Agent drift: why long-running AI agents lose the plot
Key takeaway
AI agent reliability is the consistency of an agent's output across repeated runs of the same task. It fails primarily because each run assembles context differently, retrieval order, memory state, and tool outputs vary, so the model diverges even at temperature zero, where one study measured up to 15% accuracy variation and a 70-point best-to-worst gap. Treating this as model randomness leads teams to tune temperature; treating it as a context engineering problem leads them to pin retrieval order, freeze context assembly, and measure with pass@k instead of pass@1.
You run your agent on a task. It works. You run the exact same task again to be sure, and it fails: different tool calls, a different plan, a different answer. Nothing in your code changed, the prompt is byte-for-byte identical, and you set the temperature to zero. This is not a bug you introduced. It is an AI agent reliability problem, and its root cause is almost never where teams look first.
Agent reliability is the consistency of an agent’s output across repeated runs of the same task, as opposed to its performance on any single run. The instinct is to blame the model’s randomness and reach for the temperature dial. That instinct is mostly wrong. The dominant, controllable source of run-to-run variance is that each run assembles a different context around the same prompt. Fix the context assembly and most of the variance disappears. Keep tuning temperature and it will not.
Agent reliability measures whether the same task produces the same outcome when you run it again, not whether the agent is capable on average. A Penn State and Comcast research team measured this directly and found accuracy variations of up to 15% across naturally occurring runs of identical prompts, with a gap between best-possible and worst-possible performance of up to 70 percentage points. Capability and reliability are different axes: an agent can be strong on average and still be a coin flip on any given run.
That distinction is the whole point. Most benchmarks and most internal “it works” judgments report a single run, which is one sample from a distribution the team never looks at. An agent that succeeds 90% of the time and one that succeeds 55% of the time can both show you a green checkmark on the run you happened to watch. Reliability is the shape of the distribution, and for production systems the shape matters more than the mean.
Agent reliability and agent drift are different failure modes that get conflated because both make agents behave unpredictably. Drift is degradation within a single long run: as context accumulates over dozens of steps, attention dilutes and the agent slowly deviates from its goal, role, or plan. You watch drift happen inside one execution. Reliability is variance across separate executions: you run the same task twice from a clean slate and get two different results.
The two interact but have different fixes. We covered the within-run problem in agent drift: why long-running AI agents lose the plot, where the mitigations are re-anchoring, role pinning, and periodic replanning. Reliability is a between-run problem, so its fixes target what varies from one run’s starting conditions to the next. If you only ever run a task once, you will see drift but never notice unreliability. If you run it a hundred times, unreliability is the first thing that shows up.
Most agent variance originates in the context assembled around the prompt, not in the model’s sampling. The visible prompt is a small fraction of what the model actually reads. Everything else, the retrieved documents, the memory state, the accumulated tool outputs, the order all of it arrives in, is assembled fresh on each run, and small differences there cascade into completely different trajectories. The table below separates the sources by who controls them.
| Variance source | What changes between runs | Who controls it |
|---|---|---|
| Provider non-determinism | Batching, GPU kernels, MoE routing shift token probabilities | The inference provider |
| Retrieval order | Same documents returned in a different rank order | Your retrieval layer |
| Memory state | What the agent remembers from prior sessions differs | Your context engineering |
| Tool output timing | A tool returns stale, fresh, or reordered data | Your tools and their inputs |
| Plan branching | An early divergence compounds into a different path | Emergent from all of the above |
The critical insight is in the right column. Only the first row is genuinely outside your control. Retrieval order, memory state, and tool output shaping are all context engineering decisions, and they account for far more variance than the provider layer does. When a retrieval call returns the same five documents in a different order, the lost-in-the-middle attention curve means the agent effectively reads a different context, and one early divergence in which document it trusts is enough to send two runs down entirely different paths.
Setting temperature to zero reduces sampling randomness but does not make an agent deterministic, because non-determinism enters below the temperature setting. The Penn State and Comcast study ran five leading models at temperature zero and still measured large swings: GPT-4o varied by 44 percentage points on a college math task across ten runs (88% on its best run, 44% on its worst), and Mixtral-8x7B varied by 72 points (75% versus 3%). These were identical inputs at the setting that is supposed to be deterministic.
The variance comes from layers the temperature dial never touches. Inference providers batch requests together, and the composition of a batch affects floating-point accumulation order. Mixture-of-experts models route tokens to different experts depending on load. Hardware and kernel versions differ across the fleet serving your requests. None of this is exposed to you, and all of it moves the output distribution. Then, in an agentic loop, this base-layer jitter gets amplified: a single token difference early in a long run changes a tool call, which changes the next observation, which changes everything downstream. Temperature zero narrows one source of noise and leaves the rest untouched.
Reliability cannot be measured with a single run, so pass@1 is the wrong metric for agents. A 2026 reliability-science framework for long-horizon agents argues that pass@1 systematically misrepresents capability precisely because it reports one draw from a distribution: it overstates an agent that got lucky and understates one that got unlucky. The proposed fix is to treat every run as a sample and report the spread, using pass@k (success within k attempts) alongside explicit run-to-run variance.
Practically, this means running each evaluation task many times and looking at the whole distribution rather than the first green result. Two numbers matter: the pass rate across k runs, and the variance between them. A task that passes 10 out of 10 times is reliable; a task that passes 6 out of 10 is a liability you will not catch by running it once. This also reframes what “improving the agent” means. Reducing variance, tightening the distribution so runs cluster, is often a bigger production win than nudging the average up, because a narrow distribution is what makes an agent trustworthy enough to leave unattended. This is the same reason measuring context quality matters more than measuring context volume.
The durable way to improve agent reliability is to remove variance from context assembly, not to fight it at the model layer. Since retrieval order, memory state, and tool shaping are where most of the swing lives, that is where the fixes belong. Three moves do most of the work.
First, pin retrieval order. If the same query can return the same documents in a different rank order, impose a deterministic sort as the final step so the agent always reads them in a stable sequence. Second, freeze context assembly for a given task version, so that re-running a task reconstructs the identical context rather than re-deriving it from scratch each time. Third, deliver context as structured context with stable positions instead of a re-ranked blob of prose, so the model is not re-learning the layout on every call.
This is one place where the location of context changes the reliability math directly. An agent connected to a Wire container is re-supplied the same structured context on every call, drawn from a fixed container rather than a freshly re-ranked retrieval set assembled per request, which removes retrieval-order variance as a failure source before it can compound. The point is not the platform; it is that a stable context surface is a precondition for a stable agent, and any assembly that re-derives context from scratch each run is importing variance you could have designed out.
You cannot fix reliability you cannot see, so instrument the two things that reveal it. Run every critical task k times in evaluation and record the pass@k distribution, not the first result, so unreliability shows up before your users find it. Then, for the runs that diverged, log the exact context each one received and diff them: the difference is almost always in retrieval order, memory state, or a tool output, and rarely in the prompt you wrote. Teams that instrument this stop blaming the model within a week, because the diffs make the real cause impossible to miss. Reliability is not a property of the model you chose. It is a property of the context you assemble, and that is something you control.
Sources: Non-Determinism of “Deterministic” LLM Settings · Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents · The Good, The Bad, and The Greedy: Evaluation of LLMs Should Not Ignore Non-Determinism · METR: Measuring AI Ability to Complete Long Tasks Wire transforms your documents into structured, AI-optimized context containers. Upload files, get MCP tools instantly.