1.3 Agentic Machinery and Engineering Mechanisms

Engineering methods have to fit the substrate they act on. Reinforced concrete works because concrete takes compression and steel takes tension; where the reinforcement goes follows from those properties. Agentic software engineering likewise begins by asking what productive machinery has entered the engineering process and which of its properties matter.

For MAGE, the relevant machinery is not a foundation model alone. A foundation model operates through an agentic harness inside an engineered environment. Together, they determine what autonomous work can do and where engineering can act on it.

1.3.1 Foundation Model and Agentic Harness

A foundation model supplies broad semantic reasoning at low marginal cost. Training a frontier model can require billions of dollars in capital, data, and computation; using an already-trained model for one additional reasoning task is comparatively cheap. An agentic harness—the runtime around it—turns that reasoning into action, manages the working context available to it, and exposes points where the resulting work can be observed or constrained. The useful engineering unit is therefore not the foundation model alone, but the foundation model and harness operating inside an engineered environment.

Four properties of the foundation model matter to the engineering argument:

• Broad semantic reasoning. A foundation model can interpret, synthesize, and search across open-ended domains. Give it an abstraction—a schema, state table, or policy—and it can reason about that abstraction rather than merely execute a fixed script.
• Probabilistic output. A foundation model can resolve consequential engineering questions incorrectly, and its confidence in its own result is not independent evidence that the result is correct. The producing run cannot establish engineering assurance merely by affirming its own output.
• Bounded working state. Active reasoning state is finite. Durable system knowledge must therefore persist outside the producing run and be supplied, retrieved, or reconstructed when later work needs it.
• Cheap repeated reasoning. Search, generation, repair, and reconciliation—reasoning work that once consumed substantial engineering labor—can now be repeated at previously impractical scale.

The harness contributes three complementary capabilities:

• Action. Tools turn model outputs into consequential operations: editing a file, running a command, calling an API, or changing some other part of the engineering system.
• Context management. The harness assembles and maintains the working state available to the reasoner through mechanisms such as retrieval, memory, compaction, and task state.
• Interposition. Because consequential actions pass through identifiable interfaces, the harness can expose points where the environment observes, constrains, redirects, or denies them.

None of these properties is wholly alien to human software engineering. Humans also reason with bounded state, make uncertain judgments, act through tools, and rely on evidence outside themselves. What changes is their combination with broad, inexpensive semantic reasoning and a machine-mediated environment around its actions. Recent work on harness engineering similarly treats autonomous capability as a property of the foundation-model–harness–environment system rather than the foundation model alone ¹1. Hailin Zhong and Shengxin Zhu, “AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents,” 2026, https://arxiv.org/abs/2605.13357. ²2. Justin Young, “Effective Harnesses for Long-Running Agents,” Anthropic, November 26, 2025, https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents. ³3. Garry Tan, “Thin Harness, Fat Skills,” April 9, 2026, https://github.com/garrytan/gbrain/blob/master/docs/ethos/THIN_HARNESS_FAT_SKILLS.md.. Figure 1.3-1 shows the resulting substrate. This combination changes the economics of familiar engineering problems and exposes new places to act on them.

1.3.2 The Reasoning Horizon

Scale creates a reasoning problem before an agent ever enters the picture. A sufficiently large software system exceeds what one engineer can keep actively in mind; agentic work inherits the same condition. A long engineering task is not a prompt and an answer but a sequence of related decisions: read the system, form a plan, make a change, inspect the result, reconcile what changed, and carry consequential earlier decisions into later work. The state required by that work grows while the active state available to the reasoner remains finite.

Once a task exceeds that active state, some consequential information must live elsewhere and be recovered when needed. If the reasoner repeatedly reconstructs its picture from raw implementation, loose notes, or lossy summaries, relevant decisions compete with irrelevant detail. Solved questions are re-solved, earlier constraints are contradicted, and system structure has to be rediscovered. The problem is therefore not merely how much information can be stored or retrieved, but how much question-relevant state must be reconstructed for the next engineering judgment.

Agent harnesses can move this boundary by expanding or better managing the working state available to the reasoner. But making more information available is not the same as providing a useful representation. Empirical work on long-context language models shows both limits. Usable context can fall well short of nominal capacity, and information already present in the context is not uniformly accessible.⁴4. Cheng-Ping Hsieh et al., “RULER: What's the Real Context Size of Your Long-Context Language Models?,” 2024, https://arxiv.org/abs/2404.06654. ⁵5. Nelson F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” Transactions of the Association for Computational Linguistics (TACL) 12 (2024), https://arxiv.org/abs/2307.03172. Greater model capability can move these boundaries; it does not make finite working state disappear.

Repository-scale studies report the same problem operationally: as the relevant state spreads across a larger codebase, navigation and reconstruction consume an increasing share of the work.⁶6. Sourcegraph, “Why Coding Agents Fail in Large Codebases,” Sourcegraph, 2026, https://sourcegraph.com/blog/why-coding-agents-fail-large-codebases. The precise boundary depends on the model, harness, repository, and task. The important point is the shape of the problem, not a fixed repository-size threshold.

This is a locality problem for reasoning state. Systems have long dealt with finite working sets by keeping useful state close to the computation that consumes it rather than making all state equally immediate. Purposeful representations apply the same principle semantically. A dependency graph can answer a question that thousands of retrieved source lines merely make available; a state machine can expose a behavioral property that additional context leaves implicit. Better representations reduce the amount of state that must be reconstructed for a particular engineering question.

The reasoning horizon is the boundary beyond which consequential state can no longer be carried effectively in active reasoning and must instead be recovered or reconstructed. Larger context windows, stronger reasoners, retrieval, and memory can move that boundary. Modeling can move it differently, by changing the representation over which reasoning occurs. It does not make the reasoner unbounded; it makes selected engineering questions require less reconstructed state. Figure 1.3-2 shows the mechanism.

AGENT HARNESS

Inset — Context Windows and Compaction

MAGE's reasoning horizon appears in today's agent harnesses most visibly as the problem of working within a bounded context window. The context window determines how much material the underlying model can consider directly at once, and those windows have grown substantially across generations of foundation models. Harnesses further stretch the useful working horizon by retrieving relevant state, caching or preserving selected information, and compacting an extended interaction into a smaller representation when the accumulated context becomes too large.

These mechanisms expand the amount of work an agent can carry forward, but they do so in different ways. A larger context window increases the amount of state that can remain directly available. Compaction compresses earlier state so that a longer interaction can fit within that bound, at the risk of discarding details that later matter. Retrieval and persistent state move information outside the immediate context and bring it back when needed. More generally, loop engineering can decompose work, preserve intermediate artifacts, selectively reconstruct context, and hand state between reasoning episodes. The effective working horizon of an engineered agent system can therefore be much larger than the raw context window of any single model invocation.

This is why MAGE uses reasoning horizon rather than context window. The engineering limit that matters is not a fixed token count but how much consequential reasoning state a task requires, and how effectively the surrounding system can preserve and recover that state. Today's context windows are one implementation constraint on that horizon; larger models and better harnesses can move the constraint without making the underlying problem disappear.

1.3.3 Probabilistic Work Needs External Enforcement

The second problem is not that agents make mistakes while human programmers do not. Software engineering has always separated authorship from assurance. We compile code instead of trusting the programmer's prediction that it compiles; we run tests instead of accepting an explanation that the program should work; consequential systems add review, static analysis, formal methods, operational evidence, or independent approval because the producer's confidence is not enough.

Cheap, fast, repeatable agentic production makes that separation more consequential. An agent can propose a change, inspect it, explain it, and often repair it, but another probabilistic judgment from the same productive substrate does not automatically create engineering assurance. If an obligation matters, the environment must establish what evidence counts and what follows when the obligation is not met.

Commodity intelligence is probabilistic in an engineering sense. Contemporary foundation models are learned systems whose outputs do not ordinarily carry guarantees that the engineering judgments embodied in those outputs are correct. Their present implementations may add uncertainty at several levels: generation can vary across samples; an underspecified request may admit several interpretations; intermediate reasoning and tool choices may differ; and an agentic task may compose many such judgments before producing a result. Harnesses can retry, decompose, vote, retrieve additional context, or ask another model to evaluate the first. All of these can improve reliability. None by itself turns an inferred engineering judgment into an engineering guarantee.

The details matter when evaluating a particular system, but they are too contingent to serve as the foundation of a general engineering method. Decoding can be deterministic. Errors can be correlated. One model or harness can be much better than another. Future foundation models may operate differently again. We therefore use a deliberately simple abstraction.

Suppose a realization depends on consequential judgments $J_1,\dots ,J_n$, and let $p_i$ denote the probability that judgment $J_i$ is resolved acceptably. Under the simplifying assumption that these events are independent, the probability that all of them are acceptable is the product

The effect is small when each judgment is highly reliable and there are only a few of them. If each judgment has a 99% probability of being acceptable, for example, three such judgments give an overall probability of ${0.99}^3\approx 97\%$. But the chance of success falls as the number of judgments grows: ${0.99}^{10}\approx 90\%$, and ${0.99}^{100}\approx 37\%$. It falls faster when individual judgments are less reliable: ten judgments that are each 95% reliable give ${0.95}^{10}\approx 60\%$. Even under this deliberately favorable model, many individually reliable judgments do not compose into a comparably reliable whole.

Many techniques can improve these probabilities, most notably running agents in iterative loops that critique, test, and revise their own work. Such techniques can make individual judgments substantially more reliable. The equation is illustrative, not a model of an actual agent: real judgments are not generally independent, their probabilities may be unknown, and iterative techniques can change those probabilities. But this simple model survives these complications. A consequential judgment entrusted to fallible inference retains residual risk, and adding more such judgments compounds that risk.

The consequential judgments that still depend on fallible per-instance inference form the system's probabilistic surface. Better models, prompts, context, tools, decomposition, and agent harnesses can make those judgments more reliable. Iterative loops can give the agent additional opportunities to detect and repair mistakes. These are valuable improvements, but they leave the obligation dependent on probabilistic judgment each time it arises.

This is the immediate reliability argument for moving consequential judgments out of repeated inference, but it is not the only argument for doing so. Future agents may make many such judgments cheaply and reliably. That will make for an exciting future, whether it takes one year or one hundred. But even granting that future, engineering disciplines require an independent basis for understanding what a system is intended to do, deciding which obligations govern it, and establishing why its behavior should be trusted. Part VII returns to that requirement as one of engineering control and responsibility.

1.3.4 Enforcement Outside the Producing Run

Software engineering offers another move. For selected obligations, the environment can make the required property explicit and enforce it independently of the producing run. Instead of asking an agent to remember an architectural restriction every time it edits the system, for example, the environment may be able to represent that restriction and reject changes that violate it. The judgment that established the obligation can then be reused across later acts of implementation.

Agentic work provides places where such enforcement can occur. Important changes reach the engineering system through identifiable interfaces: inputs, tool calls, edits, outputs, and lifecycle transitions. A sandbox can deny network access, a hook can reject a command, and a test can block a regression without requiring a rich system model. Explicit representations can extend the semantic reach of those same control points, allowing an action to be judged against architectural, behavioral, policy, ownership, or other system-level obligations.

The harness therefore supplies control points; representation determines what those control points can know. MAGE develops principled ways to use both while leaving the rest of realization open.