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 / behavioral — 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; Where LLM Agents Fail…). 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).

2. Wrong tool

The plan is sensible; the tool is not. Search instead of update. Staging instead of prod. The wrong calendar. Selection errors look like competence until the side effect lands — 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).

4. Infinite loops

The agent does not stop. Hou et al. (2026) 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 long workflows punish this hard: mid-task messages, hidden state, and skipped verification are normal, not edge cases (arXiv:2606.29537). The infra cousins sit here too: state/memory collapse across long runs, and context compaction that purges the constraint you still needed — 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–style excessive agency (FMA Part 5) lives here. Honor-system guardrails (soft prompt instructions) are not fail-closed hooks. 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). 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. (Shape borrowed from FMA Part 5 — pointer, not a rewrite.)

Reliability is a product of steps — not a vibe 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 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 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

Part 1: The illusion of intelligence
Part 3: The benchmark illusion
Hub: Why AI Agents Fail