01
Agent requests an action.
The request describes the intended effect, not just the tool name.
How it works
How Impact Boundary works
A selected agent tool call becomes a request. The boundary checks explicit policy inputs and observed runtime facts. Core decides. Only admitted work executes.
How the boundary works
02
Boundary checks policy and facts.
Impact Boundary checks explicit policy inputs and observed runtime facts.
03
Core decides.
The Core returns admitted, blocked, or a reason to re-check.
04
Only admitted work executes.
Only admitted work reaches the downstream tool. The adapter does not decide admission.
The adapter does not decide.
The Core owns the decision. Blocked or conflicted requests return structured reasons, so the agent can re-check state, narrow scope, add evidence, or ask for review before trying again.
Missing question
Tool access is not the same as effect admission.
Tool permissions say what an agent may call. Impact Boundary checks whether this exact action should happen now.
Can this tool be called?
That is an access question. A permission can say the agent may use a tool.
Should this effect happen now?
That is an impact question. It depends on current state, explicit policy inputs, scope, and evidence.
Who decides?
Impact Boundary puts a Core-owned decision between the request and the downstream effect.
The agent can prepare work. The boundary decides whether that work may become external impact.
First concrete example
A valid tool call can still be the wrong effect.
Your agent can request a tool action. That does not mean the effect should execute.
Valid tool call
The agent requests a tool action.
The tool call matches an available tool and has the right shape.
Observed runtime fact
The checked state is stale.
The request was prepared against old state, so the proposed effect no longer matches what is true now.
Boundary result
Execution stops before downstream change.
No file, repository, workflow, database, or target system changes unless the Core admits the request.
The boundary blocks execution before the downstream system changes.
Why Core exists
Core owns the decision.
The boundary idea became a small decision core: explicit policy inputs, observed state, runtime facts, decision, and outcome. Core is the decision owner, not the public product frontdoor.
Why adapters exist
Adapters translate admitted work.
Core should not know every target system. Adapters translate admitted work into real system actions and report outcomes.
The adapter translates, executes, and reports. It does not decide.
Five-layer boundary model
A stacked model for where the decision sits.
Once the basic story is clear, the boundary can be viewed as five layers. The important part is still the same: only admitted work reaches execution.
Layer 01
Agent request
The agent proposes a selected tool call and intended effect.
Layer 02
MCP Boundary
The request enters the boundary before downstream execution.
Layer 03
Policy inputs + runtime facts
Explicit policy inputs and observed runtime facts are checked.
Layer 04
Core decision
The Core owns admission and returns a decision.
Layer 05
Adapter execution + outcome
Only admitted work is translated, executed, and reported.