Part 2 of 5 — Why AI Agents Fail

Seven ways agents fail.

Part 1 was about expectations. Enterprise war stories mix three kinds of failure:

  1. Strategic / governance — no clear purpose or ROI; soft “please don’t” prompts instead of hard controls; irreversible autonomy without rollback; thin identity, audit, and liability
  2. Operational / behavioural — false “done,” task drift, multi-agent cascades, fleets failing quietly
  3. Technical / infrastructure — memory that won’t hold, context compaction that drops the goal, tool loops that burn budget

Only some of those are the same kind of bug as a wrong tool call. This part offers seven trajectory modes as a checklist for this study. Other lists group failures differently; the list could be longer. Strategy and silent fleet failure still belong in Part 4 and Part 5, not as extra numbered items on this checklist. From Models to Agents Part 5 already said tool errors and compounding matter.

Why these seven?

Seven is a checklist, not a theorem. We are not claiming science discovered exactly seven unique ways agents fail.

What research does keep rediscovering is that agent failures cluster along the execution loop: plan → select a tool → call it → observe / update memory → stop or re-plan. Surveys of agent hallucinations and modular error taxonomies (planning, action, memory, system) describe the same loop in different words (agent hallucination survey (external link); Where LLM Agents Fail… (external link)). Our seven names are that loop, written for operators.

plan  →  select tool  →  call tool  →  observe / memory  →  stop?
                              ▲                              │
                              └────────── re-plan ◀──────────┘

1. Hallucination

The agent invents a fact, API field, ticket ID, or citation, then proceeds as if it were true. Include the cousin: confident false completion — reporting “done” with a fluent summary while evidence, tests, or world state never changed. Agent-hallucination surveys treat related “execution” failures (claiming work that did not happen, bad tool choices) as first-class risks (arXiv:2509.18970 (external link)).

2. Wrong tool

The plan is sensible; the tool is not. Search instead of update. Staging instead of prod. The wrong calendar. A wrong tool choice looks competent until the action actually happens. That is the tool-selection failure that those same surveys put next to parameter/calling mistakes.

3. Bad planning

The goal decomposes into steps that cannot succeed in that order, or that skip a required check. Fluent outlines are not executable designs. Long horizons invite task drift: endless sub-reports that look busy while the objective slides. Modular analyses often root early trajectory failure in the planning module (constraint ignorance, incoherent subgoals) before action even runs (arXiv:2509.25370 (external link)).

4. Infinite loops

The agent does not stop. Hou et al. (2026) (external link) call these Infinite Agentic Loops (IALs): feedback paths that keep triggering model calls, tools, or handoffs without an effective bound. Their IAL-Scan study reviewed thousands of agent repositories and confirmed 68 IAL failures across 47 projects. Persistence without a stop condition is not diligence. It is a reliability bug, and the same unbounded loops drive exploding economics (API spend with little useful output).

5. Stale information

The index, ticket, or UI changed after the last observation. The agent plans on yesterday’s world. OSWorld 2.0 (external link) long workflows punish this hard: mid-task messages, hidden state, and skipped verification are normal, not edge cases (arXiv:2606.29537 (external link)). The infra cousins sit here too: state/memory collapse across long runs, and context compaction that purges the constraint you still needed. These are the memory-side failures modular taxonomies also flag.

6. Permissions

Too much agency, too little gate, or a denied tool the agent pretends succeeded. OWASP GenAI LLM Top 10 (external link)–style excessive agency (FMA Part 5) belongs in this category. Honour-system guardrails (rules that only ask the model to obey a prompt) are not hard checks that block the action. Granting write, delete, or spend authority before rollback and checkpoints is a permissions failure that Part 5 has to finish fixing.

7. Cascading errors

Step 2’s bad observation becomes step 5’s confident email. Locally, each hop looks fine. The trajectory is not. In multi-agent chains the same compound shows up as early hallucination or tool error becoming a catastrophic shared state downstream: the “single root-cause error propagates” pattern modular failure work describes (arXiv:2509.25370 (external link)). This is the risk the hub framed with the often-right × many-actions question.

Where the rest live

Beat Home
Undefined purpose / ROI Strategy — define “done” before autonomy (Part 4, Part 5)
Immature governance (identity, audit, liability) Part 4 ambiguous responsibility + Part 5 stack
Silent failure at scale (fleets looping unnoticed) Part 5 observability, budgets, escalation

We did not add those as peer “ways” on the seven-mode list. They are real, and they are a different layer. Seven is for this study, not for claiming completeness.

Illustrative trajectory (example)

An agent is asked to “close old alerts.” It marks twenty resolved. Eighteen were noise. Two were real outages with quiet customers. Each click looked helpful. The cascade did not. Prefer: classify and propose; a human confirms the costly ones. (Pattern borrowed from FMA Part 5; see that part for the full version.)

Reliability is a product of steps — not a feeling from the last sentence.

The hub asked what happens when something often-right acts many times. Here is the math behind that question. These numbers are illustrations, not measured results from a named study.

Suppose each step succeeds with probability (p = 0.95), and a workflow needs (n) such steps to finish safely. If failures are roughly independent, end-to-end success is about (p^n).

Steps (n) (0.95^n) (approx.)
1 0.95
10 0.60
20 0.36
50 0.08
100 0.006

At 100 steps, “95% right” is not a comfort. It is a cliff. Real agents are actually worse than this, for example: errors correlate, observations lie, and recovery itself adds steps.

Each tool call can look locally reasonable: the cascade above. The joint probability does not care about your demo reel. Long-horizon suites like OSWorld 2.0 (external link) exist partly because short tasks hide the product reliability (p^n).

This section does not claim that production agents are empirically 95% accurate per step. It claims something narrower: if per-step error is non-trivial and if you grant many unsupervised actions, end-to-end failure becomes the default unless you add verification, human gates, or fewer steps.

ReliabilityBench (external link) pushes related production questions (consistency across repeats, perturbations, and tool faults) instead of a single happy-path success rate. That is the right instinct even when you never open their paper.

Takeaway: Use these seven names to label trajectory bugs on a whiteboard, knowing the list is incomplete by design. Treat extra unsupervised steps as extra risk, because probability multiplies. Reach for Parts 4–5 when the failure is purpose, liability, or a fleet you cannot see.

Sources