Single agent vs multi-agent
Multi-agent diagrams look impressive in a deck. In production they multiply the number of places an answer can go wrong.
The short answer
Build one agent with good tools until a real constraint forces a split, such as work that must run in parallel or steps that need different permissions.
Most tasks that look like they need a team of agents need one agent and a better set of tools. Splitting adds handovers, and every handover is a place where context gets lost and nobody notices until the output is wrong.
There are honest reasons to split. Searching thirty sources at once is faster in parallel. A step that may delete records should not share permissions with a step that only reads. Those are constraints, not preferences.
Side by side
Compared on what it takes to run each one after launch.
| Dimension | Single agent | Multi-agent |
|---|---|---|
| Finding out what went wrong | One trace to read | A trace per agent, plus the handovers |
| Context | Held in one place | Passed along, and degrades each hop |
| Speed on wide tasks | Sequential | Genuinely faster in parallel |
| Permissions | One set, so the riskiest step defines it | Scoped per agent, which is safer |
| Cost per task | Lower. One conversation | Higher. Each agent re-reads context |
| Failure style | Gets stuck, or loops | One agent drifts and the rest trust it |
| Evaluation | Score the final answer | Score each step, or you cannot locate faults |
| Right when | Almost every first build | Parallel work, or separate permissions |
- TaskArrives whole and clear
- SplitEach agent gets a slice
- HandoverContext narrows here
- AssemblySomeone must reconcile results
- AnswerWrong here, blame is unclear
The middle three boxes do not exist in a single-agent design. Each one is a new way to fail.
Single agent
Where it wins
- One trace tells you exactly what happened, which turns most investigations into minutes.
- Nothing gets lost in a handover, because the whole task stays in one conversation.
- Cheaper per task, since context is not re-read by several agents in turn.
- Easier to improve. Better tools and a clearer prompt fix more problems than more agents do.
Where it hurts
- Long tasks fill the context, and quality falls as it grows.
- Everything runs in order, so a job needing thirty lookups waits for all thirty.
- One permission set covers every step, so the most dangerous action defines the blast radius.
- A very broad prompt covering many jobs becomes hard to change without breaking something else.
Multi-agent
Where it wins
- Work that is genuinely parallel finishes far sooner, such as researching many sources at once.
- Each agent gets only the permissions its job needs, which limits what a mistake can touch.
- A focused agent has a shorter, clearer prompt, and shorter prompts drift less.
- Different steps can use different models, matching cost to how hard each part is.
Where it hurts
- Debugging gets much harder, because a wrong answer may come from any agent or any handover.
- Context narrows at each hop, and the receiving agent cannot tell what it was not told.
- Cost rises, since each agent re-reads shared context to do its part.
- One confidently wrong agent poisons everything downstream, and the others have no way to know.
How to choose
- Choose one agent for a first build, always. You cannot design good boundaries before you have watched the task fail a few times.
- Choose multiple agents when work is genuinely parallel and waiting in sequence is the actual complaint.
- Choose multiple agents when one step needs permission to change data and another only needs to read.
- Choose more tools rather than more agents when the problem is that the agent cannot do something. That is usually the real fix.
- Choose a fixed workflow instead if the steps never vary. Ordinary code is cheaper, faster and does not improvise.
- Choose neither if nobody has written down what a correct outcome looks like. No architecture survives an unmeasured goal.
Agents we run in production
ZhoopZhoop
AI receptionist and parts procurement for a multi-branch auto repair business.
Read the case study →
Go4Gr8
Custom AI sparring-partner platform for leadership coaching.
Read the case study →
Little Tree Confections
n8n + AI meeting-to-action automation for an artisan bakery.
Read the case study →
Questions engineers ask about agent design
01When is splitting into several agents genuinely worth it?
When you can name a constraint that one agent cannot satisfy. Parallel speed and separate permissions are the two that hold up. Wanting a tidy diagram, or copying an architecture from a conference talk, are not constraints, and both cost you debugging time forever.
02Does a multi-agent system give better answers?
Not by itself. Answer quality comes from the tools, the context and the model, and splitting the work changes none of those. What splitting improves is speed on parallel jobs and safety through narrower permissions. Expect a better-organised system rather than a smarter one.
03How do we test a system with several agents?
Score each agent on its own job as well as scoring the final output. Without per-step scoring you know the answer was wrong but not which agent caused it, so every fix is guesswork. Build that scoring while you build the agents, because retrofitting it means recreating traces you no longer have.
04What is the most common mistake in production?
Assuming a handover carried the full picture. The second agent receives a summary, works confidently from it, and nobody notices the missing detail until a customer does. Log exactly what passes between agents and read those logs early, since the gap is obvious there and invisible in the final answer.
05Should each agent use a different model?
It is a reasonable optimisation once the system works, and a distraction before that. Cheaper models suit narrow steps like classifying or extracting; harder reasoning justifies a stronger one. Get the design right with one model first, then measure whether swapping any step actually changes your scores.
Related
- the difference between an agent and a workflow →Worth settling before counting agents.
- ai agents vs rpa →Whether this needs an agent at all.
- how to run evals on an AI agent before launch →Scoring each step as well as the answer.
- agents that act on your systems →Agents we design, build and keep running.
