5.5 MAGE in the Wild

The originating case supplies depth. The useful next question is whether its engineering structures are peculiar to DocAble or recur when other organizations solve related problems independently. This chapter reads eight public industrial accounts—Cloudflare, Spotify, Shopify, Docker, Siemens, Zenseact, Uber, and GitLab—as reconstructions rather than case studies: they expose selected mechanisms rather than the full histories that produced them. They supply variation—comparable structures, alternative realizations, and places where the MAGE vocabulary fits poorly. The question is narrower: what engineering structures recur, where do they differ, and what does the comparison force us to revise?

Earlier Parts connected MAGE's abstractions to familiar agent-harness mechanisms: context management, skills, tools, permissions, hooks, and fleets. Here the direction reverses. The mechanisms are observable features of independently built systems; the question is what engineering function each performs. What knowledge does it preserve? What reasoning does it avoid? What action does it constrain? What evidence does it produce? What judgment does it allow later work to inherit? Reading the systems this way lets us compare implementations that use different terminology and machinery without treating any current harness design as the MAGE abstraction.

One implication is worth flagging here. These organizations largely use agents to scale familiar software-engineering practices. That can make the software factory much more productive without necessarily making the resulting systems easier for engineers to understand. As autonomous production scales, the engineering question is whether explicit system knowledge and independent control must scale with it. Appendix G returns to that question as an organizational adoption problem.

5.5.1 Eight Entry Points

The organizations begin with different problems. One starts from institutional policy that has outgrown any reviewer's memory; another from the need to change thousands of repositories at once; another from making an organization's accumulated knowledge available to every agent; Uber starts from the economics of operating an agentic software factory at organizational scale; GitLab starts from making abundant code trustworthy at machine-scale development. Figure 5.5-1 shows the problem each organization starts from and where it invests in the engineered environment.

Cloudflare gives the cleanest policy-first example. A standards corpus that had outgrown individual memory was externalized into structured, machine-readable requirements; mechanically checkable obligations could move into custom checks while ambiguous ones remained review questions. Humans retained policy authority while agents increased the reach of decisions made elsewhere. The important limitation is equally revealing: the source richly models obligations, but gives much less evidence of an executable model of the governed software itself. That difference anticipates the modeling ceiling visible across the corpus.

Uber and GitLab reach the same kind of engineering from opposite motives: both build a durable environment around a replaceable reasoner. GitLab starts from trust — as code becomes abundant, the scarce problem shifts to trusting it, so it wraps the model in a durable layer of context, verification, governance, identity, and provenance, kept independent of any one model so the organization's controls persist even as the reasoner changes.¹1. Bill Staples, “When Code Is Abundant,” GitLab, 2026, https://about.gitlab.com/blog/when-code-is-abundant/. Uber starts from economics, and gives the fuller, independently measured account, so the deep treatment follows it.

Uber's public account describes AI tools operating throughout the software lifecycle: more than 70 percent of pull requests are attributed to local or cloud agents, engineers have created more than 3,600 agent skills, and those skills execute more than 30,000 times per day. Managed agents perform code review, CI repair, end-to-end changes, alert triage, debugging, and maintenance work.²2. Uday Kiran Medisetty, “Running a Software Factory Efficiently at Uber Scale,” Uber Engineering, 2026, https://www.uber.com/us/en/blog/efficient-software-factory/. The interesting structure is not merely the volume of agent use. Uber treats the surrounding environment as an object of engineering: real workloads become benchmarks; models are selected against cost, quality, and reliability; context and tool access are compiled down to reduce unnecessary reasoning; recurring workflows become reusable skills; and managed agents are evaluated in units such as cost per merged pull request, review, or alert.

This is recognizably MAGE-like without being model-first. Both organizations engineer the conditions under which agents act — what information and tools they receive, how work is decomposed, what it costs — and both keep a knowledge-and-context graph as the reasoning surface (Uber's AI Context Graph, GitLab's Orbit) rather than an executable model of the software's behavior. Their accounts say much more about context, skills, routing, and governance than about behavioral, process, scenario, or invariant models. Their sophistication therefore strengthens rather than dissolves the modeling ceiling developed below.

5.5.2 The Shared Baseline

Across the eight sources, four moves recur strongly enough to form a shared baseline. Knowledge is externalized rather than rebuilt from a person's memory on every task, appearing concretely as shared context, knowledge graphs, instructions, skills, and other persistent representations. Action is bounded through scoped tools, permissions, APIs, roles, and other restrictions on what an agent can do. Generation is separated from evidence through tests, validators, reviews, simulations, merge gates, and other independent checks. And consequential decisions remain human where the available representations and evidence do not justify delegating them. The mechanisms differ substantially; the same engineering functions recur across them.

Uber adds a fifth recurring concern made especially visible at scale: the environment itself is continuously measured and optimized, so model choice, context, tools, decomposition, and reusable procedures become engineering variables rather than fixed properties of the reasoner.

Across the reconstructions, safe autonomy relies not on making the reasoner infallible but on legible context, bounded action, independent evidence, and explicit limits on machine authority.

5.5.3 Where the Reconstructions Differ

The differences are as informative as the commonalities. The organizations vary in how aggressively they automate admission, how much organizational knowledge they route into each task, whether recurring failures change the shared environment, and, most sharply, how explicitly they model the governed system itself. Docker, for example, mechanizes substantial evaluation while deliberately retaining a human merge decision; Spotify pushes further toward automatic fleet-scale admission; Shopify turns shared interaction into reusable organizational context; Siemens begins from persistent engineering models rather than from source code. Uber exposes another axis: it treats cost per useful outcome as a first-class property of the agentic environment and tunes models, context, tools, and reusable skills against that objective.

No ordering follows automatically from those differences. A human admission boundary may be exactly right where the decision remains semantic or consequential. A richer model may not repay its cost in another environment. The comparison is useful because it exposes design choices and boundaries, not because it produces a winner.

The systems also differ in where they leave trust. Some primarily improve the information available to the reasoner; some make organizational knowledge persistent; some encode policy or structure into machine-actionable representations; some enforce selected properties independently of the reasoner. These are not maturity levels. They are different allocations of consequential judgment between reasoner and environment. They also allocate judgment differently among representations and judges: some improve the context presented to a probabilistic reasoner, some move selected questions into machine-actionable structure, and some enforce mechanically established results independently of the producing reasoner.

5.5.4 The Modeling Ceiling

One difference is stark. In the seven software-first accounts, the richest representations described publicly are primarily knowledge and governance representations: service catalogs, dependency information, infrastructure definitions, policy corpora, repository metadata, skills, context machinery, provenance records, and lifecycle graphs. These are important models in the broad sense used by MAGE—they externalize engineering knowledge, preserve consequential relationships, and extend what an agent can recover reliably—but the sources give little evidence of behavioral, process, scenario, or invariant models serving as the primary surface of software reasoning.

GitLab illustrates the boundary clearly. Its context graph makes relationships among requirements, code, pipelines, deployments, production signals, policy, and evidence available to agents and governance machinery. That is richer than disconnected files or retrieved prose, but its public role is still primarily to preserve and expose engineering context, provenance, and control relationships.

Siemens crosses that boundary because it comes from a model-first engineering tradition. Behavioral structure, traceability, requirements, simulation, and analysis already live in persistent engineering representations; software generation is one downstream realization. The comparison shows that the strong end of the Modeling Principle has an established precedent in model-based engineering but is unusual in the software-first agent systems examined here.

The originating case goes one step further. For selected models, mechanical checks compare declared relations to the implementation and reject changes when those relations no longer hold. These checks cover particular relations rather than establishing general correspondence between model and implementation, and the case does not show how broadly such checks can be applied at reasonable cost.

Figure 5.5-2 states the finding as three tiers and marks where the source evidence sits.

5.5.5 Engineering Capital at Organizational Scale

The industrial reconstructions show something the single-engineer origin cannot: how these moves operate across an organization. Four moves recur. Organizations centralize shared mechanisms while keeping domain judgment distributed. Platform teams own common authentication, execution, safety, or policy machinery while domain teams retain the expertise that decides what their agents should do. Human judgment moves upstream: one engineer can scope and supervise a migration implemented concurrently by a fleet rather than hand-authoring every change. Private learning becomes a shared artifact: sessions, policies, skills, and defaults become useful only when later work can inherit them. And the unit of governance grows: from a task or agent to classes of work, permissions, fleets, policies, and platforms.

Uber makes this conversion unusually literal: recurring tool workflows are packaged as reusable skills, and standard agent configurations encode routing and context decisions that would otherwise have to be reconstructed on each session. In one example, deterministic tool orchestration is moved out of repeated model turns into executable code, then packaged for reuse across later work. The source reports that code-mode converts repeated tool interactions into subprocess execution, keeping intermediate polling outside the model context; on common SQL workflows it cuts token use by more than half and by more than 90 percent in bulk cases, with more than 25 such workflows packaged as reusable skills.²

GitLab describes the same conversion from repeated judgment to durable structure. A production failure can become a regression test; a security incident can become a policy; a performance requirement can become an automated constraint; and a compliance obligation can become continuous validation. The artifact differs, but the engineering move is the same: knowledge gained in one episode is converted into structure that later work can inherit rather than requiring the same judgment to be reconstructed each time.¹

The common structure is leverage. A scarce human decision becomes more valuable when it is placed where the environment can carry it forward: one policy can shape thousands of changes; one shared representation can guide work across a fleet; one learned constraint can protect every later task over the same surface. This is the organizational face of engineering capital. Governance does not remove judgment. It gives selected judgments multiplicative reach.

5.5.6 They Converged on a Problem

The eight organizations do not converge on one stack, one degree of autonomy, or one modeling discipline. They converge on a recognizable engineering problem: how to make abundant intelligence useful without requiring proportional growth in human vigilance. Their particular mechanisms differ—context graphs, skills, tools, scoped permissions, tests, validators, gates, and persistent engineering models—but the engineering functions recur: externalize consequential knowledge, bound action, produce evidence independently of generation, and decide deliberately which obligations the environment will enforce. They differ in what they model, what they mechanize, and what they still ask a person to decide.

The comparison does not prove MAGE's causal claims. It shows something narrower: the originating case is not the only place where this engineering grammar appears. DocAble supplies mechanism and sequence; the industrial reconstructions show related structures emerging independently under different constraints.

5.5.7 Four Views of Repeated Judgment

The approaches these organizations use can work. Better foundation models can make better engineering judgments. Better prompts, decomposition, retrieval, context, and persistent organizational knowledge can improve those judgments further. Independent evaluation can reject bad candidates and send the work around another loop. Nothing in the evidence here argues otherwise.

The difficulty appears with scale and time. An engineering obligation rarely needs to survive one realization. It must survive repeated changes to a growing system. Each time satisfaction of the obligation depends on a fallible reasoner retrieving, interpreting, and honoring it, engineering incurs another probabilistic exposure. The four views below hold that process still from four angles: how often the judgment must go right, how much reasoning another attempt buys, where engineering can act, and what one judgment carried forward changes.

View 1 — Repeated Exposure

Part I introduced a deliberately simple model for consequential probabilistic judgment. Apply the same model across time. Let an obligation face relevant exposures $1,\dots ,m$, and let $p_j$ denote the probability that it is resolved acceptably on exposure $j$. Under the same illustrative independence assumption,

If the probability is constant across exposures, this becomes

The equation is not a fitted model of agent behavior. Errors can be correlated, tasks differ, and engineering processes can detect and repair failures. Its purpose is structural: reliability depends both on how favorable each probabilistic judgment is and on how often engineering requires that judgment to be made again.

Even reassuring per-exposure reliability can erode under repetition. An illustrative $p=0.999$ gives

The number is pedagogical, not an estimate of model reliability. Its point is that a long-lived system repeatedly re-exposes consequential obligations when their satisfaction remains dependent on per-instance inference.

This gives us two dimensions of scale. A larger system can place more consequential obligations and relationships in play during one change. A longer-lived system accumulates more changes over which those obligations must continue to hold. Part I emphasized the first dimension. The industrial evidence makes the second difficult to ignore.

View 2 — Retry Purchases Another Chance

The first view treats each exposure as one judgment. Real agent systems often do something more powerful: generate a candidate, evaluate it, feed the result back, and try again. A loop does not make the reasoner deterministic; it purchases additional chances to obtain an acceptable realization.

Suppose one attempt has probability $p$ of satisfying the obligation, each attempt costs $c$, and the loop permits at most $k$ attempts. Under the same simplifying independence assumption,

The expected number of attempts actually consumed is

so expected attempt cost is

As $k$ grows, eventual success approaches one whenever $p>0$, while expected cost approaches

This is why long agent loops can work extremely well without making the underlying reasoner deterministic. Repetition purchases reliability with additional inference, realization, validation, latency, and sometimes human attention.

A simple example shows the tradeoff. Suppose an attempt succeeds half the time. Ten attempts give

probability of finding an acceptable result while consuming almost two attempts on average. If a better reasoning surface raises per-attempt success to $0.9$, three attempts give

with only about $1.11$ attempts expected. The eventual reliability is essentially the same. The amount of reasoning purchased to obtain it is not.

This view therefore adds something the first one cannot show: reliability and reasoning cost are separate axes.

View 3 — Engineering Can Act at Different Places

Retry is only one intervention. Engineering can act at several different places in the process.

A stronger foundation model can increase $p$: when the consequential judgment must still be made, a satisfactory answer is more likely on each attempt. Better context, retrieval, tools, specifications, and representations can also increase $p$, reduce the cost $c$ of an attempt, or remove preliminary reasoning that would otherwise be spent reconstructing the relevant structure. Decomposition, critique, testing, simulation, and loops can purchase additional attempts. Independent validators and gates act differently: they need not improve the producing judgment at all, but can reject covered failures before they are accepted. And where an obligation can be represented and governed adequately, engineering can sometimes stop requiring the probabilistic judgment in the first place.

A simple comparison makes the last distinction visible. Suppose an obligation is resolved acceptably with probability 0.99 on each of 100 independent exposures:

Improving per-exposure reliability to 0.999 gives

That is a large improvement, and better probabilistic engineering should not be dismissed. But engineering can also act on the number of exposures. If durable structure makes 90 of those 100 occasions no longer require the probabilistic judgment, leaving ten exposures,

And the approaches can combine:

These are different interventions. Improve the odds. Purchase another attempt. Catch a bad realization before it is accepted. Or stop requiring that judgment on every change. MAGE uses all four where appropriate.

The industrial reconstructions occupy different parts of this design space. Shopify and Zenseact emphasize the information available to reasoning. Docker and Spotify make evaluation and admission increasingly explicit. Cloudflare turns selected policy into machine-readable requirements and mechanically checkable obligations while retaining human authority over ambiguous cases. Uber explicitly optimizes the economics of reasoning itself, routing work across models and restructuring context, tools, and reusable procedures to reduce the cost of satisfactory realization. GitLab places context, provenance, verification, identity, and policy into a durable layer surrounding replaceable models and agents. Siemens begins farther upstream, with persistent executable engineering representations serving as a primary reasoning surface. These are not maturity levels. They are different allocations of reasoning, cost, evidence, and enforcement between reasoner and environment.

A stronger environment can change what is verifiable. The preceding comparison treats verification largely as a fixed capability: given an obligation, a validator either covers it or does not. Modeling makes that capability itself an engineering variable.

Let $O$ be the set of consequential obligations relevant to a change, and let $V\left(E\right)\subseteq O$ be the obligations that engineering environment $E$ can verify independently of the producing reasoner. Improving the agent may increase the probability that obligations outside $V\left(E\right)$ are satisfied correctly. Improving the environment can instead enlarge $V\left(E\right)$:

The distinction matters because an obligation moved into $V\left(E\right)$ no longer depends solely on the producing reasoner getting it right. A behavioral model can make an execution property analyzable; an invariant can make a relation mechanically checkable; a model–implementation check can reject a change that breaks a declared correspondence. Better reasoning improves performance within the existing verification boundary. Better engineering can move the boundary.

The industrial reconstructions largely demonstrate the first kind of expansion around a human-derived engineering environment: give agents better context, faster feedback, broader tool access, stronger tests, and more explicit governance. MAGE includes those moves, but also asks where machine-scale engineering makes richer representations and stronger analyses economical. The two strategies are distinct and compose: a better reasoner raises $p$; a stronger environment enlarges $\left|V\right(E\left)\right|$. Part VI develops this distinction as a theory of the evolving engineering environment; Appendix G turns it into an organizational adoption problem.

View 4 — One Judgment Can Acquire Durable Reach

The preceding views still treat engineering largely as a sequence of realizations. The originating case suggests one more possibility: an engineering judgment made today can change what later realizations have to purchase again.

Architectural decisions became typed seams; recurring findings became repeatable checks; implicit behavior became lifecycle models; forensic reconstruction became provenance. Each converted work that would otherwise recur across future changes into something later work could inherit:

This is the connection to engineering capital. A useful representation can spare later reasoners from reconstructing the same structure. A validator can make a recurring evaluation repeatable. A constraint can prevent a class of realization from arising. A gate can enforce an established obligation. The value of the original judgment can therefore extend across later work rather than being repurchased one realization at a time.

As recurrence grows, the potential value of that conversion grows with it — but so do the reasons not to mechanize everything. Durable structure has construction cost, carrying cost, friction, and depreciation. Some judgments remain semantic, unstable, or too expensive to encode. The engineering question is not how to eliminate probabilistic reasoning. It is which judgments should remain probabilistic, how much reasoning should be purchased around them, and which recurring judgments are worth carrying forward in the environment.

What These Views Leave Out

These models are deliberately simple. They make repeated exposure, retry, reasoning cost, and durable reach visible by holding several things fixed. Sustained engineering violates those simplifications in two important ways.

First, the engineering environment can change the reasoning required by an attempt. An explicit representation may let an agent reason directly over architecture, state, dependencies, or obligations that it would otherwise have to reconstruct from implementation. Modeling can therefore increase the chance of a satisfactory realization, reduce its reasoning cost, or eliminate some preliminary reasoning altogether.

Second, successive realizations are likely not independent. Each change alters the system and engineering environment inherited by later work. Good structure can make later reasoning easier; architectural decay can make it harder. Tomorrow's probability and cost can depend on what today's realization leaves behind.

Part VI develops a theory around these interactions. MAGE does not necessarily reduce how many changes occur. It changes the reasoning each change requires, which consequential judgments must still be purchased probabilistically, and what engineering structure later work inherits.