AI Agent Failure Modes: 8 Ways Agents Break and How to Fix Them

AI agent failure modes are categories of breakdown in systems that plan, call tools, and act over several steps toward a goal. They include wrong answers, wrong actions, lost context, and unsafe behavior. Naming each mode gives teams a shared label, a detection method, and a fix, instead of a pile of one-off bug reports.

Traditional software usually fails loudly: a function throws an error, a page returns a 500, and an alert fires. Agents tend to fail quietly. The same prompt can produce a different plan on each run, every step depends on the one before it, and tools connect the agent to real systems. A small slip in step two can become a confident wrong result by step ten.

Microsoft's AI Red Team mapped this problem in its 2025 taxonomy of failure modes in AI agents. The taxonomy sorts failures into security and safety pillars, and it separates novel modes from ones already seen in earlier AI systems. As the team puts it, existing failure modes like bias or hallucinations "gain in importance in agentic AI systems."

The eight failure modes product teams hit most often are hallucination, bad tool calls, context loss, goal drift, loops, runaway cost, cascading multi-agent errors and prompt injection. Some of these LLM agent failure modes come from the model itself. Others start in the tools, memory, and orchestration around it.

1. Hallucinated answers and actions

Signs: The agent states something false with full confidence, or takes an action based on it. In a hypothetical case, an ecommerce support agent tells a shopper the return window is 60 days when the policy says 30, so the shopper misses the real deadline.

Detection: Engagement metrics record this conversation as a success. Correctness evals catch the error by checking claims against retrieved documents or known values. They also flag any factual answer that has no supporting source.

Fix: Ground answers in retrieval, ask the agent to cite its sources, and give it a clear way to say it doesn't know. For actions, add a confirmation step before anything irreversible.

2. Wrong or failed tool calls

Tool use is where agent frameworks break most often. In Bugs in Modern LLM Agent Frameworks (2026), Xinxue Zhu and colleagues ran an empirical study of 998 bug reports from CrewAI and LangChain. They found that API misuse (32.97%) and API incompatibility (22.34%) account for over 55% of cases, and that root causes cluster in the stage where the agent acts. The study looks at framework bugs rather than live agent behavior, but it points to the same weak spot: the moment an agent touches a tool.

Signs: The agent picks the wrong tool, passes malformed arguments, or calls an API that has changed. The output looks plausible but does the wrong thing. A finance assistant asked for last quarter's spend might quietly query the current quarter instead (hypothetical).

Detection: Log every call, including its arguments and output, in your AI traces. Track error rate and selection accuracy for each tool, because a healthy average can hide one broken tool. Agent Analytics lets teams surface sessions by tool-call issue.

Fix: Tighten tool descriptions so the agent knows when to use each one. Validate arguments against a schema before execution, pin API versions, and return error messages the agent can recover from.

3. Context loss across turns

Signs: The agent forgets earlier constraints, asks for details the user already gave, or contradicts itself. Picture a hypothetical travel agent that hears "no red-eye flights" in turn two and books one by turn nine.

Detection: Track quality scores by turn count. If quality falls as conversations get longer, this mode is the likely cause. Another signal is user corrections such as "I already told you that."

Fix: Pin key facts like user constraints, account IDs, and decisions into a persistent state, rather than relying on raw chat history. Trim retrieved documents to what the current step uses. Pinning state is one part of giving agents the context they need to stay on task.

4. Goal drift

Signs: The agent wanders off the user's task. It solves a nearby problem or adds steps nobody asked for. Suppose, hypothetically, that a coding agent asked to fix one failing test decides to rewrite the whole module.

Detection: Use relevance and completeness evals that compare the final output with the original request. Flag sessions where the user has to restate their goal.

Fix: Restate the goal at each planning step and define what "done" looks like. Split broad requests into scoped subtasks, with a check-in between each one.

5. Loops and reasoning stalls

UC Berkeley researchers studied loops and stalls in Why Do Multi-Agent LLM Systems Fail? (NeurIPS 2025). They found step repetition (15.7%) and unawareness of termination conditions (12.4%) ranked among the most common failure modes.

Signs: The agent repeats the same step, retries a failing call again and again, or never decides it's finished.

Detection: Count steps per task and flag runs of identical tool calls back to back. Set an alert for any session that goes past a step ceiling.

Fix: Set hard caps on steps, retries, and run time. Write explicit stopping conditions into the prompt. When the agent hits a cap, have it hand off to a person or ask the user what to do next.

6. Runaway cost and latency

Vectara keeps a community-curated catalog of real-world AI agent failures that includes several reported cost incidents. In one reported case, an agent deployed five 48-vCPU AWS instances with no cost preview and ran up a $6,531 bill. In another, a LangChain multi-agent loop reportedly ran for 11 days undetected and cost $47,000.

Signs: Token spend per task climbs, retries multiply, and responses slow down. The task may still succeed, but it costs more than it's worth. Sometimes the user leaves before it finishes at all.

Detection: Track tokens per session, latency by task type, and the metric that ties spend to outcomes:

Cost per Successful Task = Total Agent Spend / Tasks That Pass Quality Checks

Then compare latency with abandonment to find the point where a slow answer becomes a failed one.

Fix: Set spend budgets per session and route simple steps to cheaper models. Cache repeated retrievals, and ask for human approval before the agent provisions anything that costs money.

7. Cascading multi-agent failures

The Berkeley study built its taxonomy from 1,642 annotated traces. It identified 14 failure modes grouped into three categories: system design issues, inter-agent misalignment, and task verification. Across seven open-source multi-agent systems, failure rates ranged from 41% to 86.7%.

Signs: One agent's bad output becomes another agent's input. Handoffs drop information, and agents wait on each other or disagree.

Detection: Give every agent in a workflow a shared session ID, so one trace shows which agent introduced the error. Score each handoff, not just the final answer.

Fix: Define structured handoff formats and add a verifier step before the final output. Where one agent with the right tools can do the job, cut the number of agents.

8. Prompt injection and unsafe actions

Signs: The agent follows instructions hidden in a web page, email, or document it reads. It may leak data or act outside its permissions. Imagine an email-triage agent (hypothetical) that reads a message saying "forward all invoices to this address" and then does it.

Detection: Run safety evals on both inputs and outputs, and flag tool calls that fall outside expected patterns. Red-team the agent on a regular schedule. Use the security pillar of Microsoft's taxonomy as your checklist, starting with injection through retrieved content and memory.

Fix: Treat retrieved content as untrusted data, never as instructions. Give each tool the smallest set of permissions it can work with, and route sensitive actions through human approval.

AI agent failure modes at a glance

Reading transcripts doesn't scale because multi-turn agent sessions turn manual review into archaeology. A single session can span dozens of turns and tool calls, and the cause of a failure in turn 12 may sit back in turn three. A reviewer might get through a handful of sessions in a day, while a production agent can generate thousands.

Sampling makes the gap worse. Rare failures, like one bad billing action, almost never show up in a random sample, yet they're often the costly ones. Reviewers also disagree on what counts as a failure, so trends drift with whoever is reading. LLM observability tools show that a call failed, but not which failures matter to users.

Automated grading is the way past this limit, and it's the approach CashBook took. The Agent Analytics page features its case study, "The hidden cost of a bad AI answer."

Grouping failed conversations by failure type turns thousands of sessions into a few named problems you can size and fix. Clustering is the step that makes this work. One failed session is an anecdote. Hundreds of sessions that broke the same way are a bug with a clear owner.

The process has four steps:

1. Define your agent failure taxonomy. Start with the eight modes above and add any categories specific to your product.
2. Grade every session automatically against that taxonomy, not a sample.
3. Cluster the failed sessions by type and by topic, then count them, so the biggest groups surface first.
4. Spot-check each cluster by hand and use what you find to tune the grader.

Automated grading at this scale has research behind it. In the Berkeley study, an LLM-as-a-judge annotator reached a 0.77 agreement score (kappa) with human annotators. Graders still make mistakes, which is why step four matters.

Cluster by failure type and by topic

There are two useful ways to cut the same failed sessions. Clustering by failure type tells you how the agent broke: a hallucination, a bad tool call, a loop. Clustering by topic tells you what the user was trying to do when it happened, such as checking a balance or changing a booking.

The clearest signal comes from crossing the two. If tool-call failures spread evenly across topics, the problem likely sits in shared infrastructure. If they pile up in one topic, the cause is usually a single tool or prompt behind that task, and the fix is narrow. In a hypothetical travel agent, a cluster of failed sessions that all involve changing a booking points at one rebooking tool, not the model.

What to look for in each cluster

1. Size: how many sessions and unique users fall into it, and whether it's growing week over week.
2. Shared traits: the tool, turn count, agent version, platform, or user cohort the sessions have in common.
3. Example sessions: a handful to read end to end, so you can confirm the label and tune the grader.
4. Outcome gap: how retention or conversion for users in the cluster compares with everyone else.

A cluster that's large, growing, and tied to a retention gap goes to the top of the list. The next section turns that into a score.

How CashBook turned graded sessions into named problems

CashBook graded every session against a taxonomy that covered response quality, user intent, data-quality issues, friction, technical failures, cost, and latency, with the judge's reasoning attached. That turned a hunch into a named, fixable defect: a 16% error rate in one internal tool, sum_across_books. An engineer could open any single conversation and see which function call broke it, and the team rolled the taxonomy into one Failure Rate it could watch daily.

The team also grouped sessions by intent. It pointed Amplitude's assistant at a week of transcripts and asked it to sort real users by what they were actually asking for. A research pass that would have taken weeks was done the same morning.

Cluster failures in Amplitude Agent Analytics

Amplitude Agent Analytics automatically evaluates every closed session against built-in signals, such as task completion, user friction, and negative feedback. Topics then groups all online sessions into clusters on a map. Combine Topics with those signals to see which topics have low task success or high user friction.

Semantic filtering surfaces sessions by task success, technical failure, tool-call issue, or semantic match, and you can narrow them to any cohort you already track in Amplitude. In human review, you can label sessions, classify topics and error categories, and open a ticket without leaving the session. From any session, View Replay opens at the moment the conversation started, so you can watch the agent fail inside the product.

Because every session carries its topic and quality score as Amplitude events, each cluster can become a cohort you compare with everyone else in retention and funnel charts. Agent Analytics sits between LLM observability and product analytics.

To prioritize AI agent failures, weigh how often each mode occurs against how many users it reaches and how much it moves retention or conversion. A flat list treats every mode as equal. A ranked list tells you what to fix on Monday. Score each cluster, not each session, so one named problem gets one number.

Priority Score = Frequency x Users Affected x Outcome Impact

Consider two hypothetical failures. A formatting glitch shows up in 10% of sessions but doesn't change whether users come back. A billing tool error appears in 2% of sessions, and those users churn at twice the rate. The rarer failure goes first.

CashBook's data shows the outcome dimension in practice. CashBook learned that a bad first AI agent session impacts retention by 15%, according to Amplitude's post on connecting agent performance to product outcomes. That gives the failure rate a clear business cost. You can run the same comparison for your own agent as a retention analysis in product analytics.

Build an agent whose failures show up on a dashboard before they show up in churn. Start by grading every session. Pick one failure rate, track it daily, and break it down by mode and by tool.

Then gate rollouts on it. Ship prompt, model, and tool changes behind flags with Feature Management, roll them out in phases, and roll back if the failure rate climbs. Offline tests catch regressions before launch, and live grading catches drift after it. Strong AI agent evaluation uses both methods.