3.1 Where Authority Can Act
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 authority. Guidance influences behavior; authority constrains consequences. A prompt, brief, example, or playbook can make one action more likely than another, and that influence can be strong. It does not by itself decide what the environment permits or accepts. A permission boundary, a type, a validator, or a gate can. MAGE uses both, and reserves authority for the second move.
Feedback closes the loop. A mechanism can make the result of work legible to the next reasoning step: a failing test, an observed call, a measured latency, a validator's explanation. Feedback creates no authority; it lets an agent respond to evidence produced outside its own judgment.
Agents are steerable; their outputs are not guaranteed by the instruction that steers them. Instructions influence the model's output distribution; they do not by themselves determine what the environment permits or accepts. So authority has to reside in the surrounding environment, at a boundary where a mechanism can affect what action occurs or what result is accepted.
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/..
Authority can act at several boundaries in the work. The useful question is not which one is "hardest," but where the relevant obligation is visible and where a mechanism can affect the consequence. 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 authority. 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 simply fitting more information into a context window. A finite reasoner benefits when the information relevant to the decision is selected, represented at an appropriate level of abstraction, and available when the decision is made.
MAGE gives context engineering a durable substrate. 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 make the resulting guidance authoritative. Section 4.5 develops this pattern operationally.
Availability, however, is not authority. An agent can misunderstand, forget, or disregard something placed in its context. When an engineering obligation must hold, showing it to the agent is insufficient. Alignment places authority in the surrounding environment through constraints, validators, permissions, gates, or other mechanisms that can affect what the agent may do or what results the system will accept. In compact form: Modeling makes knowledge explicit; context engineering makes relevant knowledge available; Alignment gives selected obligations authority.
The first authority-bearing 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. Permissions can remove an action from the agent's repertoire; a hook can inspect or reject a proposed action; a tool can expose a deterministic operation instead of asking the model to improvise it. An alert-triage agent permitted to shift a maintenance window but forbidden to create infrastructure has a bounded blast radius because the API denies the forbidden action, not because the prompt discourages it 22. Cockroach Labs, “Cockroachdb AI Agents: CLI Database Automation,” Cockroach Labs, 2026, https://www.cockroachlabs.com/blog/cockroachdb-ai-agents-cli-database-automation/..
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 authority-bearing 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 give the boundary its authority.
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 bind more absolutely 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 much authority it carries are different design decisions.
Guidance can be placed alongside these boundaries, but it should not be confused with authority. Context can strongly influence behavior while carrying no authority over what is accepted. An environmental control, in turn, can bind an action the model never reasoned about at all. A bounded execution sandbox shows the distinction clearly: substantial Alignment can exist with little explicit system modeling. Richer models do something different: they enlarge the set of properties the environment can state and reason about. They expand the semantic reach of authority; they are not a precondition for authority to act.
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; a later chapter treats their growing portfolio as a system in its own right.
The Alignment Principle: give engineering obligations authority by encoding them into mechanisms that constrain actions, produce evidence, evaluate that evidence, and control admission. In other words: once the environment should hold an obligation, encode it in a mechanism that can bind the consequence rather than relying on each future agent to remember it.
Part IV turns this distinction into method: the agent may propose an engineering move, while the governed environment determines which consequences are permitted or accepted.
Authority installed at a boundary — rather than asked for in a prompt — is easiest to see in systems already running it.
Worked Examples
Docker. Docker's public account places an agent's authority 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. That is authority at the action boundary: a permission the agent cannot override through its instructions. Two industrial fleets place authority 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 give that relation authority.
Takeaway. Authority does not have one home. Docker uses a constrained action surface; Zenseact centralizes permissions in its platform; Spotify places substantial authority at the work unit; DocAble spreads controls across actions, hooks, checks, and application seams. The common move is not a particular boundary but environmental authority that does not depend on the producing agent's agreement.
The next chapter asks what must be true before any obligation deserves binding authority.