01
Agent proposes
The agent describes what it wants to do before any outside system is touched.
Impact Boundary Core
The Core is the decision step between agent work and real-world change.
Agents can prepare useful work, but proposed work should not automatically become external impact. The Core creates the admission step between intent and real systems.
Core model
From proposal to decision to controlled work.
The flow is simple: the agent does not get a direct write path. It describes what it wants to do. The Core checks whether that request still matches the current state, the local rules, and the required evidence. If the request is admitted, an adapter carries out only that admitted work.
Input
Agent IntentRequested action
Context / StateCurrent facts
Policy / RulesAllowed scope
Impact Boundary Core
AdmissionValidate intent and permissions
VerificationSigned policy checks
DecisionAdmit / Block / Conflict
Impact ControlEnforce limitations
EvidenceAudit facts and results
State BindingBind to state snapshot
Adapter
GitHubRepo impact
DatabaseData ops
APIsTool actions
OrchestratorWorkflows
Outcome
ADMITTEDImpact allowed
BLOCKEDNo impact
CONFLICTRe-read required
02
Core decides
The Core checks policy, current state, scope, evidence, and whether a next action is required.
03
Adapter materializes
Only admitted work is handed to an adapter for materialization. Blocked or conflicting work stops at the boundary.
Security model
Five controlled layers before work can leave the Core.
The Core is not one final yes/no check. It receives a structured intent and moves it through controlled layers: ingress, intent validation, state binding, policy decision, and admission. Only admitted work becomes available for an adapter. Direct impact paths stop before materialization.
Security by design: five controlled layers.
Agent intent must pass through admission before it can become work.
Ingress and intent validation
Malformed, oversized, or incomplete requests stop before policy is evaluated.
State and policy binding
The request is checked against current state, allowed scope, and required evidence.
Admission before materialization
Adapters only receive admitted work. Blocked or conflicting requests create no external impact.
Adapter Host
The Adapter Host gives your system one local boundary API.
User code submits intent and reads state through the host. Adapter workers only receive admitted WorkOrders.
The Core remains the decision authority.
User code talks to the host. Adapters only receive admitted work.
Agent-side code
Agent-side API
One local surface for state reads and proposed work.
POST /v0/read-state
Read state
POST /v0/intents
Submit intent
Idempotency-Key
Bind retry
Adapter Host binary
The local boundary host
The host keeps the user flow, Core decision, and adapter handoff in one narrow local contract.
Local API + split auth
Ingress token / adapter token
State + policy callbacks
Configured connector URLs
Core decision
Admit / block / conflict
Local state store
WorkOrder, lease, local trace
Adapter handoff
Claim work / report outcome
no raw agent intent reaches the target
Adapter worker
Target-side materialization
The adapter translates admitted work into target-system changes.
POST /v0/adapter/work-orders/claims
Claim admitted work
Materialize admitted work
Materialize target change
POST /v0/adapter/outcomes
Report bound outcome
Boundaries
The Core is not an agent framework, does not auto-merge, and does not prove generated work is semantically correct. It defines the admission path adapters use before proposed work can become impact.