AI Agents in Production: What We Learned Running Multi-Agent Systems for Real Clients

Everybody's building AI agents in 2026. Almost nobody's running them in production. We are — and the gap between demo and deployment is wider than most people think.

The numbers tell the story: IDC research commissioned by Lenovo found that of the 33 AI proofs-of-concept an average organization launched, only 4 reached production — roughly 88% never made it. That's not because the technology doesn't work. It's because building an agent that works in a demo and building one that works reliably at 3 AM on a Sunday when nobody's watching are two fundamentally different engineering problems.

We've deployed multi-agent systems for five clients over the past year. Document processing pipelines, customer support triage, quality inspection workflows. Every one of them taught us something that no framework tutorial will tell you.

Why most agent pilots die

There are three killers, and none of them are the LLM.

1. Orchestration complexity

A single AI agent is manageable. Three agents coordinating on a task is a distributed systems problem. You need to decide: who goes first? What happens when Agent A needs information from Agent B, but Agent B is still processing? What if Agent C's output invalidates what Agent A already did? How do you handle partial failures?

Most demos dodge these questions by running agents sequentially on happy-path data. In production, you're dealing with concurrent execution, race conditions, timeout handling, and retry logic. It's not AI anymore — it's distributed systems engineering with all the pain that implies.

2. State management nightmares

Agents need memory. Not just within a single conversation — across tasks, across sessions, across failures and recoveries. When a multi-agent workflow fails at step 4 of 7, can you resume from step 4? Or do you have to start over? If Agent B produced an intermediate result and then crashed, is that result still valid? Can Agent C use it?

We learned this one the expensive way. Our first multi-agent deployment had no persistent state. When the system crashed (and it crashed weekly in the first month), every in-progress workflow was lost. Clients had to resubmit documents. We rebuilt the entire system with checkpoint-based state persistence. Every agent writes its output to a durable store before handing off. If anything crashes, you resume from the last checkpoint, not from scratch.

3. Error cascades

This is the one that keeps us up at night. In a pipeline, errors are contained — a bad output at step 3 doesn't affect step 1's result. In a multi-agent system, Agent A's hallucination becomes Agent B's input. Agent B processes it confidently. Agent C builds on Agent B's output. By the time a human reviews the final result, three layers of confident-sounding nonsense have compounded into something that looks plausible but is completely wrong.

We had this happen on a contract review system. The extraction agent misread a termination clause. The analysis agent built its risk assessment on the wrong clause. The summary agent presented the flawed analysis as a key finding. The client almost missed a critical contractual obligation because every agent in the chain was confident.

LangGraph vs CrewAI — what we actually use

We're not ideological about frameworks. We use both, for different reasons.

LangGraph is what we reach for on production systems. It gives us explicit control over the execution graph — which agent runs when, what state gets passed between them, where the checkpoints go, how errors are handled. It's more code, more complexity upfront, but that complexity is the difference between a system you can debug at 3 AM and one you can't. Over 400 companies run LangGraph in production now — Klarna, Uber, JPMorgan among them. That's not a coincidence. When state management matters, LangGraph is the tool.

CrewAI is what we start prototypes with. You define agents by role, give them tools, and let the framework handle orchestration. It's fast to set up, intuitive, and great for proving that a multi-agent approach can solve the problem. We've built PoCs in 2-3 days with CrewAI that would have taken a week with LangGraph.

Our pattern: build the PoC with CrewAI to validate the approach. If the client greenlights, rebuild the production system with LangGraph. The PoC proves the concept. LangGraph handles the reality.

This isn't ideology. It's engineering. Use the right tool for the phase you're in.

The human-in-the-loop pattern that saved us

The most important architectural decision we've made isn't about frameworks or models. It's about knowing when the system should stop and ask a human.

Anthropic's 2026 agent research put it well: the agents that succeed in production are the ones that know when to ask for help. We took that to heart.

Here's the concrete example. We built a document processing system with three agents: an extraction agent that pulls data from invoices, a validation agent that checks the extracted data against purchase orders, and a booking agent that records the validated data in the client's ERP.

Originally, the validation agent either approved or rejected. Binary. The problem: about 8% of the time, it was wrong — either approving bad data or rejecting good data. Both are expensive mistakes.

We added a third option: uncertain. When the validation agent's confidence falls below a threshold, it doesn't decide. It flags the specific fields it's uncertain about and routes the document to a human reviewer, pre-filled with what it thinks is correct and highlighted where it's unsure.

The error rate dropped from 8% to under 1%. Not because the model got smarter — because the system got honest about what it didn't know. The human reviews take about 45 seconds each, and they only happen for ~12% of documents. The 88% where the system is confident flow through untouched.

This pattern — high-confidence automation with human escalation for uncertainty — is now our default architecture for every multi-agent system we build.

What breaks first

After five production deployments, here's our ranked list of things that break:

1. State persistence across agent handoffs

When Agent A finishes and hands off to Agent B, the handoff is the fragile point. If the system crashes during handoff, you can lose the result. If Agent A's output format changes slightly, Agent B may not parse it. We now use a typed state schema with versioning — every agent reads and writes to a shared state object with explicit field types and validation.

2. Cost surprises

A poorly constrained agent loop is a money fire. We had one early system where the research agent was tasked with "finding relevant information." Without constraints, it made 847 API calls in a single run, chasing increasingly tangential leads. The overnight bill was $3,400 for what should have been a $2 task.

Every agent now has hard limits: maximum iterations, maximum tokens per run, maximum cost per task. If any limit is hit, the agent stops and escalates. We'd rather have an incomplete result than a surprise invoice.

3. Error cascades from hallucination

As described above — one agent's hallucination becomes another agent's trusted input. Our mitigation: every agent that consumes another agent's output runs a basic sanity check. Does this look like the data type I expect? Are the numbers in a plausible range? Is this field present? It catches about 70% of cascading errors before they compound.

When you don't need agents

This might be the most valuable thing we've learned: sometimes you don't need agents at all.

We've talked clients out of agent architectures three times in the past year. In each case, what they actually needed was a well-designed pipeline with conditional logic. If the input is type A, do this. If type B, do that. If uncertain, ask a human.

That's not an agent. That's a flowchart with an LLM at certain decision points. It's simpler to build, simpler to debug, simpler to maintain, and cheaper to run. No orchestration complexity, no state management, no error cascades.

The question isn't "can we use agents?" It's "do agents solve a problem that a pipeline can't?" Agents earn their complexity when the task requires genuine planning, adaptation, and judgment at multiple steps — when the agent needs to decide what to do next based on what it just learned. If the workflow is predictable, a pipeline beats agents every time.

The honest truth

Agents aren't magic. They're engineering. And the engineering is harder than anyone selling you an agent framework will admit. The orchestration is hard. The state management is hard. The error handling is hard. The cost control is hard.

But when the problem is genuinely complex — when it requires planning, adaptation, and judgment at multiple steps — agents deliver results that no static pipeline can match. We've seen document processing systems handle edge cases that would have required a human. We've seen triage systems route issues with nuance that no rule tree could capture.

Just make sure you're building them for the right reasons. And make sure your agents know when to ask for help.