Agents fail at orchestration, not reasoning
A 5-agent pipeline of 90%-accurate agents produces 59% end-to-end accuracy. Most production agent failures are tool design, context collapse, and error propagation, not the model.
When an AI agent fails, the instinct is to blame the model. The model reasoned incorrectly. The model misunderstood the task. If we just used a smarter model, it would have worked.
This instinct is wrong often enough to be dangerous. After building production agent systems, the pattern that emerges is almost the inverse: the model is rarely the problem. The orchestration layer almost always is.
The math that should sober you up
Suppose each agent in your pipeline has 90% task accuracy, which is good, better than most production systems achieve. Chain three of them together and your end-to-end accuracy is 0.9 × 0.9 × 0.9 = 73%. Chain five and you're at 59%. The model hasn't gotten worse. The architecture amplifies every small failure by compounding it.
This is not a theoretical concern. It is the dominant failure mode of multi-agent systems in production. And it means that adding more agents to a pipeline, to give it more "intelligence", can make it less reliable, not more.
Each agent hands its output to the next. A chain only succeeds if every link does.
Where failures actually live
An AI agent has layers: interface, orchestration, reasoning, tools, memory, and execution. The model sits in the reasoning layer. But the failures almost never originate there.
Tool design is the most common culprit. A tool with an ambiguous description gets called in wrong contexts. A tool that returns unstructured output gets misinterpreted. A tool that raises exceptions without graceful handling terminates the pipeline. The model is not the problem; you gave it broken tools and expected it to improvise.
Memory management is the second most common. Agent context windows fill up. Conversation history grows until the model loses track of the original task. Intermediate results crowd out the instructions. The model starts producing coherent-sounding responses to a question it's no longer actually reading correctly.
Error propagation is the third. When a step produces a bad result and the next step accepts it as ground truth, the error doesn't stay local. It contaminates everything downstream. Without explicit validation between steps, a single wrong intermediate output can drive the entire pipeline into a confident nonsense conclusion.
The fixes are architectural, not model-level
The single most impactful change you can make to an unreliable agent is not to upgrade the model. It is to add validation gates between steps.
After each agent produces output, check it. Not with the LLM; with deterministic rules where possible. Did it produce valid JSON? Did it call a tool that exists? Did its output satisfy the constraints the next step requires? If not, reject and retry, or escalate to a human. Most agent pipelines are missing this entirely because it feels like bureaucracy. It is not bureaucracy. It is load-bearing structure.
| Failure type | Root cause | Fix |
|---|---|---|
| Tool misuse | Ambiguous tool descriptions; LLM guesses intent | One tool per action; crystal-clear docstrings; JSON schema validation on inputs |
| Context collapse | History grows until instructions are buried or truncated | Sliding window + explicit task summary; re-inject the goal at every N steps |
| Error propagation | Bad intermediate output accepted as ground truth | Deterministic validation gates between steps; reject-and-retry before proceeding |
| Runaway loops | Agent keeps calling tools without making progress | Per-session token budget + step count hard limit; escalate to human on breach |
| Cascade hallucination | One fabricated fact compounds across agents | Ground each agent's input in retrieved sources; never pass raw LLM output as input to the next step without verification |
Start with two agents, not ten
The correct architecture for any agent system is the simplest one that solves the problem. Two agents, one that generates, one that reviews, is often enough. The reviewer's job is to catch what the generator missed, not to add intelligence. That separation alone reduces the effective error rate because errors must survive independent review.
Before you add a third agent, prove that the two-agent system has hit a ceiling. That ceiling is almost always in the quality of the tools or the clarity of the task decomposition, not in the number of agents.
The teams that build reliable agent systems aren't using the best models. They're using boring, well-understood models with excellent tool design, tight validation, explicit memory management, and human escalation paths for anything that matters. The model is the easy part. The plumbing is where the work is.
That failure taxonomy lines up almost exactly with what's now being documented in the wild:
Why Do Multi-Agent LLM Systems “still” Fail? A new study explores why Multi Agent Systems are not significantly outperforming single-agent. The study identifies 14 failure modes multi-agent system. Multi-agent system (MAS) are agents that interact, communicate, and collaborate to Show more
References: ReAct: Reasoning + Acting (Yao et al., 2022), LangGraph, Anthropic Agents