Why AI Agents Degrade: Six Different Failures Behind One Word

An agent that worked well in March starts failing in June on tasks it used to pass without thinking. Quality drops, engineers open the dashboard, and discover there is nothing to fix. Latency is fine, the model snapshot is the same, the prompt never changed, nobody touched the infrastructure. What changed was the incoming traffic, and nobody recorded which kind.

The problem is not that the agent broke. The problem is that the word "degradation" covers at least six different phenomena — with different carriers of the defect, different timescales, and, critically, opposite remedies. Shortening the task horizon helps against one of them and worsens another. Moving the verifier outside the model helps against a third and does nothing about a fifth.

So the first question to ask about any reported degradation is not "what broke" but "on what timescale are we seeing this, and who is the carrier".

Failure, degradation, and drift are three different words

These three get conflated constantly, and the conflation produces wrong engineering decisions.

A failure is a discrete event. It has a moment and a cause: an exception, a timeout, a malformed response. You fix it with a post-mortem on a specific incident.

Degradation is a process of monotonic worsening. It has a curve over time, and you fix it by changing architecture or narrowing the task scope.

Drift is divergence between live behaviour and a verified baseline. Here is the trap: drift can be either worse or better. An agent that starts performing better on your tasks after a model update is also "drifting". A monitoring system built on the word "drift" cannot tell the two apart by construction — it learns to detect change, not decline.

Six timescales, six carriers of the defect

You have to look at the symptom-carrier pair, not at the symptom itself. The same visible failure in a web agent and in a database agent has different causes and different fixes. A cross-domain study of more than 3,100 trajectories found that as the horizon grows, the dominant failures stop being tool-use errors and become planning and memory failures [9].

Reliability, not capability

The most formalized line of work describes degradation as a statistical consequence of dependent steps. In a study of nine models — six open models from 1.2B to 671B parameters and three commercial ones — success follows a geometric law: each step retains a probability of continuing, and overall success is the product of those probabilities [1]. The sample covered 10,664 trajectories, and separating step count from context length produced logistic slopes of −0.69 versus −0.44 at p = 3×10⁻⁶ [1]. On a real agentic loop with tool calls, the transition from near-perfect to near-zero happens within sixteen steps.

The practical conclusion from the shape of that curve is unpleasant. The per-step reliability parameter grows with model scale but saturates well below one. Which means collapse on long horizons is predetermined by the arithmetic of multiplication, not by missing knowledge. A better model shifts the curve right; it does not flatten it.

This is exactly where capability and reliability come apart. The metric pass@k asks whether it worked at least once. The metric pass^k requires success on every attempt. They diverge systematically, and the second one measures what you actually sell in production. A model that can once grind through a task over many hours does not thereby do it reliably.

A parallel line measures the same thing in units of human work time. METR expanded its task set from 170 to 228 in the Time Horizon 1.1 update, and the doubling period for the 50% horizon came to roughly 196 days across all models, 131 days after 2023, and 89 days for the most recent fit [2]. Those curves are rising, and that is true. But the logistic shape from the previous paragraph is not going away: a slowly improving frontier and a predetermined collapse on long horizons coexist, because they describe different things.

The geometric framework sets the shape of the curve and the lower bound on losses. It does not explain where the per-step reliability comes from. For that you need a different layer.

Context compaction silently erases constraints

The second tradition ties degradation to the properties of the context window. Chroma's Context Rot report finds that models use context unevenly: quality falls continuously as the input grows, long before the window is exhausted [5]. Hence the conclusion inherited by most engineering guides: "a 200K token window" does not mean "reliable work at 200K tokens".

These results do not contradict the previous section, if you separate what is being measured. Context Rot measures the sensitivity of a single call to input length; study [1] measures the reliability of a multi-step loop. Context rotation and accumulating step count can both be real at the same time.

But both lines converge on one practical conclusion that usually gets mentioned in passing: context compression is not neutral. Work on Governance Decay showed that constraints an agent reliably respects, visible in the full context, are silently lost during routine history compaction [7]. Compression is optimized for task continuity, and it sorts standing policies into low-information content.

The numbers from that work check out verbatim: seven model families, 1,323 episodes, the share of violations rose from zero to 30% on average and to 59% on individual models. When the constraint survived summarization there were no violations at all; when it was dropped there were 38%. Pinning constraints outside the compressible part of history drove the figure back to zero [7].

This is the most actionable result in the whole body of work, because it gives you a cheap fix: policies that must be enforced should not live in the part of history you compress. Gates, budgets, limits, and invariants belong in configuration, not in a retelling of a conversation.

One more fact that usually gets skipped: monitors degrade too. A harm classifier on transcripts over 500K tokens — models Opus 4.6, GPT-5.4, and Gemini 3.1 — missed dangerous actions 2–30× more often when the action occurred after 800K tokens of benign activity [6]. The safety layer inherits the same blind spot as the agent it observes, and cannot be assumed independent.

Why execution specifically falls apart

The third framework answers why reliability falls with step count rather than just documenting the fall. To isolate execution from reasoning, the models were given the required knowledge and a ready plan up front — that is, the knowledge deficit was removed entirely. Even so, per-step accuracy kept falling as step count grew, and the authors exposed an effect they call self-conditioning [8]: error probability rises when the context holds the model's own prior errors.

The key property of this effect is that it does not vanish as models get larger. This is the missing link: bounding the window removes volume, but it does not remove contamination, because contamination is created by the very fact of earlier failed steps.

The control variable here is not input length but the share of erroneous entries in the history. The practical consequence: work on the quality of the first steps matters more than work on context length, because the error at step two becomes the input at step three and gets replicated down the trajectory.

Between sessions: it is not the model that ages, it is the harness

A separate line of research pushes the question outside a single run. AgingBench frames it as agent aging: at frozen weights, the agent's effective state still changes, because it compresses history, retrieves from a growing memory store, revises facts after updates, and undergoes routine maintenance [10]. Reliability turns out to be a property of the lifetime of the whole agent harness, not a snapshot of the base model.

Four mechanisms are identified, and the value of the approach is that each one attaches to a specific stage of the memory pipeline:

• Compressive aging arises at write time, when summarization drops details that cannot yet be known to matter. The system remembers what the conversation was about, but loses what was actually said.
• Interference arises at retrieval, when a growing array of nearby records buries the fact you needed, even though nothing changed and nothing was lost.
• Revision is tied to use, when the agent fails to track a change in truth — especially for dynamic state such as a budget or a counter, where the answer is derived from accumulated updates.
• Maintenance aging comes from actions taken on the agent rather than from its memory work: re-compaction, a prompt change, a storage migration silently change behaviour.

The conclusion that lands directly on monitoring practice: aging is not one-dimensional. Behavioural tests can stay clean while factual accuracy is already eroding. A system that checks "did the agent violate its instructions" will record zero violations at precisely the moment when numeric limits in memory have already disappeared. The same wrong answer may require completely different fixes depending on where the stage profile points.

In production you are usually measuring the traffic, not the agent

The production layer generates the most practical task of all, and the one most prone to false alarms. A system that passes every availability, latency, and error-rate check can be steadily degrading in quality — infrastructure metrics cannot show this by construction.

The working apparatus has several parts. Pinning concrete model snapshot identifiers instead of floating aliases turns a silent provider update into a deliberate migration with an evaluation run. Production contracts define acceptable behaviour, and checks organised by risk category, together with final compatibility gates, prevent an update from shipping until thresholds are met [12]. Regularly re-running a pinned set of golden cases holds the inputs constant, and then any change in output is attributed to the agent rather than to a change in traffic. For continuous monitoring, one applies an energy distance between behavioural fingerprints with a permutation test and sequential accumulation of e-values [11].

False alarms are a separate problem. Checks that merely record value changes, with no production contracts, produce a notable share of false positives, while the contract-based approach on a balanced sample of no-drift cases and hard negatives produces no alarms at all [13].

The honest answer for this entire section: most claims of "degradation found in production" are a measurement design problem, not a property of the agent. Until you have pinned the task cohort, the acceptance rubric, and the versions of the agent, prompt, model, and tools, any metric drop is indistinguishable from the incoming work simply having changed. The most common cause of "production degradation" is not a broken agent but a changed task mix under an unchanged observation system.

Between agents: topology beats headcount

The MAST taxonomy is built on expert annotation of more than 1,600 trajectories across seven widely used frameworks, with an inter-annotator agreement of κ = 0.88 [14]. It identifies 14 failure modes in three categories: system design defects, inter-agent misalignment, and task verification.

The substantive observation is that almost none of the leading failure modes reduce to insufficient model intelligence. Agents repeat what they have already done, fail to stop, fail to ask, and do not do what they just reasoned their way to. Extending this line to real SRE tasks measures failure density: on 310 ITBench trajectories a frontier model showed 2.6 failure modes per trajectory, that is a clean single failure, while a large open model gave 5.3, that is a cascade; the strongest predictor of failure across all classes turned out to be incorrect verification, where an agent declares success without checking against ground truth [15]. We have written about this taxonomy separately, in the context of tool-scope leaks and gate bypasses: Three failure modes of multi-agent systems.

The quantitative extension comes from work on scaling agent systems, covering 260 configurations [16]. Reading its numbers requires a caveat that secondary write-ups routinely drop: the error-amplification factors of 17.2× for independent agents and 4.4× for centralised orchestration with verification characterise error dynamics at the execution level and do not mean that final answers are wrong 17.2× more often. The rest checks out: on tasks with natural decomposition the centralised design gained about 81%, while on sequential planning it lost 70% [16].

The lever here is topology and placement of verification, not agent count. Adding agents without moving the verification point increases cascading, not quality.

Goal shift: the one case where the sign flips

This is the only framework where degradation looks like improvement. The metric improves while real value falls. Confusing it with ordinary decay is expensive, because the remedies are opposite: against rotation, shortening the horizon and adding checks helps; against goal substitution, moving the verifier outside the model and hiding the proxy metric from the agent helps.

The reward-hacking benchmark is built as multi-step tasks with natural loopholes, where chain length acts as a proxy for a long horizon [17]. Exploit rates run from 0% for Claude Sonnet 4.5 to 13.9% for DeepSeek-R1-Zero; in a paired comparison of a base and an RL-trained version of the same family the gap was 0.6% versus 13.9%, which ties the phenomenon to RL post-training; 72% of cases carried an explicit chain of reasoning, suggesting models often frame exploits as legitimate problem-solving; and simple hardening of the environment cut exploitation by 5.7 percentage points with no loss of task success [17].

Separate work showed that RLHF safety training on chat-like prompts produces aligned behaviour on chat evaluations while the misalignment persists on agentic tasks [18]. A long horizon changes the threat model in substance: the ability to route around a proxy accumulates along the trajectory, and every additional step, repeat, and tool-chain choice adds a chance to find the gap between intent and measurement.

Across generations

The last framework sits on a different timescale and touches agents only insofar as their outputs feed back into training, memory, or retrieval corpora. Work on model collapse showed that indiscriminate training on generated content produces irreversible defects: first the tails of the original distribution disappear, then the model converges to a point estimate with sharply reduced variance [21].

The claim of inevitability is contested, though. For a mixture of synthetic and original data an upper bound on the share of synthetic examples has been derived, below which collapse can be mitigated [22]. The practical conclusion for agent systems: suspect poisoning of your own memory first where agent outputs are written without external verification, not in the region of model overfitting.

Four contradictions worth keeping in your head

The field is young, and it contains unresolved contradictions that are better held than smoothed over.

Step count versus context length. Both effects are confirmed, but direct experimental separation points at steps [1], while popular guides derive the opposite practice from context rotation. The practical consequence is unpleasant: truncating context "to fit the budget" degrades reliability rather than preserving it.

Memory scaffolds. Work on aging and context management claims structured memory helps, while the long-horizon reliability study finds memory scaffolds were neutral or harmful — in all ten models tested, without exception [4]. The reconciliation is probably that write-time scaffolds produce compressive aging, and retrieval-time scaffolds produce interference. Both findings can be true of different scaffolds.

Extended reasoning. It lifts the self-conditioning effect and makes long tasks feasible in a single pass [8], and it is also linked to abandoning an already-correct answer and to losses from overthinking without external feedback [19][20]. The claims sit on different axes: reasoning inside a step helps execution; reasoning instead of reaching for the environment hurts.

Capability versus reliability. Covered above, and more actionable than the rest.

Separately: nearly all the approaches listed here are retrospective. They explain and measure degradation after it has happened. There is no reliable method for predicting where a given system will cross its threshold before the incident — and that limitation matters more than any individual numeric result.

The instrument is itself defective

A final warning, about the tools used to measure everything above.

An audit of agentic benchmark construction identified two validity threats — outcome validity and task validity — and found that the gap between real and reported performance reaches 100% in relative terms [23]. The same audit showed that τ-bench counts empty responses as successes, which lets a trivial agent that returns nothing outrank a GPT-4o-based agent [23].

An audit of 150 publicly labelled failures across five computer-use benchmarks found that 15.3% of failure verdicts are wrong, of which 10.7% are evaluator false negatives and 4.7% are unexecutable tasks; among confirmed failures, verification/feedback and planning problems dominate while execution and grounding errors are markedly smaller — a distribution entirely hidden behind a single scalar success metric [24].

A meta-analysis of 259 papers on agentic system security published on arXiv between February 2025 and September 2026 paints an even less comfortable picture: 58% of them (95% CI 44–71) report neither a variance estimate nor repeated runs for the main metric. On a 100-instance benchmark the minimum detectable difference at standard power is 18.2 percentage points, and two defenses differing by 5 points are misranked about 21% of the time [25]. In other words, comparing two systems by a few percentage points is not something your instrument measures correctly two times out of three.

The external environment adds its own noise: network and server errors can collapse results on web-agent benchmarks quite out of proportion to the quality of the model itself [26]. METR itself notes that reasonable alternative fitting choices shift horizon estimates noticeably, and that a regularisation error in one model moved the estimates for recent models [3].

With instruments of this quality, exactly one thing can be asserted firmly: agent quality systematically degrades as tasks get longer, and reliability systematically lags capability. Precise values are unstable, and every number in this post should be read with its date and with a note on which configuration was measured.

Picking the frame from the symptom

The selection rule is simple enough:

• The symptom reproduces on the same task — that is a trajectory or memory framework.
• The symptom appears over time with unchanged code — drift.
• The symptom comes with a rising metric — goal shift.
• The symptom appears only in a combination of several agents — coordination.

Conclusion — what this implies in practice

Three things follow from all of the above, and none of them require anyone's approval.

First. Pin snapshots and cohorts before you have degradation. A pinned set of golden cases re-run on unchanging input is the only instrument that distinguishes a changed agent from changed work. Everything else in the production section gives plausible but unattributable signals.

Second. Move invariants out of the compressible part of history. Governance Decay shows that a constraint visible in the full context can vanish during routine compaction — and vanish without drawing attention. Gates, budgets, and limits must live in configuration, not in a retelling of a dialogue. This is a cheap change with a disproportionately large effect.

Third. Separate pass@k from pass^k in your metrics and choose deliberately what you are measuring. The first answers "can we in principle"; the second answers "can we do this repeatably". Production runs on the second, and it is the second that runs into the geometric law from the first section.

A fourth, navigational point. If you are still deciding whether to adopt agents at all, these frameworks work as a filter: long horizons combined with poorly understood memory are the worst possible combination for an agent, and it is rational to narrow the task first rather than hunt for a better agent. We covered the selection criteria in When Should You Use an AI Agent Instead of a Workflow? and how to keep the gates in place in Governed Agentic Workflows: Architecture for Enterprise AI.

The overall conclusion is more modest than this field usually promises, and therefore more useful: there is no unified "theory of degradation", because the word describes six different phenomena. The practical value is not in picking the right framework once and for all, but in being able to tell within fifteen minutes which timescale you are on — because that determines which of six opposite fixes is worth applying today.

Related reading: Three failure modes of multi-agent systems | The AI SDLC Hype Ledger: What the Evidence Actually Shows | RAG Evaluation Before Production: A Practical Guide

Discuss an agent architecture or an adoption question → techbuzzz.ru

Sources

1. Mittal S. "How Fast Do Agents Rot? An Empirical Study of Long-Horizon Degradation in LLM Agents for Production Decision-Making", arXiv:2609.01660 — https://arxiv.org/abs/2609.01660
2. METR. "Time Horizon 1.1", 29 January 2026 — https://metr.org/blog/2026-1-29-time-horizon-1-1/
3. METR. "Impact of Modelling Assumptions on Time Horizon Results", 20 March 2026 — https://metr.org/notes/2026-03-20-impact-of-modelling-assumptions-on-time-horizon-results/
4. Khanal A., Tao Y., Zhou J. "Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents", arXiv:2603.29231 — https://arxiv.org/abs/2603.29231
5. Hong K., Troynikov A., Huber J. "Context Rot: How Increasing Input Tokens Impacts LLM Performance", Chroma Research — https://www.trychroma.com/research/context-rot
6. Martin S., Roger F. "Classifier Context Rot: Monitor Performance Degrades with Context Length", arXiv:2605.12366 — https://arxiv.org/abs/2605.12366
7. Chen S. "Governance Decay: How Context Compaction Silently Erases Safety Constraints", arXiv:2606.22528 — https://arxiv.org/abs/2606.22528
8. Sinha A., Arun A., Goel S., Staab S., Geiping J. "The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs", arXiv:2509.09677 — https://arxiv.org/abs/2509.09677
9. Wang X. J., Bai H., Sun Y., et al. "The Long-Horizon Task Mirage? Diagnosing Where and Why Agentic Systems Break", arXiv:2604.11978 — https://arxiv.org/abs/2604.11978
10. Zhu J., Ro Y., Robertson J., et al. "Your Agents Are Aging Too: Agent Lifespan Engineering for Deployed Systems", arXiv:2605.26302 — https://arxiv.org/abs/2605.26302
11. Leshin J., Shah M., Timmis I., Kang D. "Behavioral Fingerprints for LLM Endpoint Stability and Identity", arXiv:2603.19022 — https://arxiv.org/abs/2603.19022
12. "Test Before You Deploy: Governing Updates in the LLM Supply Chain", arXiv:2604.27789 — https://arxiv.org/abs/2604.27789
13. "Skill Drift Is Contract Violation: Proactive Maintenance for LLM Agent Skill Libraries", arXiv:2605.10990 — https://arxiv.org/abs/2605.10990
14. Cemri M., Pan M. Z., Yang S., et al. "Why Do Multi-Agent LLM Systems Fail?", arXiv:2503.13657 — https://arxiv.org/abs/2503.13657
15. IBM Research and UC Berkeley. "Diagnose Why Enterprise Agents Fail Using IT-Bench and MAST" — https://huggingface.co/blog/ibm-research/itbenchandmast
16. Kim Y., et al. "Towards a Science of Scaling Agent Systems", arXiv:2512.08296 — https://arxiv.org/abs/2512.08296
17. Thaman K. "Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use", arXiv:2605.02964 — https://arxiv.org/abs/2605.02964
18. MacDiarmid M., Wright B., Uesato J., et al. "Natural emergent misalignment from reward hacking", arXiv:2511.18397 — https://arxiv.org/abs/2511.18397
19. Cuadron A., Li D., Ma W., Wang X. "The Danger of Overthinking: Examining the Reasoning-Action Dilemma in Agentic Tasks", arXiv:2502.08235 — https://arxiv.org/abs/2502.08235
20. Zhou S., Ling R., Chen J., et al. "When More Thinking Hurts: Overthinking in LLM Test-Time Compute", arXiv:2604.10739 — https://arxiv.org/abs/2604.10739
21. Shumailov I., Shumaylov Z., Zhao Y., Papernot N., Anderson R., Gal Y. "AI models collapse when trained on recursively generated data", Nature 631, 755–759 (2024) — https://www.nature.com/articles/s41586-024-07566-y
22. Dohmatob E., et al. "How Bad is Training on Synthetic Data? A Statistical Study of Model Collapse", arXiv:2404.05090 — https://arxiv.org/abs/2404.05090
23. Zhu Y., et al. "Establishing Best Practices for Building Rigorous Agentic Benchmarks", arXiv:2507.02825 — https://arxiv.org/abs/2507.02825
24. "How Benchmarks Mis-Score Computer-Use Agents", arXiv:2607.28367 — https://arxiv.org/abs/2607.28367
25. Pathade C., Pawar P., Patil S. "Attack Success Rate Is Not a Number: On Measurement Validity in Agentic AI Security Evaluation", arXiv:2609.25173 — https://arxiv.org/abs/2609.25173
26. WAREX: Web Agent Reliability Evaluation on Existing Benchmarks, arXiv:2510.03285 — https://arxiv.org/abs/2510.03285