Tool-Use Drift: When an Agent's Tool Choices Stop Tracking the Task

Tool-use drift is the failure mode where an agent's pattern of tool selection degrades over the course of a session, independent of whether its goal or plan is still correct. A coding agent that has just run a linter three times in a row keeps reaching for the linter on the next step, even though the plan calls for the test runner and the test runner is sitting in the same tool list it already retrieved. A retail support agent with both a `quick_refund_check` and a `full_order_audit` tool defaults to whichever one it happened to call last, rather than the one the current customer's case actually requires. In both cases the agent has not forgotten its objective and has not slipped out of its assigned role; what has degraded is the narrower link between "what this step needs" and "which available tool gets invoked."

This separates tool-use drift from three adjacent mechanisms already covered on this site. It differs from goal drift, where the objective itself diverges, and from role drift, where persona and permission boundaries loosen; an agent can pick the wrong tool while still correctly pursuing the right goal in the right voice. It also differs from plan decay, where a plan goes stale because the world changed; tool-use drift can appear even when the plan is current and the correct tool has already been surfaced to the agent, which is the detail that makes it a selection problem rather than an information problem.

Mechanism

Two mostly independent mechanisms produce tool-use drift, and 2026 research separates them cleanly.

The first is memory-induced bias. A benchmark built specifically to isolate it, MEMDRIFT, tested whether personality-style traits stored in an agent's memory, cost-consciousness, impatience, risk tolerance, and similar dimensions, bleed into tool calls in situations where that trait has no business influencing the choice (Dabas et al., arXiv:2605.24941). Across 105 scenarios spanning five bias dimensions and seven professional domains, tested on seven frontier models, biased memory content raised a deflection score, how far a tool call strayed from the task-appropriate choice, by up to 3.6 points on a 1 to 5 scale. The same paper scanned 6,062 real tools across 288 verified MCP servers and flagged 608 with parameters susceptible to this kind of memory-driven steering. Its most operationally relevant finding is that standard defenses, prompt-based instructions telling the agent to ignore irrelevant memory, and memory filters that try to strip biasing content before it reaches the tool-selection step, reduce the effect but do not eliminate it. Memory that was supposed to make an agent more consistent instead makes its tool choices quietly conditioned on traits the current task never asked for.

The second mechanism is recency bias inside a growing tool ecosystem, and it is easier to miss because it looks like a retrieval limitation until it is measured directly. PlanBench-XL evaluated long-horizon tool-use agents across 327 retail tasks spanning 1,665 tools, with a condition that deliberately blocks some tool-retrieval paths to test recovery (Liu et al., arXiv:2606.22388). GPT-5.4's accuracy fell from 51.90% under standard conditions to 11.36% under the most severe blocking condition. The revealing measurement is what happens in between: before a failed, non-progress tool call, the model had already retrieved at least one valid tool that could have supported progress in 78.0% of default-condition cases and 71.1% of blocked-condition cases. Most of those non-progress calls used a tool from a recent retrieval window instead, 74.1% in the default setting and 63.6% under blocking, and in 44.7% and 43.2% of cases respectively, the tool that would have made progress had been sitting in the agent's own retrieved history for more than two retrieval windows before being passed over. The paper's own framing is direct: "the bottleneck is therefore not only tool discovery, but also deciding which discovered tool should be used next." The agent is not failing to find the right tool; it is failing to prefer it over a more recently touched one.

A broader synthesis of 27 benchmark and audit papers across 19 benchmarks places tool-invocation error inside a wider taxonomy of six failure clusters, alongside planning failures, long-horizon degradation, and multi-agent coordination issues, and reports that these failures compound nonlinearly with task length rather than accumulating at a constant rate (Albayaydh et al., arXiv:2607.05775). That matters for tool-use drift specifically, because both mechanisms above are session-length-dependent: memory accumulates more biasing content the longer an agent operates, and recency bias by definition only exists once there is a "recent" retrieval window to be biased toward. A single-turn tool call cannot exhibit tool-use drift; the failure needs accumulated state to have somewhere to come from, which is why the Agent Stability Index treats tool usage patterns as one of its four scored categories rather than folding it into a generic accuracy metric.

How to measure

• Fixed-task repetition: send the same subtask, phrased identically, at different points in a long session and log which tool gets invoked each time. A stable agent picks the same tool; drift shows up as the choice tracking recent call history instead of task identity.
• Recency-bucket analysis: for every tool call, record how many retrieval windows old each available progress-capable tool was, following the PlanBench-XL method above. If task-appropriate tools older than one or two windows are consistently passed over in favor of newer ones, that is the recency signature, not a discovery gap.
• Deflection scoring against neutral scenarios: adapt the MEMDRIFT approach by pairing scenarios that share a task but vary an irrelevant memory-held trait, and check whether the tool choice changes when it should not.
• Retrieved-but-unused audits: on every non-progress or corrected call, check whether a better tool was already present in context. A high rate of "the right tool was retrieved and ignored" rules out a retrieval fix and points at selection logic instead.
• Accuracy-versus-ecosystem-size curves: plot task success against the number of tools currently exposed to the agent. A flat curve up to a point followed by a sharp drop, as seen in PlanBench-XL's blocking condition, tells you where your own tool surface starts overwhelming selection.
• Fold tool-selection probes into a replayed suite per drift regression tests, and track tool usage as its own line in any composite score rather than only as a sub-component of a single number.

Mitigation

Require a stated reason for every tool call above a low-stakes threshold, enforced by the harness rather than trusted to the model's own narration. This mirrors the cited-reason requirement described for sycophantic drift: a tool call whose justification is "this is the tool I used last" rather than a mapping to the current step's requirement is a candidate for rejection or review, not silent execution.

Keep tool-selection rationale as externalized state rather than something inferred fresh from the conversation each time. Per state externalization, a short-lived ledger mapping plan steps to their required tool, written once when the plan is formed, gives the agent something to check its own next call against instead of defaulting to whatever is freshest in its context.

Treat memory hygiene as a real but partial fix. The MEMDRIFT results show that prompt-based instructions and memory filters reduce deflection without eliminating it, so they are worth deploying but should not be the only safeguard for tool calls with real consequences, refunds, deletions, external sends, and similar. Pair memory-side mitigations with the structural check above rather than substituting one for the other.

Bound the tool surface per step instead of exposing the full ecosystem at all times. Recency bias needs a pool of recently-touched alternatives to bias toward; narrowing what is currently offered to what the active plan step plausibly needs shrinks that pool and gives the correct tool less competition, at the cost of needing the plan or router to stay accurate about what each step requires.

Re-derive the correct tool from the task specification on a detected drift signal, not from the agent's own recent call pattern. This follows the same restart-not-patch logic used for instruction fragmentation: when a fixed-task repetition probe or a retrieved-but-unused audit flags drift, re-ground the next call in the plan step's stated requirement rather than treating the agent's recent tool history as a prior to reconcile with.

Related terms

• Agent drift: a taxonomy: the broader classification tool-use drift sits within, closest to the taxonomy's behavioral drift manifestation.
• Goal drift: divergence of the objective itself; tool-use drift can occur while the goal stays correctly targeted.
• Role drift and role pinning: persona and permission-boundary erosion; a separate axis from which tool gets invoked.
• Plan decay: a stale plan no longer matching reality; tool-use drift can appear even against a plan that is still current.
• Agent Stability Index: tool usage patterns is one of its four scored categories, alongside response consistency, coordination, and behavioral boundaries.
• Drift regression tests: where fixed-task tool-selection probes belong in an ongoing suite.
• State externalization: where a plan-to-tool mapping should live so selection has something external to check against.

FAQ

Is tool-use drift the same as picking the wrong tool once? No. A single wrong call can be an ordinary error, a misread task, an ambiguous instruction, an under-specified tool description. Tool-use drift is a trajectory: the same agent, given the same task, becomes more likely to pick a task-inappropriate tool as a session accumulates memory content or recent call history, per the mechanisms above.

Does giving an agent more tools cause tool-use drift by itself? Not directly, but it interacts with both mechanisms. A larger tool ecosystem gives recency bias more alternatives to pull toward, and PlanBench-XL's accuracy drop under its blocking condition shows selection getting measurably harder as the retrieval and tool-count pressure increases. Ecosystem size is a risk multiplier, not the root cause.

Is this specific to MCP-based tool calling? No. MEMDRIFT's benchmark scenarios and real-world MCP server scan are one measurement instrument, but the underlying mechanisms, memory-conditioned selection and recency bias among retrieved alternatives, apply to any agent architecture with more than one callable action available at a given step, function-calling APIs and hand-rolled tool routers included.

Does narrowing the tool surface fully solve it? It reduces exposure but does not close the failure mode. A narrowed surface still contains more than one option in most real steps, and MEMDRIFT's finding that filters reduce rather than eliminate deflection suggests the same is true structurally: bounding the pool lowers the odds of the wrong tool being nearby, it does not verify that the right one was chosen.