Impact Boundary Labs
GitHub
Documentation navigation

Core docs

Why boundaries matter

Agents are good at turning context into suggested actions. The problem starts when a suggested action and a real external write are treated as the same thing. If a model updates a repository, changes a ticket, moves someone in a workflow, or modifies a cloud resource, the question is not only whether the suggestion sounded reasonable. It is how the system decided the effect was allowed to happen.

Impact Boundary exists because direct agent writes are too implicit. A boundary makes the path to impact explicit. That is useful even when the team trusts the model, because trust does not remove the need for a system that can state what was checked and what actually changed.

Reading is not writing

An agent may need broad context to reason well. A write is different: it changes a system that has consequences outside the model. Treating those two paths as one operation is what makes agentic writes hard to inspect.

So the boundary keeps five things distinct instead of collapsing them into "the agent did something":

  • Intent - the structured request the agent submits, with an explicit target and action.
  • Decision - the result after state and policy are evaluated and Core validates the contract: admitted, blocked, or conflict.
  • Admitted work - the bounded work order an adapter may claim, created only once a decision is admitted.
  • Materialized effect - the real external change, performed by an adapter worker.
  • Outcome - the report of what actually happened, which is not the same as the intent or the decision.

Keeping these separate is the point, not decoration. It stops the system from treating "the model said so" as if it were already an inspected external action. The full glossary lives in Terminology.

The real risk is ambiguity, not malice

The main risk of direct writes is not a hostile agent. It is that the system cannot answer basic operational questions afterward:

  • Did the agent write against fresh state, or stale state?
  • Was there a policy layer, or only a prompt convention?
  • Did a worker act on a formally admitted instruction, or on whatever the tool loop produced?
  • When something broke, was it the decision or the materialization?

If those questions are hard to answer, the system is hard to trust in operation - even when the agent is well-behaved.

State drift

State drift is the practical reason a system-side check matters. The world changes between the moment an agent reasons about something and the moment the action is applied. Another pull request lands. The ticket is reassigned. The account loses a permission the agent assumed. The target resource moves on.

If the system only relies on "the agent said it checked," that check is detached from the action path. Checking state as part of admission turns an unverified claim into a real gate.

Policy proposes, Core admits

Policy matters, but policy alone is not authority to write. In this design, policy returns a candidate decision. That candidate still has to fit the Core contract and the current state before anything is admitted. Treating policy as candidate data, not direct impact, keeps the final gate in one place.

One concrete path: a repository write

Take an agent that wants to open a pull request after a code change.

Without a boundary, the loop is direct: the agent reasons over the repo, generates a change, and calls a tool that pushes a branch and opens the pull request. It may work, but the operational meaning is muddy. Was the branch still in the state the agent assumed? Was the change in scope for that repository? Was there a formal admission step at all?

With a boundary, the path is legible. The agent submits intent ("propose this repository update"). The system checks current repository state. Policy evaluates whether that change is allowed. Core validates the decision. If admitted, an adapter worker claims the work and performs the action. The outcome then reports what happened: "pull request created," or "no impact, the branch had already changed."

The same shape holds for a non-GitHub target, such as moving an item in an internal operations tool: a different adapter, the same intent-to-outcome path. That is not a guarantee the change is correct. It is a path from request to effect that stays explicit, bounded, and inspectable.

For an engineer, that is the appeal. Agentic writes become something you can reason about: you can see where state enters, where policy enters, where a decision becomes admitted, and what was actually materialized. The boundary controls the path to impact. It does not claim the agent is right.