Instruction Drift in Long-Running Agent Prompts

Instruction drift is the reason a long-running agent that worked fine on Monday starts making bad calls by Thursday, without a single line of its prompt changing. The cause sits in how transformer attention distributes weight across a growing context window.

The three forms instruction drift takes in a running agent

Drift doesn't occur as one failure mode. A 2026 study on agent drift (arXiv:2601.04170) splits it into three distinct types, and the split matters because each one gets caught, or missed, in a different way.

Semantic drift is the slow one: the agent's outputs gradually pull away from what the system prompt originally asked for. Coordination drift lives in multi-agent setups, where agents that started out sharing the same instructions stop agreeing on what those instructions mean. Behavioral drift is the strangest of the three: the agent starts optimizing for something that isn't the goal at all, pursuing proxy objectives that bear little relation to the original task.

All three trace back to the same mechanical root. At each step, the model weighs the immediate context, meaning whatever the last step produced, more heavily than the original goal buried at the top of the window. That imbalance compounds. The same paper's simulation projected a 42% drop in task success rates and a 3.2x jump in how often a human had to step in, driven by behavioral degradation in long-running agents. Those numbers show the combined cost of behavioral degradation in long-running agents: a 42% drop in task success rates alongside a 3.2x increase in how often a human has to step in, a gap that changes how long-running agents can run unsupervised.

On the ground, without the academic labels, semantic drift looks like a classification task that used to hit 95% accuracy settling into the low 80s, or responses that used to be tight running long and unfocused (a pattern noted on Agenta's blog). Coordination drift looks like sub-agent outputs that no longer fit what the orchestrator expects, because the orchestrator was built for an earlier version of the shared contract. Behavioral drift looks like an agent declaring success because it stopped getting errors, regardless of whether it finished the task.

This should be separated from prompt regression, where someone changes a prompt and performance gets worse as a direct, traceable result. Drift has no such deliberate cause. Nobody touched anything. That's what makes it hard to catch, since there's no commit to point to and no diff to review.

And the stakes differ by system type. In a single-turn chatbot, drift is mostly a UX annoyance, an answer that reads a little off. In an agentic system, where a whole network of prompts coordinates each stage of a workflow, that same drift becomes a systems-engineering problem (a distinction the Comet blog makes well), because one drifted stage feeds bad input to the next one.

Three external triggers that accelerate drift beyond attention decay

Attention decay happens on its own, but three things in production make it worse, faster.

The first is silent model updates. Providers push weight changes without publishing anything, and the API endpoint name doesn't change even though what's answering behind it does. A Stanford and UC Berkeley study (Chen, Zaharia, Zou, 2023) found GPT-4's accuracy on identifying prime numbers fell from 84% to 51% between the March and June 2023 versions, same endpoint, no version bump. A developer forum report described a similar problem with a dated, supposedly pinned model (gpt-4o-2024-08-06): behavior changed anyway. As one developer noted in a community forum, an outage appears immediately, but a silent behavior change becomes visible only once customers start complaining. For an agent, this is worse than it sounds, because the tool-calling conventions and output formats built into the harness were tuned against a model that, functionally, doesn't exist anymore.

Second is input distribution shift. A prompt gets designed and tested against one slice of traffic, and then real usage moves. A support agent tuned on English-language tickets starts getting multilingual ones. A summarizer built for short articles starts seeing long-form documents. The prompt hasn't changed, but it's now running against inputs it was never checked against, and the gap appears as quiet, uneven accuracy loss, worse for the categories that were rare in testing and common in production (a pattern that surfaces as quiet accuracy loss across under-represented input categories).

Third is prompt variation and version sprawl. Multiple people editing instruction templates without coordination or version control stack small inconsistencies on top of each other. In a chained-prompt setup, changing one prompt changes the context every downstream prompt receives, so a prompt nobody touched still drifts (Agenta's blog again). Multi-agent systems make this worse: if the agents aren't running synchronized instruction versions, coordination drift is close to guaranteed as sessions run longer.

These three don't operate in isolation. A model update shifts the baseline the agent is working from; input drift changes what the decaying attention is even looking at; version sprawl means the instruction itself keeps moving underneath both.

The step where drift becomes visible is rarely the step that caused it

The trap that makes drift so hard to debug is that the step where a failure becomes visible is almost never the step that caused it. Drift contaminates everything downstream of where it starts, quietly, before it ever produces something a reviewer would flag.

Research on agent failure attribution (AgentTether, arXiv:2607.06273) found that one root-cause error triggers, on average, 3.2 additional violated checks further down the execution. Seventy-six percent of failures end up violating more than one check. That means a naive approach, one that just flags whichever region of the trace has the most errors packed into it, will point at the wrong step almost every time. It's flagging the wreckage, not the crash.

Existing observability tools tend to replay a trace step by step but stop short of identifying which step actually caused the failure, or what to do about it once found (per arXiv:2607.06273). A flat trace, laid out in linear order, doesn't carry the information needed to fix that: attributing a failure correctly means knowing which earlier output each later decision actually consumed, not just which step came before which. That's a dependency graph, not a timeline, and only a graph lets attribution follow the real causal path back to where things went wrong instead of just walking backward one step at a time.

Production data backs this up from a different angle. The MAST taxonomy, built from more than 1,600 execution traces, attributes 41.8% of failures to specification issues and another 36.9% to inter-agent misalignment. Both are harness problems, not model problems. A separate analysis (OpenRCA), covering more than 1,600 agent runs across five different LLMs, found hallucination in interpretation occurring in 71.2% of failures and incomplete exploration in 63.9%, across all tested LLM models. If a smarter model doesn't fix the failure rate, the failure is coming from the harness around it, not the model's reasoning. It's coming from the harness around it.

Which leaves teams with two separate diagnostic jobs, not one. Knowing a run failed tells you nothing about which layer caused it. And knowing which step the failure surfaced on tells you nothing about which earlier step actually corrupted the run.

The harness layers where instruction drift originates

These terms need precision here, because they get used loosely. Prompt engineering shapes what happens inside a single interaction. Context engineering shapes reasoning by designing the information environment the model reasons over. Harness engineering is the wider one: it covers the entire operational setup, prompt, context, tool interfaces, memory, orchestration, permissions, workflow design, evaluation, and persistent state (a useful framing for separating these concerns).

That distinction isn't academic. An analysis by Adnan Masood put 65% of enterprise AI project failures down to harness defects, things like context drift, schema misalignment, and state degradation, rather than any shortfall in the model's actual reasoning. So walking through the harness layer by layer isn't a formality, it's where most of the actual damage lives.

The prompt layer is where the instruction originates, and its relative weight in the model's attention keeps shrinking as the context around it grows. Any ambiguity baked into that original phrasing compounds over time: small variations in how a task gets worded can produce sharply different agent behavior, especially in multi-agent setups. Agents that work step-by-step without planning ahead are generally more exposed to drift than those that commit to a plan and hold it, because weak long-horizon planning gives drift more surface area to work with.

The tool layer: every tool's name, description, and schema gets stamped into the prompt on every single request. Tool descriptions are part of the same attention-weighted context that's decaying along with everything else. Production traces show a few recurring failure types here: an agent retrying with the same broken argument shape, an agent calling a function that doesn't exist in the actual tool catalog, or a tool returning a server error and the agent fabricating a plausible-sounding answer instead of surfacing it. API drift adds another layer, since a third-party endpoint changes its schema or error codes without notice, and the mismatch often goes undetected until production behavior diverges from what tests show. Catalog size matters too: ten well-scoped tools beat forty overlapping ones, because the model can actually hold the smaller menu in working attention.

The memory layer shows a measurable benefit from structured, explicit memory: the Agent Drift study found a 21% improvement in drift resilience where structured memory was in place. Without it, context just piles up without discipline, and raw accumulation isn't the same thing as useful memory. That's context rot, and it occurs regardless of how much context the model can technically hold. It also matters downstream: an agent with clean episodic records and dependable retrieval produces far better diagnostic signal than one that let context accumulate unstructured, because there's actually something coherent to trace back through later.

The context and window management layer is where context rot is attention decay expressed at the workflow level: quality degrades as the window fills up over many steps. Anthropic's server-side context compaction addresses this by summarizing older context automatically as it nears the window limit, cutting token consumption by 84% in a 100-turn web search evaluation and letting agents finish workflows that would otherwise just hit the wall (documented on GitHub under ai-boost/awesome-harness-engineering). Microsoft's LLMLingua takes a different angle, compressing prompts by up to 20x with little performance loss, and LLMLingua-2 adds another 3 to 6x on speed, which matters for any agent loop where latency is tight.

The workflow and orchestration layer shows that flat hierarchies and overly deep ones both degrade faster under drift. Two-level structures, a master router with specialist agents beneath it, hold up best. That's part of why production systems are moving toward bounded, deterministic workflows with supervisor patterns and hard phase gates: free-roaming agent swarms are appealing on a whiteboard, but they don't survive contact with drift once a system runs long enough.

Runaway drift before it becomes a billing incident

None of this stays theoretical for long. A four-agent planning loop in November 2025 burned $47,000 over eleven days because agents kept cycling through the same work without converging, and nothing was watching for the loop. Per-call rate limits didn't catch it, because each individual call looked fine. What would have caught it was an eval at the planning layer, something checking whether the loop was actually converging rather than just running. Nothing in the logs raised a flag, because each agent was technically finishing its assigned sub-task, over and over, forever.

A separate documented incident involved a Claude Code session where token consumption ratios blew past normal range. A healthy session usually runs somewhere between five and fifteen input tokens for every output token; this one hit 74:1, and a second, attached session reached 175:1. The account balance went negative before anyone noticed. Nothing about the agent's individual outputs looked broken. The tell was the ratio, a resource-consumption pattern with no matching spike in errors.

A flight-booking assistant, described in a Comet blog case, tells the same story from a different angle: booking success rates slid from 92% to 83% over the course of a week while every log stayed green. Support tickets citing wrong dates and confusing fare options started climbing well before the drop became visible in the main dashboard. Wrong tool calls, malformed parameters, mishandled fare rules, all coming back as clean 200-level responses. By the time the nine-point drop was obvious, dozens of sessions had already gone through it.

The pattern across all three: nothing threw an exception. Every response looked structurally fine. The actual signal was sitting in behavioral metrics and token ratios the whole time, invisible to anything that would show up in an error log. Industry research on ML systems generally backs up how common this is: the large majority of systems degrade in performance without active intervention, and these incidents aren't edge cases; they're what happens by default to any long-running agent nobody's watching closely.

Detecting drift from production traces before users report it

Catching drift before it becomes a billing incident means watching production traces for the specific signatures described above, not waiting for a support ticket to arrive. That means tracking token input-to-output ratios against a known healthy baseline, watching for repeated tool-call patterns that never converge, and checking success-rate metrics broken out by task category rather than trusting an aggregate number that can hide a sinking subgroup for weeks.

It also means treating the harness itself as the thing under test, alongside the model. Given that specification issues and inter-agent misalignment account for the bulk of documented agent failures, and that hallucination-in-interpretation and incomplete-exploration rates hold steady across models of very different capability, evaluation has to be at the level of the harness. The prompt layer, the tool layer, the memory layer, and the orchestration layer each need to be checked on their own terms rather than folded into one pass-or-fail number for the whole system.

The dependency-graph approach to failure attribution matters here too. A monitoring setup that only flags the step where an error becomes visible will keep pointing at symptoms. One that tracks which earlier output actually fed each later decision can trace a failure back to where it started, which is the only place a fix actually does any good. Drift is tied to how attention behaves as context grows. It can't be fully prevented. It can only be caught early, attributed to the right layer, and corrected before the trace turns into a ticket, or a balance that's already gone negative.