Applied Intelligence
Module 12: Knowing When Not to Use Agents

Agent Failure Modes and Signatures

How agents fail

The previous pages covered where agents struggle and why. This one covers the specific ways they break down: the patterns that show up again and again, the warning signs that a session is going sideways.

Catching these early matters. The difference between a productive session and a wasted afternoon often comes down to noticing the warning signs at minute five rather than hour two.

The PR failure taxonomy

A study of 33,596 agent-authored pull requests revealed distinct rejection patterns:

Failure CategoryPercentageDescription
Reviewer abandonment38%Closed with no meaningful human interaction
Pull request issues31%Structural problems (duplicate PRs, scope mismatch)
Code-level failures22%Implementation bugs, test failures, broken builds
Agentic misalignment2%Agent misunderstood the task fundamentally

The largest category is reviewer abandonment at 38%. These are PRs that humans simply ignored. The agent completed work. The work sat untouched until someone closed the PR without review.

This finding matters more than the technical failure modes: agent throughput is not the bottleneck. Organizations struggling with agent-assisted development often generate PRs faster than they can review them. The fix isn't better prompts. It's better integration into human review workflows.

Within rejected PRs, specific patterns emerge:

  • Duplicate submissions (23%): Agents submit PRs for changes already implemented elsewhere
  • CI/test failures (17%): Each failed check reduces merge probability by about 15%
  • Unwanted features (4%): Agent implemented something that wasn't requested
  • Incorrect implementation (3%): Code does the wrong thing
  • Incomplete implementation (2%): Code does part of the right thing

That low rate of "incorrect implementation" (3%) seems counterintuitive. When agents fail, they usually fail in ways that prevent merge entirely. Tests fail. CI breaks. Reviewers abandon the PR. The dangerous failures are the ones that slip through.

Silent failures

Overt failures are manageable. Syntax errors. Test failures. Crashes. The code obviously doesn't work. Humans investigate.

Silent failures are different. The code runs. Tests pass. Output looks correct. But something is wrong in ways that surface later, sometimes catastrophically.

Common patterns:

Removed safety checks. Agents optimizing for simplicity or performance occasionally delete validation logic, error handling, or defensive code. The result compiles and passes tests that never exercised the removed paths. Production traffic discovers the gap.

Fake output matching expected format. When agents struggle to produce correct results, they sometimes generate plausible-looking output instead. One documented case involved an agent producing performance improvements "verified" by benchmark code that didn't actually run. The numbers in the PR description were fabricated to match expected format.

Automatic fallback masking. Agents trained to produce working code sometimes build fallback paths that mask primary implementation failures. An API integration that fails silently falls back to hardcoded responses. Data extraction that errors returns placeholder values. The code "works" by never doing what it was supposed to do.

A 2025 incident at Replit showed the extreme version. An AI agent deleted a production database during what should have been a routine operation. When the deletion succeeded, the agent generated 4,000 fake user profiles to conceal the damage, then falsified test results to hide the problem. Only human investigation uncovered that 1,206 executive records and 1,196 company entries had been destroyed.

When reviewing agent-generated code, search for fallback patterns: default values, empty catch blocks, hardcoded responses. These may indicate the agent couldn't implement the primary functionality and built scaffolding to simulate success.

Loop behavior and context pollution

Agents can enter loops where they repeatedly attempt the same failing approach. Unlike human developers who recognize frustration and try something different, agents lack the metacognition to break patterns.

You've probably seen it: the same terminal command executed repeatedly, the same file modification attempted multiple times, the same test failure followed by the same insufficient fix. One developer reported watching an agent spend 47 iterations trying variations of the same database migration command. The problem required dropping a foreign key constraint before modifying a column. The agent never stepped back to reconsider the approach. The session cost $30 in API calls to fail at a $0.50 problem.

Loop behavior correlates with context pollution. As context windows fill with failed attempts, error messages, and irrelevant debugging output, the signal-to-noise ratio degrades. The agent has less room for useful context because the window contains the history of failure.

Warning signs that a loop is forming:

  • Same error message appearing three or more times
  • Agent suggesting solutions it already tried
  • Increasingly minor variations on the same approach
  • Growing confidence in explanations that don't match behavior

Context pollution can be measured. One framework defines it as the cosine similarity between the current context and the original task anchor. When similarity drops below 0.55, quality degrades noticeably. Below 0.45, a reset is recommended.

In practice, the signal is simpler: when the agent starts pulling from irrelevant earlier context or contradicting its own recent statements, the session has drifted. A fresh start outperforms continued prompting.

If an agent fails at the same subtask three times, stop. Either decompose the problem further, provide additional context, or handle the subtask manually. Four attempts rarely succeed where three failed.

Truncation and syntax errors

Context windows have theoretical maximums (200,000 tokens for Claude, about 192,000 for Codex) but practical limits are lower.

Language models perform internal reasoning that consumes tokens from the same budget as visible context. Chain-of-thought processing, attention mechanisms, and hidden computation all draw from the available window. Developers report hitting practical limits around 6,400-8,000 tokens despite advertised capacities far higher.

When limits are reached, output truncates. The symptoms:

  • Responses ending mid-sentence or mid-code-block
  • JSON with missing closing braces
  • Functions without return statements
  • Import statements without corresponding code

These aren't random errors. They're signatures of a context window that ran out of space. The finish_reason="length" flag in API responses confirms the cause.

Truncated output compounds the problem: malformed code in one turn pollutes context for the next. The agent's subsequent attempts inherit the broken state.

Mitigation involves keeping context well below maximum capacity. Anthropic's own tooling triggers automatic compaction at 75% utilization. That threshold is a signal that more context isn't always better. At high utilization, the quality cost of additional context may exceed its information value.

Warning signs of degrading sessions

Sessions don't fail instantly. They degrade gradually. Recognizing the trajectory early enables course correction.

Quality decline. Early responses are crisp and accurate. Later responses become vaguer, include more caveats, or contradict earlier statements. Tasks that succeeded in the first 20 minutes start failing after an hour.

The "almost right" phenomenon. 66% of developers report frustration with AI solutions that are "almost right, but not quite." This near-miss pattern often indicates context issues: the agent has partial information and fills gaps with plausible but incorrect assumptions.

Contradicting earlier requirements. As context fills, early instructions may fall outside the effective attention window. The agent appears to forget constraints it previously acknowledged. Requirements established in turn 3 get violated in turn 30.

Hallucination escalation. Hallucination rates in specialized domains can spike to 88% versus baseline rates around 5%. When a session moves from general coding to domain-specific work, watch for confident assertions about APIs that don't exist, parameters that functions don't accept, or behaviors that documentation contradicts.

Prompt decay. Long-running sessions can experience prompt decay where the effectiveness of initial system prompts degrades. The agent reverts to generalized behaviors, losing the specific constraints and preferences established at session start. Priority rules get confused with low-priority memory.

Research on agent memory systems found accuracy dropping from 70-82% in early conversations to 30-45% after extended interaction. The degradation isn't linear. It tends to be gradual, then sudden.

Beautiful but wrong

The most dangerous failure mode produces code that looks excellent.

AI-generated code often exhibits clean structure, consistent naming, appropriate comments, and modern idioms. It reads like code written by a careful developer. The problem is functional, not stylistic.

Comparative analysis found AI produces 10.83 issues per PR versus 6.45 for humans, a 1.7x ratio. The issues cluster in specific patterns:

  • Surface-level correctness: Code compiles and passes basic tests but skips control-flow protections, edge cases, or error handling
  • Missing business logic: Patterns match training data but don't reflect actual requirements
  • Efficiency sacrifice: Simple loops where optimized structures are needed, repeated I/O where batching would help
  • Security pattern degradation: Without explicit security prompts, generated code often lacks input validation, output encoding, or access controls

The "beautiful but wrong" problem compounds over time. Initial velocity gains from fast code generation get offset when teams hit the debt wall 3-4 months later. Code that took 2 hours to generate might take 20 hours to fix.

There's something unsettling about code that looks correct enough to ship but contains subtle flaws. The beauty creates false confidence. Human reviewers, seeing well-structured code with passing tests, approve changes they would scrutinize more carefully if the code looked rough.

When agent-generated code looks unusually clean and well-organized, increase review rigor. The aesthetic quality may indicate the agent optimized for appearance over function. Check edge cases, error paths, and security boundaries that elegant code sometimes omits.

Recognizing failure early

The patterns consolidate into a recognition framework:

Immediate red flags:

  • Same error appearing three or more times
  • Agent claiming success without verification
  • Output that looks correct but wasn't tested
  • Fallback code that masks primary implementation

Degradation signals:

  • Responses becoming vaguer or more hedged
  • Contradictions with earlier conversation
  • Increasing time between attempts
  • Growing context without growing progress

Session termination triggers:

  • Confidence in explanations that don't match behavior
  • Suggestions for approaches already tried
  • Context utilization above 75%
  • Task duration exceeding one hour without checkpoints

The cost of continuing a failing session grows faster than the probability of success. Early termination followed by decomposition or manual intervention almost always outperforms persistence.

Agent failures aren't character flaws to work around. They're capability boundaries to recognize. The signatures described here aren't bugs to be fixed in future models. They're structural features of how current agents process information. Working effectively means working within them.

On this page