Glossary

James C. Davis

Glossary

Agentic software engineering is moving quickly, and its vocabulary has not settled. This glossary defines the terms used in this book. It has three parts: software engineering vocabulary, software agents, and the governed engineering environment.

Software engineering vocabulary

The book uses a small engineering vocabulary deliberately.

Engineering. Designing under goals, constraints, and trade-offs by reasoning about what a proposed solution may do, what it must do, and what evidence supports those beliefs. Software engineering applies that discipline to software systems.

Engineering obligation. A requirement that an implementation or other engineering result must satisfy. Obligations may arise externally—from users, regulations, standards, contracts, or operating environments—or internally from engineering decisions about architecture, behavior, quality, or process. An obligation becomes authoritative when the engineering environment can constrain work by it or determine whether it has been satisfied.

Model. A purposeful reduction of a system that preserves the information needed to answer an engineering question while suppressing detail the question does not need. Models make engineering knowledge and intent explicit so engineers and agents can reason about selected system properties without rebuilding that knowledge from lower-level artifacts each time.

Model classes. MAGE uses six recurring classes of models, organized by the engineering questions they help answer (Figure 0.4-1). The list is not exhaustive, and one representation may serve more than one class.

Figure 0.4-1. The six model classes, organized by the engineering questions they answer.

Modeling Principle. Make engineering knowledge and intent explicit in purposeful models so humans and agents can reason about larger questions without reconstructing the needed facts from lower-level detail.

Tolerance and degree of freedom. Engineering obligations need not determine a single acceptable implementation. A tolerance bounds the variation that an obligation permits; a degree of freedom is an aspect of the implementation that remains free to vary within those bounds. An unmodeled choice is therefore not necessarily free. If some implementations would be rejected, the choice may instead conceal an obligation whose tolerance is unknown, tacit, or not yet explicit.

Governance. Deciding what autonomous work must know, what it may do, what evidence it must produce, and what mechanisms will hold those decisions over time.

Alignment Principle. Give important engineering obligations authority over autonomous work. Encode them in mechanisms that constrain actions, produce evidence, evaluate evidence against obligations, or control admission. Alignment can act directly on actions and artifacts. Explicit models let those mechanisms state and check richer properties, including acceptable bounds on variation.

Governance conversion. When a recurring failure, repeated judgment, or observed gap reveals something future work should inherit, encode the lesson in durable structure: a model, packaged procedure, or authoritative mechanism.

Engineering capital. Durable engineering structure—models, packaged procedures, mechanisms, canonical documentation, and other reusable assets—that makes later work cheaper or less uncertain. Governance conversion creates such structure; it becomes capital when later work benefits from it, and depreciates when it no longer fits the system or costs more to maintain than it returns.

Commodity intelligence. General-purpose machine intelligence available cheaply and at enough scale that implementation becomes less scarce relative to engineering judgment. The term describes an economic change, not a claim that intelligence is free, unlimited, or itself sufficient for engineering.

Software agents

The agents, foundation models, harnesses, and operating limits involved in autonomous software work.

Figure 0.4-2. The agent stack and a characteristic failure mode. When a task's reasoning horizon exceeds the working state the harness can keep active, repeated reconstruction contributes to churn.

Agent. An AI system that pursues an open-ended or underspecified task through multiple steps, exercising judgment about what to do next and using tools in response to intermediate results. In this book, agent means a coding or engineering agent operating over software artifacts, tools, and an execution environment.

Churn. Work spent rediscovering context, undoing recent changes, repairing regressions, or reconciling inconsistencies instead of advancing the system.

Foundation model. The trained model at the bottom of the agent stack. Its capabilities and context capacity set important limits that the harness and engineered environment must work within.

Agentic harness. The runtime wrapped around the foundation model — Claude Code, OpenCode, and their kin — that feeds it prompts, manages the context window, and provides hooks, skills, and tools.

Skills and tools. Capabilities exposed through an agentic harness that extend what an agent can do. A skill provides reusable guidance for a recurring class of work; a tool provides a deterministic capability the agent can invoke rather than approximate through reasoning.

Fleet. The set of coding agents working on a shared codebase or engineering system.

Reasoning horizon. The amount of intermediate reasoning state that must remain available at once to carry a task to a correct result. It is a property of the task, not of who reasons — human, agent, or a later architecture. A long-horizon task needs more reasoning state than the available working memory can hold, forcing some state to be compressed and later reconstructed. Agent harnesses call this compaction; today, the context window is one important source of the limit.

The Governed Engineering Environment

The environment that gives engineering obligations durable authority.

Figure 0.4-3. The governed environment. Governance mechanisms give engineering obligations authority by acting directly on observable work or through explicit models that expose richer semantics. Durable models, mechanisms, procedures, and documentation accumulate as engineering capital.

Governed Engineering Environment. An engineered environment where selected engineering obligations have authority through durable mechanisms instead of relying mainly on people to remember or inspect them. Explicit models let those mechanisms govern properties that would otherwise require a person to reconstruct or judge them.

Governance mechanism. A repeatable structure that gives an engineering obligation authority in the environment. A mechanism can play four roles: constraints restrict permissible actions; sensors produce evidence; validators check evidence against an obligation; and gates decide whether work may cross a workflow boundary. One mechanism may play more than one role.

Semantic gap. The distance between where an engineering obligation arises and where the environment has enough meaning and evidence to decide whether the obligation is satisfied. The gap explains why some checks must wait until a later boundary, when enough of the system has been assembled to make the obligation decidable.

Model drift. A model and the system, evidence, or other representation to which it is meant to correspond cease to agree.

Traceability. Explicit, machine-readable links from model elements to the artifacts, evidence, obligations, or other model elements they represent, constrain, or correspond to.