Skip to content

Belief Inertia After Tool-Map Drift

Belief inertia is an agent re-calling tools it has already seen invalidated, or brute-forcing the space, instead of deducing from its own map.

Belief inertia is the failure to retire an invalidated tool mapping. The agent discovered how a tool behaves, recorded it correctly, then kept executing that discarded hypothesis after the tool surface changed underneath it. The same failure has a second form: abandoning the recorded map and re-probing everything rather than reasoning about what changed.

Where this applies

Three conditions have to hold together, and they mirror the stressors a benchmark had to introduce before the failure appeared at all (Toh et al., 2026): the tool surface is genuinely mutable, the session spans several tasks so an accumulated map exists, and drift is distinguishable from a transient failure. A documented, stable MCP server inside a one-shot session meets none of them.

The pattern

Acquiring tool knowledge and exploiting it are separate capabilities, and only the first looks solved. On a benchmark that strips semantic cues from 28 tools, frontier models completed every episode while the surface stayed static, then fell to a 0.03 mean completion rate once drift, stochastic failures, and timing windows were added, from 0.93 unscrambled (Toh et al., 2026).

Neither form involves forgetting. One model kept calling an invalidated function through a repetitive seven-step loop despite empty results, varying its rationale rather than its hypothesis. A deductive recovery would have cost at most six extra calls; agents spent 5.57 to 8.94 times the optimal action budget (Toh et al., 2026). More test-time reasoning bought a more expensive brute-force sweep, never the deductive strategy.

Why it works

Externalizing tool knowledge helps because the deficit is retrieval rather than learning. The correct mapping was already in the transcript and the model failed to reason from it. A structured store injected on every step makes the map an explicit input instead of something to re-derive from a growing history, recovering 0.09 aggregate completion rate and 0.59 tasks solved under combined stressors (Toh et al., 2026).

Two design choices carry that result. Durable tool knowledge (identifier, inferred behavior, parameters, confidence) is stored separately from transient task recipes, so a drift event can invalidate one half without discarding the other. The model that recovered furthest cleared outdated mappings on detected drift while preserving task progress, reported as an emergent strategy rather than a controlled variable (Toh et al., 2026). The recorded confidence level is the field to hang an invalidation policy on, though the paper tracks confidence without analyzing how models use it.

When this backfires

  • A model-authored update policy. One model's stale tool calls rose from 2.38 to 2.76 per task once memory was added (Toh et al., 2026). An agent writing its own updates can entrench a wrong mapping in a durable store, which is worse than leaving it in a transcript.
  • Ambiguous failure signals. Drift and a timeout both present as an empty result, so invalidating on failure discards correct knowledge. The timing-window stressor returned the smallest gain of the three (0.06) (Toh et al., 2026).
  • Unbounded accumulation. A memory bank without eviction propagates errors, and stored executions that look correct can mislead as experience (Xiong et al., 2025). Pair the store with a retention policy.
  • Reading the effect sizes as production deltas. The evidence is a Python simulator with engineered drift, and simulated tool-use environments miss deployment conditions badly enough to cost roughly 40% accuracy on reward-relevant perturbations (When Simulation Lies, 2026).

Even with memory in place, agents still did not adopt the deductive recovery (12.8% of opportunities against a 10.9% random baseline, p=0.195) (Toh et al., 2026). The finding is diagnostic: it establishes what agents fail at more firmly than how to repair it.

Key Takeaways

  • Test adaptation separately from discovery. An agent that passes a tool-discovery probe tells you nothing about what it does when the surface moves under it.
  • Split durable tool knowledge from transient execution state so a drift event invalidates one without discarding the other.
  • Make the invalidation trigger explicit and external to the model's own judgement, since persistence on its own measurably increased stale calls for one model.
  • Spend the budget on a drift signal rather than reasoning effort. More reasoning bought more brute-force search and never the deduction.
  • Before building any of it, confirm your tool surface actually mutates mid-session. The reported gains come from a simulator with drift engineered in.