4.1 The MAGE Workflow

MAGE has three recurring moves: Model, Align, Convert. Model the engineering knowledge or intent that should survive the current reasoning step. Enforce stable obligations at a boundary where they can actually be evaluated. When work repeatedly exposes missing knowledge, evidence, judgment, or enforcement, convert the lesson into durable structure. Then run the cycle again. Each pass asks where consequential judgment is still being purchased per realization: what judgment should be better supported, what should be enforced, and what should deliberately remain open.

The ordering is methodological. Local controls can act before a rich system model exists. MAGE asks about representation first because explicit models enlarge the engineering questions the environment can answer. Choose the representation that makes the question tractable, then attach enforcement where the obligation is stable enough and the evidence adequate enough to justify it.

The MAGE cycle

Model the intent. Enforce stable obligations. Convert recurring judgment into durable engineering structure.

Repeat.

4.1.1 One Turn at a Time

Need. A turn begins with something you want to learn, change, preserve, or make true. Sometimes that need is already precise: an endpoint must require authentication; this transformation must preserve content; this state transition must never occur. Sometimes it is not: onboarding feels confusing, operators think the system is slow, customers may want a different workflow. Do not treat the second kind as a defective specification waiting for an agent to elaborate. It is an unresolved engineering question.

MAGE does not require certainty before work begins. Keep the uncertainty explicit. Preserve what is already known; explore what is not. A non-negotiable security boundary may deserve enforcement immediately while the product behavior inside that boundary remains experimental. As evidence accumulates, promote stable claims into requirements, models, and invariants and — where justified — enforce the resulting obligations through dedicated mechanisms.

Be precise about what you know, experimental about what you do not, and make learning durable as it stabilizes.

Model. Start from the engineering question and choose a representation whose semantics make that question tractable. A structural model may expose dependency or reachability; a behavioral model may expose legal states and transitions; an ownership model may expose control and transfer; a decision model may expose what is permitted; a measurement model may expose a quantity against a bound; and a provenance model may expose lineage and evidence. Use only the distinctions the question requires. The representation earns its cost when later work benefits enough to justify building and maintaining it.

Do not confuse explicitness with certainty. A model can represent the current behavior, the constraints already known, and the measurements needed for exploration while leaving the proposed behavior provisional. Modeling an unsettled hypothesis can help reason about it; enforcing that hypothesis merely because it is machine-readable is a different move. Uncertain intent should not be enforced prematurely.

Explore or implement. If the problem is still being discovered, implementation can itself become an instrument of inquiry. Build cheap alternatives, measure them, put them in front of users, or construct the smallest prototype that can falsify the assumption. Commodity intelligence reduces the implementation cost of this exploration. That does not make the resulting code settled design: prototype to learn, then preserve what stabilizes in the representations and controls that deserve to persist.

Once the task is sufficiently settled, let the fleet work against the representations, procedures, and controls appropriate to it. Delegability — the degree to which a settled task can be safely handed to the fleet — comes from the whole engineered environment.

Align and evaluate. Decide which obligations the environment should enforce, and place the enforcing mechanism at the earliest boundary where the obligation is legible and enforceable. Ask what role the environment needs to play: constrain an inadmissible action, sense relevant state, validate evidence against the obligation, or gate whether work may advance. One mechanism may play several roles. Some obligations are local enough to decide at an action boundary; others require a whole work unit, a system-level model, runtime evidence, or human judgment. The mechanism must have the semantics and evidence needed to decide whether the obligation is satisfied.

Prefer evidence independent of the producing agent. Such evidence can be used to challenge and test the producing agent's claim: re-run the check, derive the state, measure the property, search for counterexamples, or send the result to an independent reviewer.

Convert. Work will expose gaps. A repeated failure may reveal missing representation, a missing obligation, inadequate observability, a weak validator, or enforcement placed at the wrong boundary. A repeated manual judgment may reveal a procedure worth preserving. Diagnose the class rather than reflexively adding another gate.

When the future return justifies the upkeep, make the lesson durable: improve the model, state the invariant, add the missing evidence, mechanize repeatable judgment, remove an unsafe action, or package a recurring procedure.

Repeat. Models drift, controls become noisy, assumptions expire, and mechanisms can outlive the failures they prevent. Maintenance, reconciliation, and retirement belong in the cycle. The objective is a productive governed environment.

Figure 4.1-1 shows how precision increases as knowledge stabilizes.

4.1.2 Closing the Loop

When judgment repeats, ask what future work should inherit from it. The answer may be a model, invariant, sensor, validator, constraint, gate, runbook, or skill. Some recurrences are too cheap or unstable to encode.

Price the conversion against the recurring cost it retires. A repeated mechanical review may earn a validator; repeated reconstruction may earn a model; a catastrophic failure may earn prevention before recurrence.

The improvement loop has familiar ancestors: mistake-proofing ¹1. Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, trans. Andrew P. Dillon (Productivity Press, 1986)., jidoka, continuous improvement, resilience engineering ²2. E. Hollnagel et al., Resilience Engineering: Concepts and Precepts (Ashgate, 2006)., and the postmortem discipline of converting incidents into durable changes ³3. B. Beyer et al., Site Reliability Engineering: How Google Runs Production Systems (O'Reilly Media, 2016).. Implementation abundance changes the economics: autonomous work can expose gaps faster than human attention can repeatedly absorb them, increasing the return on durable engineering structure.

4.1.3 Guidance or Enforcement?

Keep one distinction sharp. Guidance influences behavior; an enforced obligation binds whether or not the agent cooperates. A brief, convention, example, or skill can strongly influence an agent, but the agent can still misunderstand or ignore it. A type or permission can exclude an inadmissible action; a validator-backed gate can reject a result. These mechanisms do not depend on the producing agent remembering the obligation or voluntarily preserving it. A useful diagnostic for any step is therefore to ask: what consequential judgment does this step still trust the agent to make?

Do not make enforcement the automatic destination of every piece of guidance. Enforcement is appropriate when the obligation is sufficiently stable, the environment can evaluate it at the right semantic boundary, and the cost of violation justifies enforcement. Guidance remains appropriate where judgment is unsettled or where the cost of mechanization would exceed the failure it prevents.

"Must never happen" identifies a candidate obligation. Find the property and the boundary where it can be decided, then choose a mechanism capable of enforcing it.

4.1.4 Engineer the Judgment

Not every important judgment should become deterministic. MAGE provides two complementary ways to improve recurring work. One is to improve the conditions under which a reasoner makes a judgment: give it better representations, domain knowledge, examples, procedures, tools, and context so that a satisfactory realization becomes more likely. The other is to enforce selected obligations in the environment so that satisfying them does not depend entirely on the reasoner choosing correctly.

The distinction is not between two kinds of engineering artifact, but between two effects those artifacts can provide. A model can guide an agent and state properties consumed by a validator. A skill can improve judgment and invoke controls that enforce selected obligations. Evidence can inform a decision or feed an admission gate. A governed engineering environment composes these roles rather than assigning each artifact permanently to one side.

The choice is not simply between probabilistic judgment and deterministic enforcement. Start with the obligation and ask what representation makes it tractable, then use the cheapest judge adequate to the representation and the decision at hand. A type checker or predicate should decide a property it can decide completely; a test or model checker may be appropriate where the property concerns behavior; a model or human may be necessary where the remaining question is semantic. There is no virtue in asking a frontier model to decide what a predicate can establish, and no virtue in forcing a semantic judgment through a cheap deterministic proxy that cannot represent what matters.

Representation can change that allocation. A judgment that initially requires expensive interpretation may become mechanically decidable once the relevant states, relations, or invariants are explicit. Conversely, a cheap judge can be perfectly reliable over an inadequate representation and still answer the wrong engineering question. In DocAble, pixel variance was easy to measure but could not decide whether a low-variance image carried semantic content; the representation had discarded the distinction the obligation required. The engineering move was not to tune the threshold harder, but to route the unresolved semantic question to a richer judge.

Use the weakest representation that preserves the distinction the obligation requires, and the cheapest judge adequate to decide it. Then decide whether the resulting judgment warrants enforcement. A deterministic check may remain advisory; a probabilistic evaluator may sometimes be reliable enough to support enforcement. Adequacy of judgment and whether the resulting judgment should be enforced are separate engineering decisions.

There is an older way to understand this composition. Work on distributed cognition studies reasoning performed by systems of people, representations, procedures, and artifacts rather than locating all cognition inside one individual.⁴4. Edwin Hutchins, Cognition in the Wild (MIT Press, 1995). External representations matter in that account because they do cognitive work: they preserve state, change what operations are easy, and coordinate reasoning across participants. A Governed Engineering Environment has a similar systems character, although it adds an engineering concern that distributed cognition does not by itself supply: selected obligations can be enforced by mechanisms outside the immediate reasoner.

COGNITIVE SCIENCE

Inset — The GEE as a Distributed Cognitive System

Studies of distributed cognition ask us to move the boundary of analysis outward. Edwin Hutchins's classic study of ship navigation, for example, does not explain navigation solely by asking what one navigator knows. Position is established through a system of people with different roles, instruments, charts, procedures, communications, and intermediate representations. The relevant cognitive system is larger than any individual participating in it.⁴

The same perspective is useful for agentic engineering. A coding agent need not carry the whole engineering problem inside its context window. Models preserve selected facts about the system; skills preserve procedures; tools perform operations that need not be approximated through language-model reasoning; evidence records what occurred; people or agents supply judgments that remain difficult to evaluate mechanically. The capability of the resulting engineering system is therefore not simply the capability of its foundation model.

External representations matter for more than storage. Work on distributed cognitive tasks shows that the form of an external representation can change the operations required to solve a problem.⁵5. Jiajie Zhang and Donald A. Norman, “Representations in Distributed Cognitive Tasks,” Cognitive Science 18, no. 1 (1994): 87–122, https://doi.org/10.1207/s15516709cog1801_3. A state machine exposes legal transitions; a dependency graph exposes reachability and coupling; a measurement model exposes a bound. The representation changes the reasoning problem presented to whoever—or whatever—reasons next.

A GEE adds another step. Its surrounding machinery can sometimes act on the represented property. A dependency model may help an agent understand the architecture, but a validator can also compare an observed dependency with an architectural obligation, and a gate can refuse the change. The environment therefore does not merely distribute cognition across reasoners and artifacts. For selected obligations, it can enforce what those representations express.

This perspective helps explain why replacing one model with a more capable one does not make the surrounding engineering environment irrelevant. The environment carries system-specific knowledge, procedures, evidence, and controls that no general-purpose reasoner should have to reconstruct for every task. Better reasoners change what that environment needs to supply. They do not eliminate the value of putting durable engineering knowledge in the system around them.

Nor is the boundary fixed. A judgment that initially resists enforcement may become better understood through repeated use, failure, and refinement. Its obligations may become clearer, suitable evidence may become available, or a qualitative distinction may become evaluable with sufficient reliability. At that point, some of what previously depended on judgment can be enforced by the environment. Other portions may properly remain probabilistic. Figure 4.1-2 shows the recurring cycle.

The return path includes the governance conversion developed in Section 3.4. When an outcome or failure exposes missing representation, obligation, evidence, evaluation, or consequence, the organization can encode that missing structure so that future work inherits it. Not every observation warrants conversion: some judgments remain contextual, some failures are not recurring, and some structure costs more than it returns.

The idea that an organization should learn by changing the structures that govern later action also predates MAGE. Organizational-learning research distinguishes correcting an observed error from changing the governing assumptions, rules, or norms that repeatedly produce action.⁶6. Chris Argyris and Donald A. Schön, Organizational Learning: A Theory of Action Perspective (Addison-Wesley, 1978). Governance conversion makes a narrower engineering move. When experience exposes a recurring missing obligation, representation, procedure, or control, the lesson can become a model, skill, validator, permission, measurement, or other durable structure that later work inherits. The organization has then changed not only the failed instance but the environment in which the next instance will be produced.

A related lesson comes from the study of human error in safety-critical systems. Reliable systems do not assume that the person performing an operation will never make a mistake. They use multiple defenses so that an error need not become a system failure.⁷7. James Reason, Human Error (Cambridge University Press, 1990), https://doi.org/10.1017/CBO9781139062367. The same principle applies when the immediate reasoner is an agent. Better instructions and better context can reduce error, but recurring failures should also prompt a systems question: what representation, interface, check, independent evidence, or admission control could keep the same mistake from propagating? A GEE treats the reasoner as one component of the engineering system rather than its sole source of correctness.

The dashed arrow is an opportunity, not a required progression. MAGE does not assume that engineering knowledge should eventually become deterministic, or even enforced. Some judgments remain qualitative because the underlying objective is contextual, plural, or difficult to observe independently. Others contain narrower obligations that can be enforced even while the larger judgment remains open. The relevant unit is therefore the obligation, not the task.

Example — good writing. Consider the obligation to produce "good writing." A style guide can externalize knowledge about that objective and improve an agent's realization, but there is no single construct called good writing that admits a sound checker. Some narrower obligations nevertheless admit deterministic checks: spelling, grammatical rules, paragraph-length bounds, prohibited terms, or excessive repetition. Others admit useful but probabilistic evaluation: whether a paragraph has an effective topic sentence, whether an introduction summarizes and prepares the material that follows, or whether prose exhibits a desired style such as terse and factual rather than metaphorical. Those evaluators can themselves back enforcement where their reliability and consequences make that feasible.

None establishes that the resulting prose is "good writing." They establish narrower properties that have become sufficiently explicit to evaluate, while the broader judgment remains partly contextual and plural. Repeated experience can move this boundary. A preference first recorded only as prose in a style guide may later become a precise rule; a recurring qualitative criticism may become a probabilistic evaluator with useful measured behavior; some judgments may never justify either. The style guide remains useful throughout because its role is broader than the subset of its knowledge that the environment can enforce.

Example — from DocAble evidence to a memory bound. The DocAble memory example from the Interlude shows the same movement in a quantitative setting. The initial engineering knowledge was empirical: simple presentations worked, real teaching presentations worked, and eventually hundreds of documents from several universities worked. Those observations supported engineering judgment about the architecture's operating range, but they could not establish what would happen for a larger media payload. A roughly 250 MB presentation exposed the boundary of that evidence.

Modeling the artifact made a stronger obligation feasible. Separating the document's structural skeleton from its media exposed the relation that mattered: persistent worker memory need not scale with total media size. The resulting residency model states a quantitative invariant,

where, within the declared operating envelope,

and C does not grow with total media size. The architecture can enforce the assumptions behind that bound, while measurement checks whether the realized system behaves as the model predicts. What began as judgment supported by examples became a narrower property for which the system could provide substantially stronger evidence and enforcement.

The stronger mechanism still does not establish that DocAble "uses memory well," any more than spelling checks establish good writing. It governs a property that became precise enough to state and enforce: within the modeled envelope, total media size does not determine peak worker memory. Other dimensions — pathological structure, an individual object beyond the supported bound, excessive concurrency, or something not yet modeled — remain outside that claim. The progression from examples to a bound therefore illustrates the dashed arrow: modeling can make previously judgment-dependent obligations feasible to enforce.

Adequacy of judgment and enforcement are separate engineering decisions. A deterministic checker can remain advisory, while a probabilistic evaluator can support enforcement if its measured reliability and the cost of error make that appropriate. Deterministic evaluation provides stronger assurance for a covered decidable property; whether the obligation should govern the work is a design decision, and enforcement determines whether the environment actually requires it.

4.1.5 Prefer Structural Prevention

Prefer structural prevention when the legitimate action space can be closed. A typed API, a sanctioned mutation seam, a closed verb set, or a forbidden dependency can make an invalid move simply unavailable, and the reviewer need not catch that class of mistake because the governed interface does not offer it. Where prevention would exclude legitimate behavior, or the property only becomes visible after the work runs, preserve the action space and add independent evidence instead.

Where an invalid state can be made unrepresentable without excluding legitimate behavior, prefer a constraint. A property visible only after execution needs evidence and evaluation.

DocAble put both sides to work at once. It narrowed document repair to a closed set of bounded, typed edits, routed ordinary document-format mutation through sanctioned structured seams, and rejected direct raw-library access from code outside those seams. It turned recurring review findings into build-failing checks — prevention wherever the action space could be honestly closed. It then validated content preservation as a post-condition on every run, because "the output still says no less than the input" is a property that only becomes legible after the transformation.

4.1.6 Size Work to Reasoning and Assurance

Not every agent task deserves the full apparatus of governed autonomy. A bounded transformation whose relevant state fits comfortably in one pass, whose output is cheap to inspect or mechanically verify, and whose failure is cheap to reverse can often be delegated directly. Write the contract, let the agent produce the result, check it, and move on.

Size the task along two axes: reasoning burden and assurance need. The first is reasoning burden: how much intermediate state the task must preserve before it can produce a coherent answer. Large systems, cross-cutting changes, and long sequences of dependent decisions push that burden upward. The second is assurance need: how costly, irreversible, or difficult to detect a bad result would be. A five-line authorization change may have a short reasoning horizon and still deserve strong validation; a large disposable prototype may tolerate far less.

Size work as a sequence of transformations with explicit inputs, outputs, and checkable boundaries. Make each step large enough to exploit the model's capabilities but small enough that its result can be meaningfully evaluated before the next step compounds it. Better representation can support larger steps because it reduces the state the reasoner must reconstruct; stronger models may support larger steps too. Neither removes the need for an evidence boundary where the consequence warrants one.

DocAble's remediation edit language is the concrete pattern. Rather than ask a model to rewrite an entire document opaquely, the system asks for bounded, typed edits — set this alt text, reorder these children, change this role. Each edit can be stamped, reversed, and evaluated. The unit of delegation should line up with a unit of evidence.

Task shape matters as much as task size. A perfectly bounded transformation aimed at the wrong representation still fails. If a model performs poorly on geometry, carving the geometric problem into smaller geometric calls does not rescue the framing. Change the representation or change the division of labor. MAGE sizes work to the reasoner, the available representation, and the assurance required — not to an arbitrary line count.