Agents can act
They can read state, plan work, use tools, and submit changes.
Impact Boundary Core
Control agent impact beforeit happens.
Agents can read, plan, and propose work. The Impact Boundary Core decides what may become external impact.
Admitted work reaches an adapter. Blocked, stale, or conflicting work stops before it touches a system.
First reference adapter: GitHub Gateway
Admitted repository intent becomes a reviewable pull request, not a direct push.
Agent session log
> agent: GitHub write token missing > agent: submit structured intent gateway: reject_stage: parent_head_revalidation required_next_action: re_read_parent_pr impact: none
Why now
The risk is shifting from wrong answers to wrong outcomes.
When models only produced text, the main risk was a bad answer. Agents can now inspect code, call tools, prepare pull requests, and operate inside real workflows. The question is no longer only whether an answer is correct.
The question is whether proposed work should become real impact. Useful human work already has boundaries: developers use pull requests, pilots need clearance, and financial operators need authorization. Ability does not remove process.
BEFORE: MODEL OUTPUT
draft
code suggestion
risk shifts
NOW: AGENT WORK
API action
system change
Boundary before external impact
Useful work has boundaries
A capable developer still works through review. A capable pilot still works through clearance.
Impact needs admission
Before work reaches GitHub, a database, or another target system, the Core decides whether the request may continue.
Impact boundary core
The agent stops at intent. The Core decides admission.
An agent can propose work, but intent is not impact. Before anything leaves the boundary, the Core checks input, state, policy, evidence, and admission.
Intent source
Agent
Proposes intent
Structured intent
Admission engine
Impact Boundary Core
Validates the decision path before any adapter sees work.
Policy
Scope
State
Evidence
Decision outcomes
Admitted
May continue
External impact
Blocked
No impact
Conflict
Re-read state
Intent enters. The Core decides. Only admitted work may continue.
Key distinction
Sandboxing isolates execution. The Core isolates impact.
A sandbox limits where an agent runs and what it can access. The Core asks a different question: should this proposed outcome be allowed to exist?
Sandboxes isolate execution
They help control runtime, filesystem, process, and network behavior.
Permissions authorize access
A credential can say an actor may use a tool. It does not decide whether this proposal should happen now.
The Core controls outcome
The Core checks proposed work against state, policy, scope, and evidence before impact can continue.
Valid credentials are not valid outcomes.
Adapter host
Bring your own target system. Keep the boundary.
Every team has different systems: repositories, databases, APIs, local tools, workflows, or internal services. Adapters connect those systems to the Core without giving the agent a direct write path.
Adapters expose state, claim admitted WorkOrders, and return outcomes. They do not decide admission. The Core does.
submit-intent.ts
await core.submitIntent({
target_adapter: "github-pr",
operation_type: "create_pr",
payload: { title, branch, base }
})
policy.go
if scope != "branch:main" {
return Blocked()
}
if op == "delete_repo" {
return NeedsApproval()
}
return Admitted()
worker.ts
const wo = await claimWorkOrder()
if (!wo) return
await github.createPR(...)
await core.reportOutcome({
outcome_status: "completed"
})
Adapters can run as local binaries or Docker Compose services.
Reference adapter
Watch an agent correct itself at the boundary.
Impact Room is a reference adapter for bounded agent action. The agent can observe room state and propose a step, but every real effect still requires Core admission and adapter-side materialization.
This reference environment does not touch GitHub or any external system. It shows the same control pattern in a small, inspectable environment.
First reference adapter
GitHub Gateway is the first reference adapter.
Pull requests already separate proposed code from merged code. GitHub Gateway adds the missing boundary before repository impact: an agent proposal must be admitted before it becomes a pull request.
A coding agent can prepare repository work, but it does not receive GitHub write credentials. Admitted repository intents become reviewable pull requests. Blocked or conflicting requests stop before GitHub receives write impact.
Boundary Learning Score
The boundary does not only block. It teaches the next step.
Rules are not enough if agents keep violating them. Boundary Learning Score measures whether an agent adapts to decisions, required_next_action, and local constraints.
When a request is blocked, invalid, or stale, the Core can return structured feedback: re-read state, choose an allowed scope, include missing evidence, reduce blast radius, or request human review.
Reduce repeated mistakes
Agents should stop retrying paths the boundary already rejected.
Lower wasted runtime
Fewer blocked attempts and stale retries mean less wasted agent work.
Measure adaptation
The score shows whether the agent follows required_next_action and improves across runs.
A good agent is not the one that never gets blocked. A good agent reaches the goal while adapting to the boundary.
Labs
Labs that make boundary behavior visible.
Impact Room shows the boundary pattern in a small inspectable environment. Boundary Learning Score measures whether agents reduce repeated mistakes and adapt across runs.
Reference adapter
Impact Room
Reference adapter for bounded agent action. The agent observes state, proposes a step, receives boundary feedback, and corrects without direct authority over impact.
Open Impact Room
Coming lab
Boundary Learning Score
If there are rules, there should be a way to measure whether agents learn them. The score tracks repeated blocked attempts, stale retries, scope discipline, and adaptation across runs.
Explore Boundary Learning Score
Future direction
Boundary challenges
Design small target systems where agents must learn local rules before they touch real infrastructure.
Submit a demo idea
If there are rules, agents need a way to learn them. Operators need a way to measure whether they learned.
Future layer
Coming next: evaluate the request before impact admission.
Before a request reaches admission, the system should understand what kind of decision it needs.
Is the state fresh? Does the request fit policy? Is evidence missing? Does an operator need to look?
Boundary Evaluation helps route the next decision without giving the agent authority over impact.
Decision evidence
Every outcome should carry decision evidence.
A useful boundary should be inspectable.
The system should show what was proposed, what state and policy were checked, what decision was made, and what outcome happened.
Evidence makes decisions reviewable without replaying impact.
Security model
Five checks. Three separated control zones.
Admission checks happen inside separated zones: agent workspace, boundary validation, and adapter materialization.
PolicyStateScopeEvidenceRequired next action
01
Agent workspaceIsolation zone
The agent can read permitted context and prepare structured requests, but it does not hold the target-system write path.
02
Boundary validationDecision zone
The Core checks whether the request is allowed, fresh, scoped, and supported by required evidence.
03
Adapter materializationImpact zone
Only admitted work reaches an adapter. Blocked, invalid, or conflicting requests stop before external impact.
We gate impact, not truth.
The boundary controls whether proposed work may become outcome. It does not prove semantic correctness, does not auto-merge, does not replace human review, and does not make arbitrary adapters trusted by default.
Have a system where agents should propose work, but not directly change things?
Explore the Core, try the GitHub reference adapter, or tell us what kind of boundary your target system needs.
Send feedback