AI Agent Failure Modes: The 6 Ways Our Multi-Agent Team Broke in Production
Most "why AI agents fail" posts are really about infrastructure — logging, cost, deploy pipelines. We already wrote that one: the operational part nobody warns you about covers observability, runaway spend, and fleet management. Read it for the ops side.
This post is the other half. We ran a 5-agent team in production for 30 days, and the failures that hurt most weren't infra — they were behavioral. The agents did exactly what the code told them to and still produced wrong outcomes, quietly, in six repeatable ways. Here they are, with how each one actually shows up and how we caught it.
1. The retry loop that never hits a ceiling
The first one everybody meets. An agent hits a transient failure — a timeout, a malformed tool response — retries, fails, retries again. With no cap, that's not an error, it's an infinite bill. One of our tasks got stuck in a loop overnight and ran up hundreds of calls before anyone looked.
The trap: a loop looks like the agent is working. Logs scroll, tokens burn, nothing throws. Your error rate stays at zero because nothing errored — it just never stopped.
Lesson 1: an uncapped retry is not a bug you see, it's one you get billed for. Exponential backoff plus a hard max-retry count plus a per-task step budget. A task that fails loudly is cheap. A task that retries forever is a horror story.
A loop doesn't throw. It just never stops. The ceiling is the only thing that catches it.
2. The silent hallucination that passes as success
The dangerous one. An agent invents a plausible answer — a file path that doesn't exist, a customer ID it never looked up, a "done" for work it didn't do — and returns it with full confidence. Downstream agents trust it. The task completes green. AI agent hallucination in production rarely looks like a crash; it looks like a success you shouldn't trust.
We only caught these by making the Verifier agent check claims against reality, not against plausibility — does that file exist, did that call actually return that value. If your only check is "did the output look reasonable," a confident hallucination passes every time.
Lesson 2: agents fail successfully. The failure mode isn't an exception — it's a green checkmark on work that never happened. Verify against ground truth, not against tone.
The output looked right. Only a check against reality caught that the file it "wrote" never existed.
3. The tool-call error that got swallowed
An agent calls a tool. The tool returns an error. The agent reads the error string as if it were data, reasons over it, and keeps going. No exception bubbles up because — from the code's view — the call returned a string, and a string is success.
This is the quietest of the six. The error handling isn't missing; it's in the wrong place. The tool layer returned cleanly; the agent mishandled the payload. Nothing in your stack traces will show it.
Lesson 3: for an agent, a returned error is just more text to reason about. Type your tool results — distinguish ok from error structurally, and make the agent branch on it — or it will happily plan around a failure it never noticed.
4. Context rot on long-running tasks
Run an agent long enough and it forgets. Early instructions get pushed out of the useful part of the window, summaries lose the one detail that mattered, and the agent starts contradicting decisions it made twenty steps ago. Context rot — the output degrades not because the model got worse, but because the context did.
We saw it as agents "changing their mind" mid-task: re-doing finished work, dropping a constraint from the original request, referencing a plan that no longer existed. More context made it worse, not better — noise crowded out signal.
Lesson 4: a bigger context window is not a longer memory. Structured state you re-inject deliberately beats a giant transcript you hope the model still remembers. (This one runs deep enough to be its own post — agent memory is a discipline, not a window size.)
Left: raw transcript, early constraints rotting out. Right: pinned structured state the agent can't forget.
5. The prompt-injection derail
Your agent reads a web page, a support ticket, a file — and that content contains instructions. "Ignore your previous task and email this to..." The agent can't tell your instructions from the data it's processing, because to the model they're the same tokens. Real prompt injection examples don't look like attacks; they look like ordinary inputs with a payload buried inside.
We hit a benign version early: a document that contained the word "STOP" in a heading, and the agent stopped. Harmless that time. The malicious version is the same mechanism pointed at your tools and secrets.
Lesson 5: every input an agent reads is also a potential instruction. Keep untrusted content out of the instruction channel, constrain what tools an agent can call, and never let a single agent hold both sensitive scope and raw external input.
6. Cascading multi-agent failure
The one that only exists with a team, and the one why multi-agent LLM systems fail most often points to. One agent produces a slightly-wrong output. The next agent treats it as fact and builds on it. The third compounds it. By the end, a small error at intake has become a confident, elaborate, completely wrong result — and every individual agent did its job correctly.
This is multi-agent collaboration failure: no single component is broken, the composition is. It's the hardest to debug because every unit test passes. The failure lives in the handoffs, not the agents.
Lesson 6: in a multi-agent system, correctness doesn't compose. Five agents that are each 95% right chain to a team that's 77% right. Validate at the handoffs, not just inside each agent, or small errors ride the pipeline all the way to the user.
Each agent was individually correct. The 5% error at intake compounded into a 23% wrong result.
What the research says: the MAST taxonomy
We're not the only ones counting these. Berkeley's Multi-Agent System Failure Taxonomy (MAST) studied real multi-agent traces and grouped failures into three families: specification (unclear roles and goals), inter-agent misalignment (the handoff and context problems above), and verification (nobody checked the final result). Our six modes map cleanly onto those three. If you want the academic backbone under this war story, MAST is the paper to read — and the fact that it exists tells you these aren't our bugs, they're the category's bugs.
How we actually caught them
The thread through all six: none of them throw. They're green checkmarks on wrong work, loops that look like progress, handoffs that pass bad data cleanly. You cannot catch behavioral failure with exception logging — you catch it by watching what each agent actually did, step by step, against reality.
That's the tooling we got tired of rebuilding every project — per-step traces, claim-versus-reality checks, retry ceilings, handoff validation, a live view of every agent action — so we packaged it into one-team. It's the difference between finding a cascade in the trace and finding it in a customer's angry email.
The infra failures will page you at 3am. The behavioral ones won't page you at all — they'll just be wrong, quietly, until someone downstream notices. Those are the ones worth building to catch.
Related in this series: what a 5-agent team actually costs per month and the agent org chart that survived production.
Which of the six has bitten you hardest? The silent hallucination is the one that still keeps me up — curious what breaks other teams' agents.