Most multi-agent systems do not need to be multi-agent

The fastest way to make an agent worse right now is to turn it into a crowd. I keep seeing teams reach for multi-agent systems the moment a single agent gets a little flaky, as if splitting the work across a planner, a researcher, a writer and a critic will make the flakiness go away. Usually it does the opposite. You took one thing that was hard to reason about and turned it into four things that have to agree with each other, and now you get to debug the conversation between them too.

I want to be careful here, because I am not anti multi-agent. There are shapes of problem where it is the right call and I will get to those. But the default has drifted, and the default is wrong. Most of the systems I have looked at would be faster, cheaper and easier to fix as one well-built agent with good tools.

Where the multi-agent overhead actually comes from

The pitch for splitting agents up sounds clean. Give each one a narrow job, let them specialize, wire them together. The cost is hidden in the wiring. Every handoff is a place where one agent has to compress what it knows into a message, and the next agent has to reconstruct intent from that message. Meaning leaks at every boundary. The planner thinks it asked for one thing, the worker hears something slightly off, and nobody notices until the output is wrong in a way that is hard to trace back to a single step.

Then there is the plain arithmetic of it. Each agent carries its own context, its own system prompt, its own copy of the relevant history. A four-agent pipeline can burn many times the tokens of a single agent doing the same job, and a lot of that spend goes into agents re-explaining the situation to each other rather than into the work. You are paying for the coordination, not the result.

And the failures change character. With one agent, when something breaks, I have one trace to read. With several agents talking asynchronously, I get race conditions, an agent acting on a stale answer from a peer, and cascading mistakes where the first small error gets treated as fact by everyone downstream. The reports I have read on production agent frameworks put a large share of failures squarely on coordination rather than on any single agent being dumb. That matches what I see.

This is a distributed systems problem wearing a costume

None of this is new if you have built backends. The moment you have independent processes passing messages and acting on each other's output, you are in distributed systems territory, and all the old ghosts come with you. Ordering. Partial failure. One node trusting another node's bad data.

I spent years building on-chain indexers for a top-10 crypto and a DeFi exchange, which is about as unforgiving an async pipeline as you can pick. Events arrive out of order, a handler acts on what looks like settled state, and then the chain reorganizes under you and the thing you committed was never real. The bugs that cost me whole weekends were almost never inside one handler. They lived in the seams, in the assumptions one stage made about another. Multi-agent setups have the exact same seams, except the messages are fuzzy natural language instead of typed structs, so you cannot even rely on a schema to catch the mismatch.

That is the part that should give people pause. We spent decades building tools to make distributed coordination safe, and a multi-agent design throws away the strongest one, which is a precise contract between components. An LLM message is not a contract. It is a suggestion the next agent is free to misread.

What one good agent buys you

A single agent with a solid set of tools keeps everything in one head. It can hold the goal, see the full history of what it tried, and notice when an earlier step contradicts a later one, because it is the same context the whole way through. When it fails, I read one timeline. When I want to make it better, I change one prompt and one tool layer.

Most of what people want from multiple agents is really just structure, and you can get the structure without the crowd:

• Phases instead of personas. If you wanted a planning step and an execution step, run them as phases inside one agent, not as two agents arguing. Same reasoning thread, clear stages, no handoff to corrupt.
• Tools instead of teammates. A "research agent" is usually a search tool with a good wrapper. A "critic agent" is often a single verification call. Give the one agent sharper tools before you give it coworkers.
• Idempotent actions over retries. A lot of the chaos in agent pipelines is a retry firing twice and writing twice. I wrote about that in idempotent tool calls, and it matters far more than how many agents you run.

When multiple agents do earn it

There is a real version of this pattern and I do not want to wave it away. Multi-agent systems start to pay off when the subtasks are genuinely independent, so the agents are not constantly waiting on each other, and when the whole job no longer fits in one agent's working context without rotting. I have written before about how that rot sets in, in context rot, and it is the honest reason to split: not to add intelligence, but to give each chunk a clean, short context of its own.

So the test I use is simple. Can I cut this work into pieces that run in parallel and barely need to talk? If yes, separate agents can win, because the coordination is cheap and the isolation is worth real money. If the pieces have to keep checking in with each other to make any progress, that constant chatter is the tax, and one agent almost always comes out ahead. A clean fan-out of three independent jobs that report back once is great. A relay race where each runner has to brief the next one mid-stride is where I have watched these systems fall apart.

The boring conclusion

Start with one agent. Make it good. Give it real tools, a tight context, and actions that are safe to repeat. Reach for more agents only when you can point at work that is truly parallel and too big to hold in one place, and even then, keep the talking between them to a minimum. The number of agents is not a measure of how serious your system is. Most of the time, a smaller system that you can actually debug at 3am is the serious one.

If you are building this kind of thing and weighing how far to split it, that tradeoff is most of what I write about in my AI and agents notes, and the rest of my work is on the homepage.