We Tried Multi-Agent. Here's Why We Went Back to a Single Agent.

For about four months, our architecture diagram looked like an org chart. There was a Planner agent at the top. Below it, a Researcher, a Coder, a Critic, and a Summarizer. Arrows everywhere. Little message queues humming between them like interns passing notes.

It looked sophisticated. It demoed beautifully. And quietly, it was making our product worse.

Last month we ripped most of it out and shipped a single agent with a good set of tools. Latency dropped by more than half. Our bug reports thinned out. And — this is the part I still find funny — the answers got better, not worse.

This is the honest story of why. Not a hot take, not a victory lap. Just what we learned spending real money and real weeks on multi-agent systems before walking most of it back.

Why multi-agent felt like the obvious answer

If you've read anything about AI agents in the last year, you know the pitch. One model trying to do everything gets confused. So you decompose the problem. You give each sub-task to a specialist agent with its own prompt, its own context, its own job. Divide and conquer. It's how we organize humans, so why not language models?

We bought it completely. And honestly, the logic isn't wrong — it's just incomplete.

Our first version was a customer-support assistant that had to read documentation, check a user's account state, and draft a reply. Splitting that into a "retrieval agent" and a "writing agent" felt clean. Each one had a tight, readable prompt. We could reason about each piece in isolation. The whiteboard loved it.

The whiteboard is not where software lives.

Where it started to fall apart

1. The agents couldn't actually talk to each other

Here's the thing nobody warns you about: agents don't share a brain. They share text.

When our Planner handed a task to our Researcher, it had to compress everything it knew into a written instruction. The Researcher then did its work and compressed that into a summary for the next agent. Every handoff was a lossy translation. By the third hop, the original user's nuance — "I already tried restarting, please don't tell me to restart" — had evaporated.

We were playing telephone, and paying per token to play it.

A single agent with the full conversation in its context window doesn't have this problem. It just knows what the user said, because it's all right there. We had spent weeks rebuilding, badly, the one thing the model already did for free: hold a coherent picture of the whole task.

2. Debugging became archaeology

When a single agent gives a bad answer, you read the transcript. Maybe ten minutes of work.

When a five-agent system gives a bad answer, you get to ask: which agent? Was it the Planner's decomposition? Did the Researcher retrieve garbage? Did the Critic over-correct a fine answer into a worse one? Did the handoff drop a field?

One genuinely bad week, we traced a wrong refund amount through four agents before finding the bug: the Planner had phrased a sub-task ambiguously, the Researcher answered a subtly different question, and every downstream agent confidently built on the mistake. No single component was "broken." The system was broken between the components, which is the worst place for a bug to live because no stack trace points there.

3. The costs were quietly absurd

Every agent re-reads context. Every handoff is more tokens in and more tokens out. Our "elegant" pipeline was making six or seven model calls to do what one well-equipped call could do.

We were paying roughly 3–4x the token cost for the privilege of more latency and more failure modes. When I finally put the cost-per-resolved-ticket on a slide next to the single-agent prototype, the meeting got very short.

4. Errors didn't cancel out. They compounded.

This was the deepest lesson, and it's just math. If each agent is 90% reliable on its piece, a chain of five of them isn't 90% reliable. It's 0.9 to the fifth — about 59%. Independent failure points in series multiply against you.

We had unconsciously assumed specialists would make the system more robust. In a pipeline, every specialist you add is one more thing that can quietly be wrong.

What actually fixed it: tools, not teammates

Most of the time, you don't need another agent. You need another tool.

We didn't need a "Researcher agent" with its own prompt and personality. We needed a search_docs function the main agent could call. We didn't need a "Database agent." We needed a get_account_status tool. The intelligence — the planning, the judgment, the synthesis — could stay in one place, with one coherent view of the problem, reaching for tools the way a developer reaches for a terminal.

A single agent with five good tools beat five agents with one tool each. Same capabilities, a fraction of the moving parts. The model already knows how to sequence tool calls and react to their results — that's the entire point of a modern agent. We'd been doing that orchestration by hand, in the slowest and most expensive way possible.

So is multi-agent always wrong? No.

I want to be fair, because the internet loves a clean villain and this isn't one. Multi-agent genuinely earns its keep when:

• The work is truly parallel. If you need to research forty companies and there's no dependency between them, fanning out forty agents at once is faster and perfectly natural. Parallelism is a real reason. Decomposition for its own sake is not.
• You need genuinely isolated context. Sometimes you want a sub-agent to chew through 100K tokens of logs and hand back only a three-line conclusion, precisely so the main agent's context stays clean. Isolation can be a feature.
• You need independent verification. A separate critic that never saw the original reasoning can catch errors a self-reviewing agent rationalizes past.

Notice the pattern: multi-agent wins when the agents are independent, not when they're a sequential assembly line. Parallel fan-out, good. Lossy relay race, bad. We had built the relay race and called it an architecture.

The boring truth about good AI systems

Here's what I wish someone had told us four months ago. The exciting-looking architecture is usually not the good one. Complexity is a cost you pay every single day in latency, in dollars, in 2 a.m. debugging sessions — and you only get to bill it back if it buys you something you genuinely couldn't get another way.

For the overwhelming majority of tasks, the best system is a single capable model, given the full context, equipped with sharp tools, and trusted to figure out the sequence. It's less impressive on a slide. It's far better in production.

We went back to a single agent not because multi-agent failed in some spectacular way, but because it kept losing the quiet competition that actually matters: which system was cheaper, faster, easier to fix, and more correct on a Tuesday afternoon when no one was watching the demo.

Start with one agent. Add tools until it's capable. Only reach for a second agent when you can name the specific thing — real parallelism, real isolation, real independent verification — that one agent genuinely cannot do. Most of the time, you'll be surprised how far one good agent gets you. We were.