The difference between the main objects
One of the easiest ways to get confused about agentic systems is to blur together terms that should stay separate.
Model output
Model output is what the system generated: a plan, a tool call, a proposal, or a suggested action. It may be useful, but by itself it is just generated content.
Intent
Intent is the structured request the system chooses to submit into the boundary. This is already stronger than raw model output because it turns a free-form suggestion into a typed request with explicit target information and action context.
Decision
A decision is the result of the decision path after state and policy have been evaluated and Core has validated the contract. The decision says whether the path is admitted, blocked, in conflict, or routed elsewhere.
Materialized effect
Materialized effect is the real external change. This is the moment where a target system is actually touched by an adapter worker.
Outcome
Outcome is the report after materialization. It says what happened once the worker tried to perform the external effect. It is not the same as the original decision or the original intent.
Keeping these objects separate is more than terminology. It prevents the system from treating "the model said so" as if that were already an inspected external action.
Why direct writes are risky or unclear
The main risk of direct writes is not only malicious behavior. The more common problem is ambiguity. A system may not be able to answer simple operational questions after the fact:
- Did the agent write based on fresh state or stale state?
- Was there any policy layer, or only a prompt convention?
- Did a worker act on a formally admitted instruction, or on whatever the tool loop happened to produce?
- When something went wrong, was the problem in the decision path or in the target-side materialization?
If those questions are hard to answer, the system is hard to trust operationally.
A boundary is useful even when the agent is trusted
It is tempting to think that a strong prompt, a good model, or a trusted internal use case makes a boundary unnecessary. That misses the point. A boundary is not only about distrusting the model. It is about giving the surrounding system a stable control point.
Even a well-behaved agent can operate on old assumptions, misunderstand a target's current state, or trigger an external effect through a route that is difficult to inspect later. A trusted agent still benefits from a system-side state check and a separate admission step because those steps make the write path explicit.
The boundary is not only for hostile cases. It is also for ordinary operational clarity.
State drift in simple terms
State drift means the world changes between the time an agent reasons about something and the time an action is actually applied. This happens constantly in real systems.
An agent might inspect a repository branch, a ticket, or a cloud resource and decide that an action is safe. But by the time it tries to apply that action:
- another pull request may have landed;
- the ticket may have been reassigned;
- the room may have been locked;
- the account may have lost the permission the agent assumed;
- the target resource may have changed state.
If the system only relies on "the agent said it checked," then that check is detached from the actual action path. A system-side state check is stronger because it becomes part of the admission process instead of an unverified claim inside model output.
Why policy should not directly equal impact
Policy is important, but policy alone should not be treated as direct authority to write. In this design, policy returns a candidate decision. That candidate still has to fit the Core contract and the current request and state context.
If policy directly equaled impact, malformed or mismatched outputs would be harder to catch. Treating policy as candidate data instead of direct effect keeps the system honest about where the final gate actually is.
Example: repository write
Consider an agent that wants to open a pull request after making a code change.
Without a boundary, the loop can be very direct: the agent reasons over the repo, generates a change, and calls a tool that pushes a branch and opens a pull request. That may work, but the operational meaning is muddy. Was the target branch still in the state the agent thought it was? Was the change allowed for that repository and scope? Did the system have a formal admission step before opening the PR?
With a boundary, the flow is clearer. The agent submits intent such as "propose this repository update." The system checks the current repository state. Policy evaluates whether that type of change is allowed. Core validates the decision path. If admitted, an adapter worker can claim the work and perform the repository action. The outcome then reports what actually happened, such as "pull request created" or "no impact because the branch had already changed."
That is not a guarantee that the change is semantically correct. It is a clearer path from request to effect.
Example: non-repository system
Now take a non-GitHub example such as moving a person or item between rooms in an internal operations tool.
An agent might read the current room assignment and decide to move someone because that seems consistent with the task. But room membership can change quickly. A lock may have been added. Capacity may have changed. Another worker may already have performed a move.
If the system uses a boundary, the state is checked again as part of the path. Policy evaluates whether the move is allowed. Core validates the decision path. Only admitted work becomes claimable by the adapter that talks to the room system. The worker then reports the outcome, which might be "completed," "no impact," or a failure outcome.
Explicit, bounded, inspectable
A good write path should be explicit, bounded, and inspectable. The system should be able to say where the request came from, what target and scope it applied to, and what happened after materialization.
Why this matters for engineering teams
For a developer, founder, or security-minded engineer, the appeal of the boundary is that it turns agentic writes into a system you can reason about. You can inspect where state enters the path, where policy enters the path, where a decision becomes admitted, and what was actually materialized.
Summary
Impact Boundary is useful because direct agent writes are often ambiguous, even when the agent is well-intentioned or trusted. It separates model output, intent, decision, materialized effect, and outcome. It uses system-side state checks instead of relying only on "the agent said it checked." It treats policy as candidate data rather than direct impact authority. The boundary controls the path to impact; it does not prove the agent is correct.