Part 5 — The Evidence  ::  Chapter 27

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 six public industrial accounts—Cloudflare, Spotify, Shopify, Docker, Siemens, and Zenseact—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?

5.5.1 Six 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; a third from making an organization's accumulated knowledge available to every agent. Figure 5.5-1 shows the problem each organization starts from and where it invests in the engineered environment.

Six entry points into a shared design space: where each organization begins and where it invests A table of six industrial systems, each entering the agentic engineering design space through a different problem and investing in a different part of the environment. Cloudflare begins from institutional policy and invests in machine-readable requirements and review mechanisms — a governance emphasis. Spotify begins from fleet-scale change and invests in targeting, verification, and admission — a governance emphasis. Shopify begins from organizational knowledge and invests in shared context and reusable agent infrastructure — a knowledge emphasis. Docker begins from delegated runtime authority and invests in scoped roles, tools, and evaluation — a governance emphasis. Siemens begins from model-first engineering and invests in persistent executable engineering representations — a modeling emphasis. Zenseact begins from distributed autonomous work and invests in platform boundaries, context, and delegation — a knowledge emphasis. A closing band reads: MAGE is the vocabulary used here to compare the observed structures, not a seventh case. Badge colour keys emphasis to the house semantic language: rust for governance and alignment, green for modeling and knowledge. The figure locates emphasis; it does not rank maturity or claim any source implements the complete method. Six entry points into a shared design space Each organization begins with a different problem and invests in a different part of the environment. Modeling · knowledge emphasis Governance · alignment emphasis ORGANIZATION STARTING PROBLEM INVESTMENT EMPHASIS Cloudflare Institutional policy Machine-readable requirements + review Governance Spotify Fleet-scale change Targeting, verification, admission Governance Shopify Organizational knowledge Shared context + reusable agent infra Knowledge Docker Delegated runtime authority Scoped roles, tools, evaluation Governance Siemens Model-first engineering Persistent executable representations Modeling Zenseact Distributed autonomous work Platform boundaries, context, delegation Knowledge MAGE the vocabulary used here to compare the observed structures The figure locates emphasis; it does not rank maturity or claim any source implements the whole method.
Figure 5.5-1. Six Entry Points. MAGE provides the comparison vocabulary; no source is claimed to implement the complete method. The organizations begin with different problems and invest in different parts of the agentic engineered environment. The figure locates emphasis; it does not rank maturity.

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.

5.5.2 The Shared Baseline

Across the six 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. Action runs through bounded tools or roles rather than giving the reasoner unconstrained authority. Generation is separated from evidence through tests, validators, reviews, simulations, or other independent checks. And consequential authority remains human even where the machinery performs most of the work. The implementations differ substantially; the same engineering grammar recurs across them.

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.

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.

5.5.4 The Modeling Ceiling

One difference is stark. In the five software-first accounts, the richest representations described publicly are primarily knowledge representations: service catalogs, dependency information, infrastructure definitions, policy corpora, repository metadata, skills, and context machinery. These are important models in the broad sense used by MAGE—they externalize engineering knowledge 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.

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.

The modeling ceiling in three tiers: where the source evidence concentrates Three stacked tiers of modeling, drawn bottom to top. Tier 1, Engineering knowledge, is green and holds topology, ownership, policy, infrastructure, lineage, and context; the five software-first sources concentrate here. Tier 2, Executable system models, is a warm neutral and holds behavior, process, scenarios, invariants, and traceability; Siemens clearly reaches this tier from a model-first engineering tradition. Tier 3, Checked correspondence, is rust and holds mechanical checks over selected model–implementation relations; the originating case experiments here, and the public software-first reconstructions do not reach it. The right margin marks where the source evidence sits, tier by tier, not where any organization's capability sits. A source silent at a tier is not evidence the organization lacks the capability. The modeling ceiling, in three tiers Where the source evidence concentrates — not a rating of any organization's capability. TIER 3 Checked correspondence Mechanical checks over selected model–implementation relations. Originating case experiments here — no public reconstruction reaches it TIER 2 Executable system models behavior · process · scenarios · invariants · traceability Siemens reaches this tier from a model-first tradition TIER 1 Engineering knowledge topology · ownership · policy · infrastructure · lineage · context Software-first sources concentrate here — the knowledge tier the software-first ceiling — the corpus falls quiet above the knowledge tier richer representation ▲ Siemens shows that the executable-model tier predates MAGE in model-based engineering; the originating case checks selected model–implementation relations; the public sources do not establish comparable mechanisms. Tiers mark where the SOURCE EVIDENCE sits. A source silent at a tier is not an organization that lacks it.
Figure 5.5-2. The Modeling Ceiling. Three tiers of modeling: engineering knowledge, executable system models, and checked correspondence. The software-first corpus concentrates on the knowledge tier; Siemens reaches the executable-model tier; the originating case checks selected model–implementation relations, and the public sources do not establish comparable mechanisms. The tiers locate the public source evidence, not organizational capability.

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.

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 six 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 answers repeatedly externalize knowledge, bound action, separate generation from evidence, and place consequential authority deliberately. 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.

Part VI asks what theory can explain both—and what follows if that theory is right.

© James C. Davis, 2026–present