Here’s a temptation that catches almost everyone once they’ve built their first working agent. You get one agent doing something genuinely useful, and your mind immediately jumps to the obvious upgrade: if one agent is good, surely a whole team of them is better? A researcher agent, a writer agent, a critic agent, an editor agent, all passing work between them like a tiny company. It sounds powerful. It sounds sophisticated. And a lot of the time, it’s a mistake.
I want to give you the honest version of multi-agent systems in this article, not the hype version. They are a real and valuable tool. They are also over-reached for constantly, bolted onto problems that a single well-built agent would have solved more cheaply and more reliably. So we’ll cover what they actually are, the handful of shapes they come in, the real trade-offs, and, most importantly, how to tell when you genuinely need one.
What “multi-agent” really means
A multi-agent system is exactly what it sounds like: more than one agent, each with its own instructions and often its own tools, coordinating to solve a problem that’s split into parts. The key word is split. Instead of one agent holding the whole task in its head, you divide the task and give each piece to an agent that’s set up to be good at that piece.
Why would that ever help? Two honest reasons. The first is focus. A single agent juggling ten tools and a sprawling instruction set gets muddled, the same way a person given ten unrelated jobs at once does worse at all of them. Narrow the job and quality goes up. The second is separation of concerns. Some tasks genuinely benefit from a fresh perspective, a critic that reviews a writer’s work does better precisely because it isn’t the one who wrote it and isn’t attached to the words.
Those are the legitimate reasons. Notice that neither is “it sounds cooler.” Hold onto that.
The shapes they come in
Most multi-agent systems, under the branding, are one of a small number of patterns. Learn these four and you’ll recognise almost everything.
The orchestrator and workers pattern has one lead agent that breaks a task into pieces and hands each to a specialised worker, then gathers the results. Think of a project manager delegating to a team. This is the most common and usually the most useful shape.
The sequential pipeline passes work through a fixed line of agents, each transforming the output of the last: outline, then draft, then edit, then fact-check. It’s a factory line. Simple and predictable, but rigid.
The debate or critic pattern pairs a “doer” agent with a “reviewer” agent that critiques the work, sending it back for revision until it passes. This is where separation of concerns pays off most.
The parallel pattern runs several agents on the same problem independently and then combines or votes on their answers, useful when you want to reduce the chance of a single agent’s blind spot deciding the outcome.
Figure 1: The four common topologies: orchestrator-workers, sequential pipeline, doer-critic, and parallel. Most real systems are one of these or a small combination.
Figure 1 lays these out side by side. When someone shows you a diagram of their “sophisticated multi-agent architecture,” you’ll usually be able to point at it and say which of these four it really is.
The costs nobody puts on the slide
Now the part the enthusiastic blog posts skip. Multi-agent systems are not free upgrades. Every agent you add brings real costs, and they compound.
The most obvious is money and latency. Each agent is one or more model calls, each with its own context and its own loop. A five-agent system can easily cost five times as much and take five times as long as a single agent doing the same work. For an interactive product where a user is waiting, that’s often disqualifying on its own.
Subtler and more dangerous is error propagation. In a pipeline, a small mistake in the first agent becomes the input the second agent trusts completely. Errors don’t cancel out as they flow downstream, they accumulate. A researcher agent that misreads one fact hands that wrong fact to the writer as gospel, and now it’s baked into the final output with no one to catch it.
Then there’s coordination overhead. Agents communicate in natural language, which is wonderfully flexible and maddeningly lossy. One agent says “handle the edge cases” and the next agent’s interpretation of “edge cases” is anyone’s guess. The more hand-offs, the more room for quiet misunderstanding.
Figure 2: A three-agent pipeline showing how a small error in the first stage compounds downstream, and how cost and latency stack with each added agent.
Figure 2 makes the compounding concrete. That first small error, faint at the source, is loud by the time it reaches the output. This is the single biggest reason well-built single agents often beat sprawling multi-agent ones in practice.
The honest decision rule
So when do you actually reach for multiple agents? Here’s the rule I’d give a friend.
Start with one agent, always. Push it as far as it’ll go. Give it good tools, a clear system prompt, and the planning and reflection techniques from articles 6 and 7. A surprising number of tasks that feel like they need a team are handled comfortably by one focused agent.
Reach for multiple agents only when one of these is genuinely true. The task has clearly separable sub-tasks that need different tools or different expertise, and cramming them into one agent visibly hurts quality. Or the task genuinely benefits from an independent reviewer, where the value comes precisely from a second agent not being attached to the first one’s work. Or you need agents working in parallel on independent pieces to save wall-clock time on a big job.
If none of those applies, you’re probably adding cost, latency, and failure modes to buy yourself a diagram that looks impressive. That’s a bad trade.
A grounded example
Picture a system that writes researched articles. The naive multi-agent design has five agents: planner, researcher, writer, critic, publisher. The pragmatic version notices that planning and writing are really one coherent job best kept in one head, so it uses two agents: a research agent with search and retrieval tools whose only job is gathering and summarising sources, and a writer-editor agent that takes those summaries and produces the finished piece, with a reflection step built in so it critiques its own draft before finishing.
Two agents, cleanly separated by what tools they need and what they’re good at. Not five agents separated by job titles on an org chart. That distinction, splitting by genuine capability rather than by imagined roles, is the whole art of it.
In the next article we look at a specific and increasingly important multi-agent-adjacent pattern that ties this track directly back to retrieval: agentic RAG, where the agent decides for itself when, what, and how many times to search before it answers.