3.1 Where Obligations Can Be Enforced
A foundation model produces probabilistic outputs; a harness turns selected outputs into actions. Once those actions can alter a repository, invoke an API, change infrastructure, or ship an artifact, the engineering question is no longer only how to steer the reasoner. It is where the surrounding environment can intervene between a proposed action and its consequence.
Start with the distinction between guidance and enforcement. Guidance influences behavior; enforcement determines what the environment will permit or accept. A prompt, brief, example, or playbook can make one action more likely than another, and that influence can be strong. A permission boundary can forbid an action; a validator and gate can refuse a result. Feedback can then return the evidence or explanation to the reasoner—a failing test, an observed call, a measured latency, or a validator's explanation—so that subsequent work can respond. MAGE uses all of these mechanisms, but counts an obligation as enforced only when the engineered environment constrains the relevant action or determines whether the resulting work is accepted rather than merely advising the reasoner.
Recent agentic-security guidance draws a similar boundary. Once agents act before commit time, the repository is too late to be the security boundary: the tools, permissions, and execution environment that produce a change join the trusted base, so agentic security must secure the process that creates the artifact, not only the artifact 11. Snyk, “The Agentic Development Lifecycle,” Snyk, 2026, https://snyk.io/blog/agentic-development-lifecycle/..
An obligation can be enforced at several boundaries in the work. The useful question is not which one is "hardest," but where the relevant obligation is visible and a mechanism can enforce it. Four representative boundaries recur throughout the book — reasoning input, agent action, the work unit, and the accepted artifact or runtime state. Figure 3.1-1 puts them on one line.
3.1.1 Reasoning Input, Action, Work Unit, and Artifact/Runtime
The first location is reasoning input: the context, representations, examples, and instructions put in front of the reasoner. This is where Modeling and context engineering do most of their work: a finite reasoner does better when the relevant system knowledge is already externalized and selected for the task. But placement in context is ordinarily guidance, not enforcement. The model can misread, forget, or disregard what it was shown.
AIInset — Context Engineering: Making the Right Knowledge Available
Context engineering concerns what information is made available to a reasoner for a particular episode of work. Instructions, examples, retrieved material, prior decisions, and engineering models can all contribute to that working state. The problem is not fitting more information into a context window. It is selecting the right information, at the right abstraction, when the decision is made.
MAGE gives context engineering durable engineering knowledge to draw from. Modeling externalizes engineering knowledge so that each agent does not have to reconstruct it from source code, documentation, and prior conversations. Context engineering can then select the relevant portions of that knowledge for the work at hand. The distinction is useful: Modeling engineers what is known; context engineering engineers what is presently available to reasoning. Retrieval, memory, compaction, skills, and other mechanisms may change how that selection is implemented, but the underlying engineering problem remains.
One realization is dynamic context injection (DCI): the environment observes properties of the work, selects the engineering knowledge relevant to those properties, and places that knowledge into the agent's reasoning context. The mechanism improves what the agent can see when making a decision; it does not itself enforce what that guidance says. Section 4.5 develops this pattern operationally.
Guidance can make an acceptable realization more likely. A sufficiently sound constraint or admission mechanism can instead exclude a represented class of unacceptable realizations from the surface it governs. The first improves the producer's chances of satisfying the obligation; the second changes what admission must trust.
The first enforcement boundary is the action boundary exposed by the harness and its tools. Here, one attempted side effect is in view: a tool call, an API request, a shell command, or a file mutation.
AGENT HARNESSInset — Hooks and Permissions
MAGE's Alignment principle appears in today's agent harnesses partly through mechanisms that interpose on agent actions. Harnesses may require permission before a tool executes, restrict which tools or resources an agent can access, or invoke hooks when the agent attempts an operation. These mechanisms create places outside the producing model turn where the engineered environment can observe, constrain, or reject what the agent is trying to do.
The mechanisms provide different kinds of control. Permissions and restricted tool surfaces can remove actions from the agent's available repertoire—for example, allowing a deployment tool to read production state while denying it permission to modify that state. Pre-action hooks can inspect a proposed command or mutation and reject it when an obligation is violated. Post-action hooks can run checks or collect evidence after a change has occurred. Beyond the harness itself, tests, linters, type checkers, CI gates, policy engines, and deployment controls can evaluate larger units of work before they are accepted. What matters is not whether a mechanism is called a hook or a gate, but what obligation it checks and what it does when that obligation is violated.
This is why MAGE describes alignment controls and enforcement boundaries rather than treating hooks or permissions as the abstraction. Harness features expose convenient contemporary control points, but the underlying engineering problem is broader: determine which obligations matter, where sufficient evidence exists to evaluate them, and what mechanism constrains or rejects unacceptable realization.
The second is the work-unit boundary, where many actions compose into a meaningful unit: a completed task, pull request, build, migration step, or deployment candidate. Obligations that no single action can express become legible here: that the model and the implementation agree at task completion, that a change carries all its required evidence, that "done" actually holds. A pre-commit check can reject a local defect; a task-completion audit can weigh the whole body of work; a deployment gate can refuse a candidate whose accumulated evidence is inadequate. These boundaries matter because different obligations become legible at different grains of work.
The third enforcement boundary is the artifact or runtime boundary: the resulting system or running state. Types, narrow APIs, architectural seams, schemas, runtime permissions, and admission policies can make a forbidden state impossible to express or impossible to accept. DocAble's format seam provides a concrete example: ordinary remediation code reaches the raw format library only through one structured interface, while a ban-lint detects any forbidden direct access. The model states the architecture; the interface and the check enforce the boundary.
3.1.2 Placement and Strength Are Different Decisions
The four boundaries do not form a monotonic scale from weak to strong. A narrowly scoped API permission may enforce its obligation more strictly than a late CI check; a type may rule out one state completely while saying nothing about a system-level obligation a task-completion gate can weigh. Where a mechanism acts and how strongly it enforces an obligation are different design decisions.
Richer models can expand the properties the environment is able to state and govern, but substantial enforcement can exist without them. A bounded execution sandbox, for example, can constrain actions without requiring a rich model of the system it contains.
3.1.3 Return Evidence at the Earliest Useful Boundary
The boundaries also decide where feedback can return. A harness can preserve durable state before a lossy compaction; an action hook can explain why a call was refused; CI can hand back a failing invariant while the change is still fresh in the window; a deployment validator can report which evidence failed admission. The earlier useful evidence returns, the less work an agent must reconstruct before repairing the miss.
Controls within the GEE can also interact or conflict; Section 3.5 treats their growing portfolio as a system in its own right.
The Alignment Principle: make engineering obligations enforceable by encoding them into mechanisms that constrain actions, produce evidence, evaluate that evidence, and control admission. In other words: once the environment should enforce an obligation, satisfying it should not depend solely on each future agent remembering it.
Part IV turns these mechanisms into method. For now, their placement is easiest to see in systems already using them.
Worked Examples
Docker. Docker's public account places enforcement in the environment, not its instructions: the agent acts only through a constrained tool seam, and the platform — not the prompt — decides what that seam permits. A move outside the boundary is refused, not merely discouraged. The permission is enforced at the action boundary: the agent cannot override it through its instructions. Two industrial fleets place enforcement the same way at coarser grain. Zenseact's public account describes each domain team's agent as little more than a config file and a skill, while a central team owns the runtime, permissions, and context routing; an agent's reach is a property of where it sits in the platform, not of how it was asked. Spotify's public account describes migration agents operating through a restricted API and a narrow Git interface, with every change clearing a merge gate before it lands. The gate, not the agent's confidence, admits the work.
DocAble. DocAble distributes its controls across the boundaries: a skill in the harness, an action hook, a pre-commit check, and — its sharpest — an application-boundary seam for document mutation. At the application boundary, DocAble represents document mutation through a sanctioned structured seam. Static controls reject ordinary code that bypasses that seam for the raw format library. The model states the architecture; the interface and lint enforce that relation.
Takeaway. Place the enforcing mechanism at a boundary where the obligation is legible and the environment can evaluate or constrain the relevant work. The appropriate boundary depends on the obligation.
The next chapter asks what must be true before an obligation deserves enforcement.
Works Cited
- Snyk. “The Agentic Development Lifecycle.” Snyk, 2026. https://snyk.io/blog/agentic-development-lifecycle/.