Speculative Tool Execution: Side-Effect Isolation and Promotion for Predicted Branches

While the model is still comparing two options, the runtime can check inventory or compile two candidate patches in advance. But if it preemptively creates an order or sends a message, the abandoned branch has already changed the outside world. Worse, a tool may claim dryRun=true while internally triggering a webhook, allocating an auto-increment ID, or writing to a shared cache. The latency benefit cannot prove the absence of side effects merely by deleting records afterward.

The Causal Commit Barrier for Parallel Tool Calls determines when multiple already-planned branches commit together. This article examines whether candidates may be pre-executed before the plan has been finalized. Human Approval Gates for Agents authorize high-risk actions; speculation must not turn execution after approval into something that already happened before approval.

Classify by Actual Effects First

Publish speculationPolicy.v1, classifying operations by the exact tool descriptor digest as PURE_READ, ISOLATED_COMPUTE, DRY_RUN_VERIFIED, BOUNDED_HOLD, or FORBIDDEN. A safe method in HTTP semantics means that the request's defined semantics are read-only; it does not guarantee that the implementation has no incidental effects. Classification evidence must come from gateway interception, tests, and downstream contracts. Tool names, model descriptions, or MCP annotations alone are not trustworthy.

A regular candidate receives a speculationTicket.v1 bound to the run/plan revision, branch, principal, tool and policy digests, input digest, base resource versions, isolation domain, budget, expiresAt, and a monotonically increasing generation. The ticket permits access only to snapshot data, temporary namespaces, controlled network sinks, or formal dry-run endpoints. It contains no canonical write verb. Production credentials must not be injected into a speculative worker even when the code supposedly guarantees they will not be used.

schema: speculationTicket.v1
ticket: sp-81
planRevision: 12
tool: deploy.preview@6
mode: DRY_RUN_VERIFIED
baseVersions: {manifest: 441, policy: 92}
sandbox: preview-ns-81
generation: 7
expiresAt: 2026-07-19T15:04:00Z

Kubernetes server-side dry-run does not persist requests, but an admission webhook may participate only when it declares constraints such as sideEffects: None or NoneOnDryRun. This is not a general proof that any tool is free of side effects. For every dry-run adapter, the platform should verify that egress to databases, messaging systems, email, payment services, object storage, DNS, and webhooks produces no canonical writes. If complete interception is impossible, the tool is FORBIDDEN. Sandbox Permissions for Coding Agents provide process, file, and network boundaries, while Short-Lived Capability Leases for Agents prevent tickets from being transferred to other tools or resources.

Speculative Results May Only Be Promoted, Never Applied Directly

Candidate states follow ISSUED -> RUNNING -> PREPARED -> VALIDATED -> PROMOTABLE. Unselected candidates enter DISCARDED, timed-out candidates enter EXPIRED, and only the final selector may transition a candidate to PROMOTED. Results are written to an independent speculative store whose cache keys include the ticket generation, and they are not available to ordinary requests by default. Reading results can also create side-effect risks: if permission-sensitive data is placed in a shared cache, an abandoned branch can still cause a leak. Content therefore passes through Agent Tool-Output Defenses before its provenance and freshness are recorded.

The sole acceptance point is the promoteSpeculation transaction. It matches the current plan revision, the unique chosen branch, ticket generation, principal, policy, and base resource versions; reruns authorization and any necessary lightweight validation; and then writes a promotion receipt and canonical outbox entry. An unselected branch, an old generation, or changed base data can never be promoted. For pure computation, the result digest is promoted. For an actual write operation, only a validated effect intent is promoted and subsequently carried out by the normal executor; the sandbox write set is never copied into production.

BOUNDED_HOLD does not reuse ordinary tickets. It issues a narrower holdTicket.v1 whose credential can write only to a dedicated hold namespace and cannot create orders, decrement canonical inventory, or send notifications. The hold ledger records a stable hold ID, amount, TTL, chosen plan revision, release/expiration receipt, and promotion state. A hold explicitly counts as temporary resource consumption and must not be disguised as having zero side effects. If a downstream system cannot expire holds automatically, query them by ID, and release them idempotently, it is classified as FORBIDDEN. The promotion transaction only hands the selected hold to the normal executor for conversion into a canonical effect. Unselected holds must be released and reconciled. MCP Timeouts, Retries, and Idempotency handles uncertainty in the conversion result.

Actively Search for Hidden Writes

The fault suite injects webhooks, shared-cache writes, object uploads, and DNS egress into dry-run tools. It also injects simultaneous promotion of two candidates, selection changes, worker recovery after ticket expiration, sandbox escapes, base-version drift, lost hold-release acknowledgments, TTL failures, and outputs containing indirect instructions. Canary resources, the hold ledger, and network sinks provide evidence of violating paths; checking only the primary business tables is insufficient.

The release gate requires zero canonical writes outside the hold namespace from unselected branches, zero unknown egress, and zero promotions from expired generations. The hold ledger must satisfy issued = promoted + released + expired + outstanding, with zero outstanding holds after expiration. Every promotion must be bound to the final decision receipt, ten thousand interleavings must agree with the reference state, and p95 latency must decrease by at least 15%. Rollout begins in shadow mode, then enables PURE_READ, and finally enables 1% traffic for one dry-run or bounded-hold tool at a time. Any out-of-bounds effect immediately triggers a policy-generation increase, ticket revocation, and alias shutdown. Holds are released by receipt, and promoted effects are compensated through the normal ledger. Deleting the sandbox must never be treated as a production rollback.