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. Give stable obligations authority at a boundary where they can actually be evaluated. When work repeatedly exposes missing knowledge, evidence, judgment, or authority, convert the lesson into durable structure. Then run the cycle again.

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 authority where the obligation is stable enough and the evidence adequate enough to justify it.

The MAGE cycle

Model the intent. Give stable obligations authority. 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 authority immediately while the product behavior inside that boundary remains experimental. As evidence accumulates, promote stable claims into requirements, models, invariants, and — where justified — authoritative mechanisms.

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

Model. Choose the reduction that makes the engineering question answerable without carrying unnecessary detail. The answer may be a prose model, diagram, typed contract, graph, state machine, or measured relation; it may also expose an invariant the environment should later hold. 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; giving that hypothesis binding authority merely because it is machine-readable is a different move. Uncertain intent should not acquire premature authority.

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 authoritative: 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 deserve environmental authority and place that authority at the earliest boundary where the obligation is legible and enforceable. Some obligations are local enough for a type, permission, or action hook. Others require a whole work unit, a system-level model, runtime evidence, or a human judgment. The chosen mechanism must have the semantics and evidence needed to decide the obligation.

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 authority 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 Authority?

Keep one distinction sharp. Guidance aims; authority binds consequences. Here, bind means that the result no longer depends on the agent's cooperation: the environment can deny an action, reject a result, or block admission. A brief, convention, example, or skill can strongly influence an agent, but the agent can still misunderstand or ignore it. A type, permission, or validator-backed gate acts outside that cooperation.

Do not make authority the automatic destination of every piece of guidance. Authority is appropriate when the obligation is sufficiently stable, the mechanism can evaluate it at the right semantic boundary, and the cost of violation justifies the restriction. 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 the mechanism appropriate to that property.

4.1.4 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 — 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.5 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.