Protocol objective
Make diverse tool calling behave like one controlled transaction
Long-running enterprise jobs rarely share one transaction manager. A purchase decision can cross demand signals, procurement, ERP, approvals, warehouse state, and banking systems, each with distinct schemas, permissions, retries, and failure semantics.
The execution protocol supplies the missing control plane. It does not pretend that distributed side effects are atomic. It makes every boundary explicit, preserves partial progress, and requires reconciliation before the run may claim completion.
State machine
Every consequential transition passes through verification
Minimum authoritative state and policy required for the next checkpoint are versioned and fresh.
A typed transition and expected postcondition exist; no consequential write has occurred.
Identity, permission, policy, limits, approvals, and segregation constraints have passed.
The tool call owns an idempotency key and a bounded side-effect contract.
The runtime reads authoritative state rather than trusting the tool response or model narration.
Partial progress is preserved while the runtime retries, compensates, rebinds, or escalates.
Terminal checks pass and the evidence package is sufficient to reconstruct the result.
Any state may terminate in a controlled refusal or escalation. COMPLETED is reachable only through VERIFYING.
Separation of authority
Four boundaries prevent plausible text from becoming an unsafe write
Inference boundary
The model may interpret intent, classify state, and propose a typed transition. It cannot grant itself authority or declare a side effect complete.
Authorization boundary
A deterministic gate resolves identity, tenant, policy version, limits, approvals, and segregation constraints immediately before execution.
Transaction boundary
The runtime assigns an idempotency scope, records the expected side effect, executes through a typed adapter, and captures the receipt or uncertainty.
Evidence boundary
Completion is determined from authoritative read-back and explicit postconditions—not the model narrative or a nominally successful API response.
Context discipline
Fresh state at checkpoints, not an ever-growing transcript
Context is an execution dependency with a validity interval. The runtime must know where each value came from, when it was observed, and which write or external event makes it stale.
- Bind only state required by the active checkpoint, with source and version attached.
- Invalidate a bind after any consequential write or external version change affecting its assumptions.
- Keep prior observations in the trace, not in active working context as if they were still current.
- Resolve conflicts by source authority and policy—not by whichever record appears latest in the transcript.
Failure semantics
“The call failed” is not a sufficient recovery state
Recovery depends on whether a side effect definitely did not occur, definitely occurred, or remains unknown. Conflating those conditions is how retries become duplicate transactions.
Rejected before write
Preserve the proposal and failed constraint; rebind or escalate only if a legal alternative exists.
Definite no-write
Retry within the declared budget using the same idempotency scope after checking freshness requirements.
Unknown side effect
Do not retry. Query authoritative state using the idempotency scope, then complete, compensate, or escalate.
Partial cross-system commit
Freeze dependent transitions, preserve completed writes, and enter the job-specific reconciliation path.
Postcondition mismatch
Treat the run as incomplete even when the tool returned success; rebind changed state and invoke recovery.
Non-negotiable invariants
Properties the model cannot waive
- 01The model may propose a write; only the control plane may authorize it.
- 02Every consequential call carries tenant, identity, policy version, and idempotency scope.
- 03A successful API response is not completion; authoritative postconditions must pass.
- 04Retries never erase prior side effects, and recovery never restarts blindly from the original prompt.
- 05Context is rebound after material state change instead of accumulated indefinitely in conversation history.
- 06A run that cannot prove safety and completion must refuse or escalate, never infer success.