6.1 A Theory of MAGE

Part V ended with two views of agentic engineering: one system studied deeply enough to reconstruct mechanisms and sequence, and independent systems studied broadly enough to expose variation. This chapter proposes an explanation for both.

The theory is directional rather than numerical. It names the main parts, how they interact, and the relationships that should hold under stated conditions. Section 6.2 turns those claims into testable predictions.

The central claim is simple. Agentic capacity acts through the engineered environment that surrounds it. A strong environment turns more implementation capacity into durable progress; a weak or incoherent one turns the same capacity into churn, escaped defects, repeated intervention, and control friction. Those outcomes also change what later work inherits. Poor realizations can degrade architecture, representations, or conventions, making later work harder. Engineers can instead diagnose recurring problems and change the environment so that later work inherits better structure. As the environment improves, larger tasks and greater autonomy become feasible, exposing the next frontier.

Theory of MAGE — informal

Agentic capacity does not by itself produce engineering progress. It magnifies the fit—or misfit—between the work attempted and the engineered environment that surrounds it.

Part I began from two limitations of autonomous realization. Reasoners have finite reasoning horizons, and consequential judgments entrusted to fallible inference retain residual risk. Parts II and III supplied two engineering responses: change the representation over which reasoning occurs, and give selected obligations independent enforcement. Part V showed a broader set of responses in practice: improve the reliability of probabilistic judgment, catch bad realizations through independent evidence and admission, or move selected recurring judgments into durable structure.

The probability-and-cost model in Part V was deliberately narrow. It exposed repeated risk, retries, and the cost of reaching an acceptable realization; it did not model the full lifecycle of defect detection, recovery, human attention, representation maintenance, friction from controls, or changes to the environment. The theory here looks at the larger system: how agentic capacity and the engineered environment together shape engineering outcomes, how the environment changes with experience, and when those changes are worth their cost.

6.1.1 The Dynamic Model

Figure 6.1-1 puts the theory on one diagram. Agentic capacity supplies model capability, concurrency, and raw implementation rate. The governed engineering environment supplies the representations, constraints, evidence, and enforcement through which that capacity acts. Together they shape three outcomes: durable throughput, defect escape, and human attention consumed per unit of useful output.

When the environment does not fit the work, the mismatch becomes visible as churn, recurring failures, escaped defects, repeated intervention, or friction from the controls themselves. These symptoms tell engineers that something is wrong. They do not say what is wrong: an engineer or organization still has to decide whether the signal is a local defect, a missing representation, a weak boundary, an inadequate control, or an obsolete piece of machinery. That diagnosis drives the change to the environment, which shapes the next round of work.

The process has a simple feedback structure. Prior engineering knowledge gives the environment a starting point. Work then exposes gaps between what the task requires and what the environment supports. Engineers diagnose those gaps and improve the environment. A stronger environment supports more ambitious work, which eventually exposes new gaps. The cycle repeats as the system, the available agentic capability, or engineering ambition changes.

This feedback structure has a precedent in cybernetics, which studied how regulators use information about a system to keep its behavior within acceptable bounds. Conant and Ashby's good regulator theorem makes representation central: under its assumptions, the simplest optimal regulator must embody a model of the system it regulates ¹1. Roger C. Conant and W. Ross Ashby, “Every Good Regulator of a System Must Be a Model of That System,” International Journal of Systems Science 1, no. 2 (1970): 89–97, https://doi.org/10.1080/00207727008920220..

MAGE applies a related idea to software engineering. The environment represents consequential properties of the system and its engineering process, observes what happens during the work, and changes when its representations or controls prove inadequate. The recurring question is simple: what must the environment know in order to govern the work?

Not all useful structure is discovered through failure. Existing architecture, standards, requirements, operating history, and lessons imported from earlier systems can seed the environment before an agent acts. Other needs become visible only in use. MAGE therefore has two routes to durable structure: before failure, when engineers deliberately encode a known obligation or useful representation, and after experience, when use exposes a recurring cost or risk worth turning into shared structure. Governance conversion names the latter route; it is not the origin story of every model or mechanism.

Two conditions determine whether adaptation reaches the shared environment. First, someone has to recognize that pressure is structural rather than local. Second, that diagnosis needs a path to the shared environment—the architecture, models, mechanisms, or infrastructure that can prevent the failure class from recurring. Without diagnosis, pressure produces motion without direction. Without authority to change the shared environment, the lesson dies as a local patch. Section 6.3 treats both as scope conditions.

6.1.2 Where Engineering Can Apply Leverage

The dynamic model suggests a broader question: where can engineering intervene to improve agentic work? Several answers are possible. Engineers can improve the reasoning model itself; change the context, tools, memory, or harness through which it works; change the process by which work is decomposed, coordinated, reviewed, and approved; change the representations over which consequential reasoning occurs; or change the evidence and controls that determine which results acquire consequence. These interventions can substitute for or complement one another. A stronger reasoner may need less support from its environment; a better representation may make the same task tractable for a weaker reasoner; a stronger admission mechanism may tolerate a less reliable producer.

One emerging school of thought puts substantial leverage in the engineering process around the agents. Hassan's Agentic Software Engineering treats trustworthy agentic development as an end-to-end software engineering system spanning people, process, tools, and artifacts. Humans establish intent and risk boundaries; agents operate through structured workflows, escalation paths, evidence requirements, permissions, and gates. Yegge's Gas Town approaches the problem from the orchestration side: persistent work state, specialized agent roles, handoffs, coordination, supervision, and merge machinery organize many fallible agents into a functioning software factory. These approaches differ considerably, but both make the organization of agentic work itself an important control surface.²2. Ahmed E. Hassan, Agentic Software Engineering: Building Trustworthy Software with Stochastic Teammates at Unprecedented Scale, 1st ed. (2026), https://agenticse-book.github.io/.³3. Steve Yegge, “Welcome to Gas Town,” January 1, 2026, https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04.

MAGE puts greater theoretical weight on what the work inherits from the engineered environment, especially its representations and enforceable obligations. Modeling changes the objects over which humans and agents reason; Alignment gives selected obligations evidence and enforcement independent of the producing reasoner; governance conversion lets later work inherit lessons learned by earlier work. Process still matters, but following a good process is not itself the engineering property ultimately at stake. The question is whether the resulting system has the intended architecture, satisfies its requirements, respects its constraints, and carries adequate evidence for consequential claims. A process can organize how those questions are answered; an engineering model can make selected answers explicit objects that humans, agents, and mechanisms can inspect and reason over.

These are complementary sources of leverage rather than mutually exclusive methods. Gas Town itself contains durable state and structured artifacts; Hassan explicitly emphasizes artifacts, evidence, constraints, and enforcement; MAGE necessarily relies on workflows, permissions, and procedures. The difference is principally one of where the methods place engineering leverage. The theory developed here asks what happens when consequential engineering knowledge and judgment move into durable representations and controls that subsequent work inherits. Section 6.4 returns to the larger design space by asking when model capability, representation, harness and process, iteration, and enforcement substitute for or complement one another.

6.1.3 What Makes an Environment Effective

More machinery does not mean a better environment. Ten thousand lines of stale checks are worse than one hundred lines that govern the obligations that matter. What counts is not how much machinery exists, but how well the environment fits the work.

An effective environment needs four things:

1. Useful representations. The information needed for the work is explicit at an appropriate level of abstraction.
2. Adequate coverage. Important obligations have appropriate evidence and enforcement.
3. Coherence. Models and mechanisms reinforce one another rather than contradicting or needlessly duplicating.
4. Economy. Their future value justifies their maintenance, friction, and context cost.

Together these determine how much consequential work still depends on fallible per-instance inference: the probabilistic surface of Part I. Representation makes consequential knowledge explicit and, where its structure permits, easier to reason about. Coverage supplies evidence and enforcement. Coherence asks whether the parts work together. Economy asks whether avoiding repeated judgment is worth the cost of carrying the machinery.

Coverage does not require mechanizing every obligation. Some belong in a compiler rule or admission gate; others remain statistical, semantic, or consequential enough to require human judgment. A strong environment does not mechanize everything. It makes clear where judgment belongs and where paying for the same judgment repeatedly would be wasteful.

These are not stages of a maturity model ⁴4. Terry B. Bollinger and Clement L. McGowan, “A Critical Look at Software Capability Evaluations,” IEEE Software 8, no. 4 (1991): 25–41, https://doi.org/10.1109/52.300034.. Improve the part of the environment that is limiting the work. If engineers repeatedly reconstruct important state, improve the representation. If failures escape, strengthen evidence or enforcement. If controls have become a tax, reconcile or remove them.

6.1.4 Outcomes and Observables

A theory of agentic engineering should distinguish activity from progress. MAGE therefore treats raw implementation velocity as an input and tracks three outcomes: durable throughput, defect escape, and human-attention burden. Table 6.1-1 defines each outcome and identifies candidate observables.

Durable throughput is useful system progress that survives rework, integration, and operation rather than merely landing in the repository. Defect escape records consequential failures that reach later lifecycle stages or production. Human-attention burden measures the scarce engineering judgment consumed per unit of durable progress.

Several easy-to-count quantities measure activity or investment rather than outcome: commits, lines changed, control files, model-sync events, and support ratio. They can help explain what an environment is doing; they do not establish that it is producing a return.^** The activity-versus-outcome gap already shows up in industry data. A 2026 benchmark of 83,000 developers across 253 organizations ⁵5. LinearB, “The Engineering Productivity Gap: How Elite AI Teams Are Pulling Away from the Rest,” LinearB, 2026, https://linearb.io/resources/ai-engineering-productivity-gap. reports large merge-rate gains among heavy AI users, yet finds yield falling among the heaviest even as merge rates roughly doubled; an industry analyst reads the same period as rising AI spend without proportionate shipping velocity, the difficulty having moved from comprehension to confidence ⁶6. Jennifer Riggins, “AI Coding Got Faster. Why Didn't Engineering?,” The New Stack, August 9, 2026, https://thenewstack.io/ai-productivity-measurement-gap/.. Activity is not the same as durable progress.

6.1.5 Three Core Predictions

Three predictions form the core of the theory. Each describes a different way the engineered environment can help.

First, the environment can make additional agentic capacity more productive rather than merely faster. Second, it can give a reasoner a better surface over which to work, reducing how much of the system must be reconstructed for each task. Third, it can preserve useful engineering judgment so that later work inherits it rather than purchasing the same reasoning again.

These effects are related, but they are not the same. Environment fit concerns whether capacity can be productively absorbed. Representation leverage concerns what the reasoner must reconstruct. Engineering capital concerns what later work gets to inherit.

Environment fit moderates the effect of velocity. Increasing agentic capacity should produce more durable throughput when the relevant engineered environment fits the work, and more churn, escaped failure, or repeated intervention when it does not. In either case, raw implementation velocity may increase; what changes is how much of that activity becomes durable progress. The effect of added velocity therefore depends on whether the environment supplies the representations, evidence, enforcement, and coherence the work requires.

Representation creates leverage. A task-relevant, trustworthy model should reduce the expected cost of reaching an acceptable realization, or increase the scale of work completed at matched quality, by reducing reconstruction and exposing consequential distinctions at a more tractable abstraction. The advantage should matter most as the required reasoning state grows. The claim fails if models impose maintenance and interpretation costs without extending reasoning reach or preserving quality.

Engineering capital amortizes judgment. Where useful engineering knowledge or recurring judgment becomes durable structure, later work over that surface should require less reconstruction, repeated judgment, or rework, and should carry less risk. The prediction includes its own boundary: the return lasts only while the asset remains fit. Stale models, obsolete validators, conflicting controls, and procedures that outlive their problem should lose value and can eventually impose net cost.

Each claim can fail. The environment may have little moderating effect; explicit models may add cost without extending reasoning reach; accumulated structure may cost as much as the judgment it was meant to retire. These are the theory's core claims. Section 6.2 derives more specific predictions from them.

The reasoning-horizon proposition

Why should representation create leverage in the first place?

Consider what happens when an engineer enters an unfamiliar system to answer a seemingly simple question: Can this service depend on that one? The answer may be distributed across source files, configuration, dependency injection, deployment descriptors, documentation, and conventions that exist only in the history of the system. Before reasoning about the dependency, the engineer must first reconstruct enough of the system to know what the dependency means.

An agent faces the same problem. A larger context window can postpone the limit, and better retrieval can bring useful evidence closer, but neither changes the underlying fact that implementation contains far more detail than most engineering questions require. A useful model changes the problem by presenting the consequential structure directly. This is the basis for the reasoning-horizon proposition.

Reasoning-Horizon Proposition. Large software systems contain more potentially relevant state than any finite reasoner can keep active at once. Task-relevant models can extend the effective reasoning horizon by replacing implementation detail with semantically richer representations of the properties under consideration. The gain holds only while the representation is relevant, sufficiently faithful to the relation it claims, and cheaper to use than reconstructing the same knowledge from lower-level artifacts.

A useful representation can shorten the reasoning path, not merely make each reasoning step easier. Without an explicit model, an agent may first have to reconstruct the relevant architecture, state, dependencies, obligations, or other relationships from lower-level artifacts before it can reason about the engineering question itself. When the environment already supplies a trustworthy, task-relevant model, the agent can skip much of that reconstruction and reason directly over the consequential structure. In this sense, the environment preserves some prior reasoning instead of forcing each attempt to reconstruct it.

The effect is analogous to using a map rather than repeatedly reconstructing a city from street-level observations. The map does not contain everything in the city, nor should it. Its value comes from preserving the relationships needed for a particular class of questions while suppressing detail that would otherwise have to be rediscovered. An engineering model provides the same kind of leverage when it preserves the distinctions relevant to the work.

Agentic systems do not create this scale problem. Human engineers have always used abstractions because no engineer can keep the implementation of a Linux-scale system in active view. Commodity intelligence changes the economics and frequency of the problem: larger delegated tasks and greater implementation volume increase the return on representations that preserve useful reasoning across episodes.

These representations do more than store facts. State machines expose transitions, dependency graphs expose relationships, contracts expose obligations, and assurance arguments relate claims to evidence. They put consequential structure into a form the reasoner can use directly. Part II offered six useful classes of such model, not a proof that they are necessary, sufficient, or minimal. Because representation creates leverage and can expand what Alignment can govern, choosing, reducing, and even learning representations is itself an engineering problem. The principle is simple: a representation is worthwhile when the reasoning it saves is worth more than the cost of building and carrying it.

Representation leverage can also work in the other direction. Part IV showed the practical version of this move: use implementation signals and commodity intelligence to help recover latent models from an existing system. Repeated structures can reveal a domain concept the implementation already embodies but has never named; bottom-up analysis can recover an abstraction that later humans, agents, and mechanisms use directly. The representation is new as an explicit engineering artifact, even when the structure it captures was already latent in the system.

The stronger possibility is representation innovation. A reasoner need not be limited to recovering an abstraction that engineers already know how to name. By working across implementations, histories, measurements, failures, and existing models, commodity intelligence may propose a different decomposition, relation, state space, or other representation that makes an engineering question tractable. The innovation is not that the machine draws a novel diagram. It is that the representation exposes consequential structure that existing representations did not make practically available for reasoning or analysis.

This extends the reasoning-horizon proposition in both directions. Human-designed representations can compress engineering knowledge into forms that let machines reason beyond implementation detail. Machine-induced representations can make latent structure explicit. Machine-innovated representations may go further, exposing relationships that extend what humans and later machines can practically reason about.

Discovery does not confer trust. Neither induction nor innovation makes a representation trustworthy. Like any model in Part II, a machine-proposed representation claims a relationship to the system and must earn the trust placed in that claim. A recovered model can be checked against the implementation it purports to summarize; a genuinely novel abstraction poses the harder question of what evidence establishes that it preserves the distinctions required by its intended engineering use. The stronger the reasoning, assurance, or enforcement built on the representation, the stronger that evidence must be.

Representation engineering can therefore work in both directions. Humans can construct abstractions that extend machine reasoning; machines can recover abstractions implicit in human-built systems; and machines may eventually help invent abstractions that extend the effective reasoning horizon of both. The research agenda returns to how representations can be selected, induced, invented, validated, learned, and reduced.

The engineering-capital proposition

Representation leverage explains how structure can make one episode of reasoning easier. The next question is what happens across episodes.

If engineers repeatedly reconstruct the same architectural fact, rediscover the same failure mode, or make the same review judgment, the organization repeatedly pays for essentially the same reasoning. But some judgments can be preserved. A dependency rule can become a validator. An architectural distinction can become a model. An operational lesson can become a procedure. Once that happens, later work begins from a different starting point.

This is the sense in which MAGE uses the term engineering capital: prior engineering work leaves behind productive capacity that future work can inherit.

Engineering-Capital Proposition. Durable engineering structures become capital when future work inherits useful capacity from them: less reconstruction, less repeated judgment, earlier or stronger evidence, safer action, or cheaper recovery. Models, mechanisms, architectures, procedures, and other engineering assets can all qualify. Their returns are local to the surfaces where later work inherits that capacity, and last only while the assets remain fit.

The metaphor is capital rather than memory. A document that merely records an old decision may preserve information; an engineering asset becomes capital when it changes the cost, capability, or risk of future work. Like other capital, it must produce a return to justify carrying it, and it can depreciate when the environment changes.

That inheritance need not depend on the continued presence of the engineer who supplied the original judgment. When an architectural distinction becomes a trustworthy model, a review judgment becomes a validator, or an operational lesson becomes a reliable procedure, some of the originating engineer's productive capacity now lives in the environment. A later engineer or agent can benefit from the result without reconstructing the reasoning that produced it.

The transfer is necessarily partial. Durable structure carries only the judgment it successfully represents or mechanizes. When requirements change, a new failure appears, or the representation itself becomes inadequate, engineering judgment is needed again. Engineering capital therefore does not eliminate expertise; it changes how often the organization must pay again for expert judgment on the same question.

The analogy to technical debt is intentional. Debt makes future change more expensive; capital makes future change more productive. Neither status is permanent. Capital depreciates as systems, obligations, and tools change. A validator can become noise, a model can drift, and a once-useful constraint can begin blocking legitimate work. Governance therefore includes maintenance, reconciliation, and retirement. Accumulation is not the objective; productive capacity is.

The analogy also connects MAGE to an emerging account of debt in AI-assisted software. Storey argues that technical debt in the implementation is only one of three interacting forms of debt. Cognitive debt accumulates when a team's shared understanding of the system erodes; intent debt accumulates when goals, constraints, and rationale are poorly externalized or maintained. Generative AI can accelerate all three by increasing implementation faster than teams can understand it or preserve why it exists.⁷7. Margaret-Anne Storey, “From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI,” Queue 24, no. 3 (2026), https://doi.org/10.1145/3807966.

A Governed Engineering Environment acts on each layer, although not in the same way. Architectural constraints, validators, models, and other durable structures can reduce technical debt by keeping later realizations inside selected structural boundaries. Explicit requirements, decisions, models, and obligations counter intent debt by preserving consequential knowledge outside any one person or reasoning episode. Cognitive debt is different: MAGE does not require every engineer to reconstruct every generated implementation in detail. It instead seeks to preserve the understanding needed for consequential engineering decisions in representations and evidence that humans and agents can inspect, challenge, and reuse.

This does not make the three debts disappear. A stale model can preserve obsolete intent; an incoherent collection of mechanisms can itself become technical burden; and no representation can substitute for understanding that was never captured in the first place. The point is narrower. Engineering capital gives selected knowledge, intent, and judgment a durable place to live, while governance determines which of those assets remain trustworthy enough for later work to inherit.

6.1.6 Modeling and Alignment Are Distinct—and Compound

The previous propositions explain why durable structure can help, but they combine two effects that MAGE keeps separate. An environment can help the reasoner reach a satisfactory answer, and it can independently control whether an unsatisfactory answer acquires consequence. MAGE calls the first Modeling and the second Alignment.

Modeling and Alignment are therefore distinct engineering activities. Modeling changes the representation through which engineers and agents reason; Alignment enforces selected obligations on realization. Either can produce value without the other.

A model can reduce reconstruction and make satisfactory realization easier without enforcing anything. Conversely, an Alignment mechanism can govern an obligation even when the producing agent never sees the representation or rule from which the mechanism decides. A type can exclude an invalid state, a sandbox can deny a capability, and a validator can reject a forbidden dependency even if the agent repeatedly proposes one.

Consider a simple architectural obligation: service A may not depend directly on service B.

One engineering problem is helping an agent understand the relevant architectural structure well enough not to propose the forbidden dependency. A useful structural model may make acceptable realizations easier to produce. A different engineering problem is ensuring that the forbidden dependency cannot enter the system even when the producer gets that relationship wrong. An independent admission check can provide that guarantee.

Cost and failure, separately

We can make the distinction precise by considering cost and failure separately.

Let $R$ denote the representation available to a reasoner. Let $p_R$ be the probability that one attempt produces a realization satisfying a particular obligation, and let $c_R$ be the cost of producing that attempt. A better representation can increase $p_R$, decrease $c_R$, or both. Under the simple retry model from Part V, the expected production cost before an acceptable candidate appears approaches

This is one role of Modeling: make acceptable realization cheaper to find.

Now let $A$ denote an independent admission mechanism. In the strongest region of Alignment, suppose $A$ is a sound deterministic predicate for the covered obligation: an unacceptable candidate cannot pass. Then

That guarantee does not require the producer to reason well about the obligation. The agent can be shown no structural model at all, repeatedly propose forbidden dependencies, and still be prevented from merging them. This is one role of Alignment: make consequence independent of whether the producing reasoner got the covered judgment right.

But assurance without useful representation can be expensive. If each rejected candidate is regenerated until the sound gate accepts one, and validation costs $c_A$ per attempt, then under the same illustrative assumptions,

Alignment can therefore provide the same admission guarantee over two reasoning surfaces at very different realization costs.

Return to the architectural example. Suppose the rule is checked perfectly at merge time. Hiding the structural model from the agent does not weaken that gate: forbidden changes still cannot merge. But the agent may repeatedly reconstruct the relevant architectural relationship incorrectly and collide with the gate. Expose an appropriate structural model to the same agent and the guarantee need not change at all. What changes is the cost of reaching a candidate the gate will accept.

Alignment protects the boundary; Modeling reduces how often work collides with it.

The four combinations therefore have different engineering meanings (Table 6.1-2).

The table is schematic rather than exhaustive. Modeling may itself improve reliability, and Alignment mechanisms may be statistical rather than deterministic. The point is that their primary contributions are separable.

Software engineering changes the problem

The analysis so far asks what happens when repeated attempts face the same realization problem. Part V used this simplification to isolate repeated probabilistic exposure: if consequential judgments have some probability of success and successive exposures are treated as independent, their joint probability of success falls as the number of exposures grows. The retry model likewise holds the probability and cost of an attempt fixed while asking what additional attempts purchase. These models are useful because they isolate the effects of exposure and repetition.

Software engineering requires a different model because one realization changes the conditions inherited by the next. Winters et al. characterize software engineering as "programming integrated over time": software is developed, modified, and maintained as both the system and its environment change.⁸8. Titus Winters et al., Software Engineering at Google: Lessons Learned from Programming over Time (O'Reilly Media, 2020). One realization therefore becomes part of the architecture, conventions, representations, tests, and other structure inherited by subsequent work. A good change can make later work easier to reason about; a locally acceptable but structurally poor change can make it harder.

For this question, independence leaves out the relationship that matters. Let the probability of satisfactory realization at step $i$ be

where $E_i$ is the engineering environment inherited at that step. The resulting realization $a_i$ then helps determine the environment available to subsequent work:

This coupling creates path dependence. A locally acceptable change can increase architectural irregularity, obscure system structure, introduce inconsistent conventions, or otherwise make later work harder to reason about. Later agents then operate over a worse reasoning surface, potentially reducing the probability of satisfactory realization. Architectural decay can therefore become self-reinforcing: poor structure makes good realization harder, and subsequent realizations can degrade the structure further.

The reverse trajectory is possible as well. A realization that improves representations, architecture, constraints, or other engineering capital can make later work easier to reason about and govern. The environment then carries useful structure forward rather than forcing each subsequent reasoner to reconstruct it.

The independent model and the dynamic model therefore answer different questions. The first isolates the effect of repeated probabilistic exposure under fixed conditions. The second preserves the relationship between successive realizations and the environments they create. These linked trajectories are the mathematical counterpart of the feedback loops in Figure 6.1-1.

Modeling can also enable Alignment

The two principles interact in a second way. Some obligations can already be checked mechanically, and Alignment can govern them directly. Others are semantic only because the relevant state must be reconstructed from lower-level implementation. Suppose the architecture requires every route to a remediation service to cross quota authorization: reasoning from implementation means reconstructing routes from handlers, middleware, configuration, and dependency injection, but representing the permitted routes explicitly turns the obligation into a graph question—does every allowed path cross the quota boundary? The property did not become less consequential; Modeling changed the object over which it is decided, turning a repeated semantic judgment into a checkable property.

There is a broader pattern here. Some engineering questions are hard because the answer is intrinsically judgmental. Others are hard because the information needed to answer them is buried in the wrong representation. These cases look similar when an engineer or agent is staring at source code: both require reasoning. But they have very different engineering possibilities. If the underlying property is genuinely judgmental, better representation may help without eliminating the judgment. If the property becomes mechanically decidable once the relevant structure is made explicit, Modeling has done something stronger: it has moved a decision from repeated inference into repeatable machinery. The boundary between those cases matters enough to name.

Call the boundary between these cases the determinization frontier: judgment on one side must still be supplied per instance; judgment on the other can be carried repeatably by the environment. Alignment can mechanize an obligation that is already decidable. Modeling can move the frontier by changing the representation until a previously reconstructed property becomes decidable. Figure 6.1-2 draws the two routes. The frontier is not a wall around what agents may do. It separates judgments the environment must repeatedly purchase from judgments it can carry forward itself.

Moving the frontier reduces the probabilistic surface: fewer consequential judgments depend on the agent getting them right. It does not make the agent deterministic, and it does not require eliminating implementation freedom. The environment can tightly govern what must be true while leaving the agent free to choose among many acceptable realizations.

The frontier can move incrementally: from prose judgment to an explicit invariant; from an invariant to exhaustive checking over a bounded state model; or, for temporal claims, to a specification over executions.

Moving the frontier does not mean closing off realization. The frontier concerns obligations: which judgments the environment can carry repeatably. The acceptable ways to satisfy them remain degrees of freedom for the agent to explore.

At the limit, a sufficiently complete realization model leaves little consequential freedom: realization becomes a transformation problem, and deterministic generation may be preferable to an agent. This limiting case connects MAGE to conventional model-based engineering; Section 7.2 returns to the relationship. Most software systems occupy a different point in the design space. Engineering specifies what must be true; many implementation choices remain acceptable. Commodity intelligence makes it economical to let autonomous realization choose among them.

The joint engineering problem

We can now put the pieces back together.

Modeling can make satisfactory realization easier to find. Alignment can prevent selected failures from acquiring consequence. Better environments can preserve useful judgment for later work, but every representation and mechanism also costs something to build, maintain, reconcile, and carry.

The objective is therefore not to maximize Modeling, maximize Alignment, or minimize the probabilistic surface at any cost. It is to engineer an economical division of labor among the reasoner, the environment, and the human judgment that remains.

For a task and its obligations, an engineer chooses both a representation $R$ and an Alignment strategy $A$:

The expression is deliberately schematic. Modeling principally changes the cost and difficulty of satisfactory realization; Alignment principally changes the probability and consequence of unacceptable realization; both impose construction and carrying costs. In high-assurance settings the problem may instead be stated as minimizing total cost subject to an assurance requirement,

For an adequately implemented deterministic gate over a decidable obligation, $\epsilon$ can be zero for that covered property even while realization remains probabilistic.

Part V supplied two kinds of evidence: longitudinal depth from the originating case and comparative variation from independent industrial reconstructions. Neither supplies population-level effect sizes or causal estimates. The theory above is the proposed explanation of those observations. Section 6.2 states predictions that require stronger external tests; Section 6.3 asks where they should be expected to hold.