The 35% Problem: Why Multi-Agent AI Workflows Collapse in Production
Your AI agent gets it right 90% of the time. You chain ten of them together. Your team ships it. It fails 65% of the time.
Nobody ran the math.
The promise of multi-agent systems is composability: break a complex task into discrete steps, assign each to a specialized agent, and watch the whole exceed the sum of its parts. This works in demos. In production, compound error cascades quietly destroy that promise — not dramatically, but consistently, at a rate most teams discover only after users are affected.
The Multiplication You Didn't Do
Basic probability is unforgiving. If each agent in a pipeline has a 90% success rate — impressive, for an AI component — and you chain ten of them together, your end-to-end success rate is 0.90^10: roughly 35%. Not 90%. Not even 50%. Thirty-five percent.
The math gets worse with longer chains. A 20-step pipeline at 95% per step gives you a 36% chance of a clean run. Want 80% end-to-end reliability on a 10-step chain? Every single step needs to hit 98% individually. That's not a language model accuracy problem — that's a reliability design problem that no model update will solve.
Most engineering teams building agentic systems in 2025 and 2026 built component-level tests. They validated individual agents in isolation, reported impressive accuracy numbers, and shipped. Nobody multiplied the failure rates together before the first production incident. The framing was wrong: teams evaluated agents the way they evaluate features, not the way they evaluate distributed pipelines.
The compound failure rate isn't a flaw to be patched. It's the system's actual behavior, present from day one, invisible until the chain is long enough and the traffic high enough.
Where the Cascade Starts
Compound probability is just the floor. In practice, multi-agent systems fail in ways that aren't cleanly probabilistic, because failure in one agent changes the input to the next — and changed input rarely triggers an explicit error.
The most common failure mode isn't an agent that crashes. It's an agent that succeeds with degraded output. A code-generation agent produces syntactically valid Python that doesn't match the schema the testing agent expects. The testing agent runs, reports a vague error, and the orchestrator has no signal to distinguish "test failure" from "schema mismatch." The pipeline continues. Garbage propagates downstream until either a human notices or a user-facing system behaves badly enough to surface a ticket.
Anthropic's team described this dynamic in their Building Effective Agents guide in December 2024: agentic systems accumulate errors because mistakes early in a pipeline rarely get corrected downstream — they compound. Their recommendation was aggressive checkpointing and human-in-the-loop verification for high-stakes branches, not more powerful individual agents. The problem isn't model capability. It's pipeline architecture.
What teams actually do: build the pipeline first, add error handling later. By the time they're adding circuit breakers, the schema between agents is already implicit — undocumented, assumed, fragile. Refactoring is expensive. The system has already shipped.
Three Failure Patterns That Show Up Every Time
Across teams that have shipped agentic systems and written publicly about it, three failure patterns appear with enough consistency to name:
Schema drift. Agents produce and consume untyped text. One agent's output format shifts slightly — a field name, a nesting change, a key renamed — and the downstream agent silently misinterprets it. There's no exception. No stack trace. Just a subtly wrong result that propagates until something downstream is obviously broken. By then, identifying the source requires tracing through every agent in the chain.
Retry loops without backoff. When an agent fails, a naive orchestrator retries immediately. Under load, a single agent's transient error becomes a cascading queue backup across the entire pipeline. Teams building agentic systems for the first time frequently underestimate how fast an orchestrator amplifies a local failure. A 30-second database timeout in one agent can lock up the orchestrator for minutes and starve every concurrent pipeline run.
Missing idempotency. An agent performs a write operation — creates a file, sends an API call, updates a record — and then fails before reporting success to the orchestrator. The orchestrator retries. The write happens twice. For stateful workflows, this is a data integrity problem disguised as a reliability problem. It's also the hardest class of failure to detect, because the symptom (duplicate state) often appears far from the cause (the retry).
None of these are exotic. They're classic distributed systems problems. What's different is that teams building AI pipelines often don't have distributed systems experience, and the "it worked in the demo" phase is short — providing less warning before production exposure than traditional software development.
What Reliable Agentic Systems Actually Look Like
The teams that ship reliable multi-agent systems share one design habit: they treat failure as the default, not the exception. They design for degradation before they design for success.
In practice:
Typed contracts between agents. Every agent has a declared input schema and output schema. Not a comment in a README — a validated type enforced at runtime. Pydantic models, JSON Schema, TypeScript interfaces, whatever fits the stack. An agent that can't produce a valid output fails explicitly rather than returning degraded text that propagates. This single change eliminates the entire class of silent schema drift failures.
Idempotency keys on every state-changing operation. Each write carries a unique identifier. The downstream system checks for the key before executing. Retries become safe. This is boring infrastructure work, not AI work — and that's the point. The AI parts of the system need the same reliability guarantees as any other stateful distributed system.
Explicit failure budgets. Before a pipeline ships, the team calculates expected end-to-end reliability based on observed per-agent accuracy. They set an acceptable failure rate, build alerting around it, and define what triggers a rollback. If the budget can't be met with current per-agent accuracy, the pipeline doesn't ship until it can. This forces the compound math conversation to happen during design, not after a production incident.
Checkpoint and replay. Long pipelines checkpoint intermediate state to durable storage. A failure at step 8 doesn't require re-running steps 1 through 7. This is the agentic equivalent of savepoints in a database transaction. It also dramatically reduces the blast radius of a single agent failure.
The Question Nobody Is Asking
Everyone building multi-agent systems is asking: can we build an agent that does X? The question that actually matters in production: what happens when the agent doing X fails halfway through, and the agent after it received garbage input, and the agent before it will retry twice more?
That question doesn't have an answer in a language model. It has an answer in typed schemas, idempotency, circuit breakers, and failure budgets calculated before the system ships.
Chaining ten agents at 90% reliability is an impressive demo. It's also a 35% success rate in production. Both of those things are true at the same time. The only variable is whether your team ran the math before or after users discovered it.
Cover photo by Google DeepMind via Pexels.