Why the runtime is the wrong boundary
Agent middleware can inspect decisions, but it only controls the code paths that choose to go through it. That is fragile when teams run multiple frameworks, direct SDK calls, background jobs, or plain HTTP clients.
If the protected system is still reachable around your control layer, then the real control point is somewhere else. The key question is not whether you observed the agent. It is whether the mutation can happen without you.
What changes at the target API
IntentChain sits on the route to the target system. That means the protected request has to pass schema validation, policy evaluation, permit verification, and credential mediation before it can be forwarded.
- One boundary: the same control point works across frameworks, runtimes, and tool choices.
- No parallel path: raw HTTP or alternate SDK calls do not escape the rail if the gateway is the route.
- Exact execution: the downstream system sees only requests that have already survived verification.
That placement turns the API edge into the real control point. The runtime can still decide what to attempt, but it cannot decide what actually executes.
Why this is the real moat
The moat is not a nicer policy language. It is owning the executable path. When the action cannot reach the target API except through the rail, governance becomes enforceable instead of aspirational.
That is why the control point belongs at the target API, not the agent runtime. The irreversible action lives there, so the boundary has to live there too.