Duality Lab — James C. Davis

Apply the MAGE Method

This page is a concise guide to applying MAGE. It summarizes the practical argument rather than reproducing it: Part 4 of the book develops the method in full, and Appendix G develops organizational adoption.

Read Part 4: The MAGE Method → · Read Appendix G: Adopting GenAI in an Organization →

Engineer the environment, not just the realization

MAGE starts from a practical observation: giving an agent a better prompt is not the only way to improve its work. We can also improve the engineering environment in which the work happens.

Engineering recurring work: a governed environment both supports reasoning and enforces selected obligations, and the cycle iterates Recurring engineering work exposes a judgment and is handled by engineering the environment. The environment supports the reasoner — models, knowledge, examples, procedures, context, skills, tools, evidence — and enforces selected obligations — constraints, validators, permissions, gates, checks. A dashed arrow from support to enforcement marks the recurring move of adding enforcement where feasible. The governed engineering environment then hosts realization, enforcement mechanisms act on selected obligations, and work is realized. A return edge runs from realized work back to recurring engineering work: its lower portion observes outcomes and failures, and its upper portion improves the environment — the governance conversion of Section 3.4, where recurring judgment can be encoded economically. RECURRING ENGINEERING WORK expose the judgment ENGINEER THE ENVIRONMENT SUPPORT THE REASONER models · knowledge · examples procedures · context · skills tools · evidence ENFORCE SELECTED OBLIGATIONS constraints · validators permissions · gates checks add enforcement where feasible GOVERNED ENGINEERING ENVIRONMENT reasoner attempts realization mechanisms enforce selected obligations REALIZED WORK observe outcomes and failures improve the environment; governance conversion where warranted
Engineering recurring work. Support the reasoner and independently check important obligations; observe what the work reveals, and convert recurring lessons back into the environment.

There are two complementary moves. Modeling improves what the reasoner has to work with: the system structure, intent, knowledge, procedures, context, and evidence relevant to the task. Alignment checks important requirements independently of the agent where appropriate, rather than relying only on the agent to remember, interpret, and satisfy them.

Then do the work and observe what happens. Repeated failures and recurring human judgments reveal what the environment is still missing. When the expected future benefit justifies the cost, governance conversion changes the environment so that later work can inherit what earlier work learned.

The result is an iterative engineering process, not an attempt to specify everything correctly in advance.

Read the full method in Part 4 →

Start where you are

There is no single MAGE starting point. Where to begin depends on two questions: how much of the system already exists, and how settled is the relevant intent?

Two axes of a migration's starting conditions: how much system exists, crossed with how much intent is settled A two-by-two matrix. The columns ask how much you know about what the system should become: intent uncertain on the left, intent settled on the right. The rows ask how much system already exists: little implementation on top, much implementation on the bottom. The four cells name the proportionate first move. Little implementation with uncertain intent: explore — build enough to learn before you specify. Little implementation with settled intent: model early — a known contract earns heavy modeling from the start. Much implementation with uncertain intent: recover, then explore — surface the latent structure, then probe the open intent. Much implementation with settled intent: recover, reconcile, govern — surface the latent models and controls, reconcile them with the code, and put settled obligations under enforcement. The settled column is shaded more strongly than the uncertain column, but the reading is per-obligation rather than project-wide: the more settled a particular obligation, the more enforcement it can safely receive, so a security, legal, or safety constraint may be settled and enforced even inside an otherwise exploratory product. How much system exists fixes the representation and controls you inherit; how settled a given obligation is fixes how much of it can safely be made explicit and enforced. Two axes fix where a migration starts how settled the intent is → Intent uncertain what to build is open Intent settled the contract is known ↓ how much exists Little a blank page Much a live system little × uncertain Explore build enough to learn before you specify little × settled Model early a known contract earns modeling from the start much × uncertain Recover, explore surface the latent structure, then probe the open intent much × settled Recover, reconcile, govern surface latent models and controls, reconcile them, then govern
Where to start. How much of the system already exists, and how settled the relevant intent is, determine where to begin.

If little exists and the intent is uncertain, explore. If little exists but important requirements are already settled, model early. If a substantial system already exists, recover the knowledge and structure already embedded in it; then either continue exploring unsettled questions or reconcile and govern the parts that are already understood.

Most real systems contain a mixture of these conditions. Apply the method to the engineering problem in front of you rather than trying to classify the whole project as being at one MAGE “stage.”

Expand delegation as the environment improves

AI assistance is comparatively easy because the worker remains around the agent. The worker supplies missing context, notices mistakes, makes intermediate judgments, and decides whether the result is acceptable.

Delegation changes that arrangement.

From assistance to bounded delegation: responsibilities move into the environment and the delegation boundary expands Two panels. On the left, under assistance, a worker supplies context, judgment, and acceptance directly to an agent, and a narrow dashed boundary marks the little the agent may do on its own. A wide arrow points right: selected responsibilities move into the environment. On the right, under bounded delegation, a governed environment surrounds the agent — models carry context, evidence establishes properties, and mechanisms constrain and admit results — while the worker governs that environment rather than each act, and a wider dashed boundary marks the expanded authority the agent may exercise on its own. The change is a shifting boundary, not a sequence of maturity levels. FROM ASSISTANCE TO BOUNDED DELEGATION ASSISTANCE WORKER context judgment acceptance AGENT the worker supplies each judgment directly selected responsibilities move into the environment BOUNDED DELEGATION WORKER governs GOVERNED ENVIRONMENT models context evidence properties mechanisms constrain · admit AGENT selected responsibilities move into the environment The dashed boundary of delegated authority expands — a shifting boundary, not a sequence of maturity levels.
From assistance to bounded delegation. Responsibilities the worker supplied move into the environment as the delegated boundary expands — a shifting boundary, not a ladder of levels.

As the worker steps farther out of the immediate task, the responsibilities they supplied do not disappear. They must either remain with an appropriate expert or move into the engineering environment: into models, evidence, procedures, checks, constraints, and other structures that can support and govern the delegated work.

The goal is therefore not to move an organization through fixed “levels of autonomy.” Expand the delegated boundary where the surrounding engineering provides an adequate basis for doing so. Different systems—and different requirements within the same system—can support different amounts of delegation.

Go deeper

The MAGE Method — Part 4. The complete treatment of the practical method: choosing work units, modeling, alignment, governance conversion, brownfield migration, validation, operations, and reusable skills. Read Part 4 →

Adopting GenAI in an Organization — Appendix G. Guidance for moving from individual assistance toward bounded delegation: identifying the functions people currently supply, deciding which responsibilities can move into the engineering environment, and expanding delegation where the resulting basis is adequate. Read Appendix G →