Drift-Aware Routing: Resetting or Rerouting an Agent Before It Fails, Not After

Drift-aware routing is a dispatcher policy that reads a running agent's own measured stability, not just the task content, before deciding where work goes next: delegation is weighted toward agents whose drift score is still healthy, and an agent whose score has crossed a threshold gets reset instead of handed the next step. It is one of three mitigation strategies named in the same January 2026 simulation study that introduced the Agent Stability Index (Rath, arXiv:2601.04170), and it is the one this site has referenced by name three times without yet explaining it, because unlike the other two strategies the paper proposes, it is not something most production agent frameworks do at all today.

That gap is the reason it is worth a dedicated treatment. Episodic memory consolidation and adaptive behavioral anchoring both have obvious production analogues: summarizing old turns and re-injecting a goal statement are things every framework already does in some form, even if not framed as drift mitigation. Routing a task away from an agent specifically because its own stability score has degraded has no equivalent shipped feature in the frameworks this site has already surveyed. That absence is the actual finding here, not a footnote to it.

What the paper's version actually does

The paper's own description is specific: drift-aware routing is "modified router logic incorporating agent stability scores in delegation decisions, preferring stable agents and triggering resets for drifting agents," where a reset "involves clearing accumulated context and reinitializing from baseline prompts" (Rath, arXiv:2601.04170). Two separate actions are bundled under one name here, and the bundling matters: a *preference* adjustment changes which agent instance gets the next unit of work, a comparatively cheap, continuous decision. A *reset* discards an agent's entire accumulated context and restarts it from its original prompts, a comparatively expensive, discrete one. The router needs both to work as the paper describes it, but they fail differently, and a harness that only implements one half gets a different risk profile than the paper's combined design.

How this differs from the routing frameworks already ship

It's worth being precise about what production multi-agent frameworks route on today, because the honest answer is: task content and the model's own judgment, not a measured stability signal. OpenAI's Agents SDK implements delegation as handoffs, and a handoff is "represented as tools to the LLM," meaning the deciding agent calls a tool like transfer_to_refund_agent when it judges, from the conversation itself, that another agent should take over (OpenAI Agents SDK docs). That is an intent-classification decision made by a model reasoning about the current turn. It has no mechanism for asking "has the agent I'm about to hand this to been drifting for the last forty interactions," because nothing in that path computes or carries a stability score across turns in the first place.

This is the same gap agent stopping criteria documents one level up the stack: production frameworks are well-instrumented for resource ceilings and intent-based control flow, and essentially uninstrumented for anything that requires tracking a behavioral trend across many prior turns. A router that only ever asks "which agent handles this kind of task" cannot also ask "which agent is still trustworthy," because the second question needs a running score the first one was never built to maintain.

Reset, re-anchor, and reroute are three different moves

It is easy to conflate drift-aware routing with re-anchoring patterns, because both activate on the same signal, a drift or stability metric crossing a threshold, but they are not substitutes:

• Re-anchoring keeps the same agent and the same context, and re-injects the goal, role, and constraint set into the high-attention recent region of the window. The agent's accumulated state is preserved; only the anchor is refreshed.
• Resetting (the DAR action) discards the agent's accumulated context entirely and reinitializes from baseline prompts. Whatever the agent had learned, inferred, or tracked mid-session is gone, replaced by a clean slate.
• Rerouting (the DAR preference action) does not touch the drifting agent's state at all; it simply stops sending that agent new work and sends it to a different, currently-stable instance instead.

Re-anchoring is the cheaper first move precisely because it does not throw anything away. A reset is appropriate when re-anchoring has already failed, or when the accumulated context itself is suspected to be the problem rather than just the agent's attention to its goal, which is the same distinction context poisoning and context compaction failure modes make about contaminated versus merely degraded context: a poisoned or badly compacted window is a case where re-anchoring the same context makes no sense, because the context is the thing that needs discarding, not just re-pointing. A bare reset without that distinction risks discarding a context that was fine and only needed its goal refreshed, paying the full cost of a restart for a problem re-anchoring would have fixed more cheaply.

What the simulation measured for the strategy alone

The paper reports per-strategy figures in a table measuring "mitigation strategy effectiveness over 200 post-intervention interactions" in its simulation framework. Drift-aware routing alone is reported at a 63.0% drift reduction with Agent Stability Index retention of 89.4%. For comparison in the same table: episodic memory consolidation alone reduces drift by 51.9% with 87.1% ASI retention; adaptive behavioral anchoring alone, the paper's best single strategy, reduces drift by 70.4% with 92.5% retention; and all three combined reduce drift-related errors by 81.5%, at roughly 23% added computational overhead that the paper attributes primarily to the memory-consolidation summarization cost, not to routing (Rath, arXiv:2601.04170).

Read those numbers as what they are: outputs of a single-author simulation across modeled multi-agent workflows, not measurements from a production deployment. The paper does not report a standalone computational overhead figure for drift-aware routing, nor a numeric stability-score threshold for when a reset fires, so neither the relative cost of this strategy versus the other two, nor the exact trigger condition, should be read into the 63.0% figure. What transfers usefully from the number is the ranking, not the magnitude: in this simulation, routing on a stability score beat memory consolidation alone and came in behind anchoring alone, which is a reason to treat rerouting as a solid second-line mitigation rather than either a first resort or a discardable one.

Building a stability-gated router without the reset risk

• Compute the stability score continuously, not only when a routing decision is pending. A score that is only checked at dispatch time cannot distinguish an agent that just started drifting from one that has been degrading for fifty turns, which matters for deciding between re-anchoring and a full reset.
• Treat "prefer stable agents" and "reset a drifting one" as two independently tunable thresholds, not one. The paper bundles them into a single strategy, but a harness gains nothing by forcing the cheaper preference adjustment and the expensive reset to fire at the same score.
• Try re-anchoring before resetting, and reserve a full reset for cases where re-anchoring has already been attempted and failed, or where the context itself is suspected of being poisoned or over-compacted rather than merely under-anchored.
• Before any reset clears accumulated context, checkpoint whatever is load-bearing per state externalization. The paper's reset is a clean discard by design; a production harness that wants the same mitigation without losing recoverable progress needs an externalized goal, plan, and fact record the reset does not touch.
• Log every routing decision with the category that fired it, preference or reset, and the stability score at the time, mirroring the stop-category logging agent stopping criteria recommends for the same reason: without that record, you cannot later tell whether a bad outcome came from routing too late, resetting too eagerly, or the underlying stability metric itself being miscalibrated.
• Validate the router's threshold against drift regression tests before trusting it in production, the same way any pathology-based stop condition needs validation before it is allowed to take an action with real cost.

Pitfalls

• Reading the 63.0% figure as a production benchmark rather than a single simulation's projection under its own modeling assumptions.
• Implementing only the "prefer stable agents" half and calling it drift-aware routing, when the paper's strategy, and its measured effect, depends on resets actually firing for agents that cross the threshold.
• Resetting before trying the cheaper re-anchoring move, which pays a full context-discard cost for problems a goal re-injection would have solved.
• Clearing accumulated context on reset without checkpointing anything first, which turns a mitigation into its own source of lost progress.

Related terms

• Agent Stability Index: the composite score this routing strategy reads to decide preference and reset actions.
• Re-anchoring patterns: the cheaper, context-preserving alternative to a full reset, and the move to try first.
• State externalization: what to checkpoint before a reset discards an agent's accumulated context.
• Agent stopping criteria: the adjacent decision of whether to stop a run entirely, versus rerouting or resetting it mid-run.
• Context poisoning and context compaction failure modes: the cases where a reset is the right move because the context itself, not just the agent's attention to it, is the problem.
• Drift regression tests: where a router's reset threshold should be validated before it is trusted to act on real traffic.

FAQ

Is drift-aware routing the same as load balancing? No. Load balancing distributes work by capacity or latency; drift-aware routing distributes it by a measured behavioral stability signal. An agent can have full available capacity and still be the wrong one to route to if its stability score has degraded.

Do any production agent frameworks implement this today? Not as surveyed here. OpenAI's Agents SDK routes handoffs by the deciding model's own intent judgment on the current turn, with no mechanism for carrying a stability score across turns into that decision. Building drift-aware routing today means adding that scoring and threshold logic yourself, on top of whatever intent-based handoff system a framework already provides.

Does a reset lose everything an agent has learned in a session? By the paper's own description, yes: clearing accumulated context and reinitializing from baseline prompts is a full discard. That is exactly why pairing a reset policy with externalized checkpoints, rather than relying on the reset's clean slate alone, is the practical fix for the one risk this strategy otherwise introduces.

Should I reset or re-anchor first? Re-anchor first in the general case, since it is cheaper and does not discard anything. Move to a reset when re-anchoring has already been tried on that agent and failed, or when the context itself is suspected to be corrupted rather than merely under-anchored, since re-anchoring a poisoned context does not address why it became poisoned in the first place.