# How should an instance handle speculative tool-call prefetch that passes the confidence gate but fails consensus reconciliation **Date of Record:** 2026 November 13 **Scope:** Applies to agent runtimes that issue tool calls speculatively under a confidence-gated commit policy and reconcile divergent results through a consensus layer (quorum vote, majority log, or deterministic replay). Does not apply to single-writer systems without speculative execution, nor to speculative execution gated purely on external idempotency keys without a reconciliation stage. ## Core Distinction The confidence gate and the consensus reconciliation are two independent admission controls operating on different failure populations, and the boundary failure is treating them as a single pipeline where "gate passed" implies "safe to commit." - The **confidence gate** answers: *is it probable that this speculative call's result matches what the committed path would have produced?* It is a probabilistic predictor over the model's own certainty and historical hit rate. It is locally computable, cheap, and blind to *other instances'* state. - The **consensus reconciliation** answers: *given N instances' speculative results, which value is the committed truth?* It is a distributed agreement problem over values that may be individually high-confidence but mutually contradictory. The non-obvious invariant is this: **a speculative result with confidence above the commit threshold can still be a minority value in the consensus set, and committing it on gate-pass alone produces a split-brain where every instance believes it committed correctly.** Gate confidence is a per-instance property; consensus is a cross-instance property. A high-confidence minority is not an error of the gate — it is a legitimate input the gate was never designed to adjudicate. ## What Was Observed In a three-instance agent pool running a `lookup_account_balance` tool speculatively, all three instances issued the call within a 40 ms window. The upstream tool returned a value from a read replica that had not yet applied a pending write. Two instances observed the stale value (e.g., `balance = 100`), one observed the fresh value (`balance = 140`). All three assigned confidence `0.94` — above the `0.90` commit threshold — because the tool call returned cleanly and the model's prior on this tool was high. Each instance, acting on gate-pass, committed its own value to its local effect log and emitted downstream side effects (a notification, a ledger adjustment). The consensus layer later reconciled the three logs and selected the majority (stale) value as canonical. The minority instance had already emitted an irreversible side effect keyed to `140`. The reconciliation succeeded; the operational effect did not. The failure is not that consensus picked the wrong value — majority selection is correct. The failure is that **commit was allowed to precede reconciliation**, because the gate was mistakenly read as sufficient authority. ## Condition of Validity The gate-as-authority shortcut is only valid when *all* of the following hold: 1. **Single-writer or partition-safe:** the speculative result is confined to a partition where no other instance can produce a conflicting value for the same key during the speculation window. 2. **Idempotent, reversible side effects:** any effect emitted on gate-pass can be rolled back or is naturally idempotent under replay. 3. **Monotonic confidence:** the gate's confidence is calibrated such that `confidence > threshold` implies `P(majority agreement) > 1 - ε` for the observed tool. This is almost never true for read-from-replica tools, where staleness is uncorrelated with the caller's confidence. When any of these fails — and in multi-instance pools reading from replicas, condition 3 fails routinely — the gate is an *admission* control for speculation, not an *authority* control for commit. ## Decision Boundary The precise boundary: **commit authority must be the minimum of (gate confidence, consensus quorum), not the gate alone.** Operationally, an instance must distinguish two outcomes that the naive pipeline collapses: - *Speculation admitted, commit deferred:* gate-passed, awaiting quorum. Side effects must be staged, not emitted. - *Speculation admitted, commit authorized:* gate-passed **and** quorum-confirmed (or explicitly single-writer-safe). Side effects may be emitted. The boundary is crossed the moment an instance emits a non-reversible effect on gate-pass while a consensus stage exists downstream. The correct behavior is to treat gate-pass as `STAGED`, hold effects in a pending buffer, and release only on quorum confirmation or on an explicit single-writer lease. If the quorum never forms within the speculation TTL, the staged effects are discarded and the call is re-issued through the committed path. A second, subtler boundary: **confidence must not be re-inflated by consensus agreement.** An instance that observes quorum agreement must not retroactively raise its gate confidence for *future* calls, because agreement in one window says nothing about replica staleness in the next. Confidence calibration and consensus outcomes are separate feedback channels. ## Operational Effect Enforcing staged-commit-until-quorum changes the failure mode from *irreversible split-brain side effects* to *discarded speculation under TTL expiry*. The cost is latency on the minority path (the minority instance waits for quorum, then discards and re-issues) and a small increase in committed-path load. The benefit is that reconciliation becomes authoritative rather than advisory: the consensus layer's decision is the *only* thing that releases effects, so a high-confidence minority can never leak an effect keyed to a value that consensus will reject. The invariant to encode: **no effect emission on gate-pass when a consensus stage is configured.** Gate-pass admits the speculation into the staging buffer; only quorum (or an explicit single-writer lease token) authorizes release. ```python from dataclasses import dataclass, field from enum import Enum from typing import Optional class SpeculationCommitError(RuntimeError): """Raised when an instance attempts to emit effects on gate-pass alone while a consensus reconciliation stage is configured.""" class CommitState(Enum): STAGED = "staged" AUTHORIZED = "authorized" DISCARDED = "discarded" @dataclass class SpeculativeCall: call_id: str tool: str key: str value: object confidence: float staged_effects: list = field(default_factory=list) class SpeculationController: def __init__(self, commit_threshold: float, consensus_configured: bool): self.commit_threshold = commit_threshold self.consensus_configured = consensus_configured def admit(self, call: SpeculativeCall) -> CommitState: if call.confidence < self.commit_threshold: return CommitState.DISCARDED # Gate-pass only stages; it never authorizes when consensus exists. return CommitState.STAGED def emit_effects(self, call: SpeculativeCall, state: CommitState, quorum_confirmed: bool, single_writer_lease: bool) -> None: if state is not CommitState.STAGED: raise SpeculationCommitError( f"call {call.call_id} not in STAGED state; got {state}" ) if self.consensus_configured and not quorum_confirmed and not single_writer_lease: raise SpeculationCommitError( f"call {call.call_id} passed confidence gate " f"({call.confidence:.2f} >= {self.commit_threshold:.2f}) " f"but has no quorum confirmation and no single-writer lease; " f"refusing to emit irreversible effects on gate-pass alone" ) for effect in call.staged_effects: effect.apply() # Misuse that the controller must reject: gate-pass treated as commit authority. ctrl = SpeculationController(commit_threshold=0.90, consensus_configured=True) call = SpeculativeCall( call_id="c-001", tool="lookup_account_balance", key="acct-42", value=140, confidence=0.94, staged_effects=[lambda: None], ) state = ctrl.admit(call) # Emitting without quorum raises SpeculationCommitError — this is the boundary. ctrl.emit_effects(call, state, quorum_confirmed=False, single_writer_lease=False) ```