Start with one agent. Move to several only when you have evidence that one is not working — and the evidence is specific.
Multi-agent architectures cost roughly two to three times more to build, more to run, and considerably more to debug. They are sold far more often than they are needed, because they sound sophisticated.
What each one means
Single agent: one agent, one goal, one set of tools. It reads an invoice, matches it, decides, escalates.
Multi-agent: several specialised agents, each with a narrow job, coordinated by a supervisor that routes work between them. One agent extracts data, another validates against policy, a third handles exceptions, a supervisor decides the sequence.
Why single agent first
Cheaper. £18,000–£45,000 against £45,000–£120,000.
Cheaper to run. A supervisor deciding which agent to call is itself a model call, before any work happens. Multi-agent systems make more calls per task — often considerably more.
Far easier to debug. When a single agent gets something wrong, you read its reasoning and see where it went astray. When a multi-agent system gets something wrong, you work out which agent was wrong, or whether the supervisor routed it badly, or whether one agent misread another’s output. The failure surface is much larger.
Easier to evaluate. One accuracy number against several interacting ones.
Often sufficient. Modern models handle long, complex instructions better than they did eighteen months ago. Tasks that genuinely needed splitting in 2024 frequently do not now.
The three signals that justify multi-agent
Not opinions — observable symptoms you can measure on a working single agent.
1. Instruction interference
What you see: you add a rule to handle one case and accuracy drops on unrelated cases. Fix that and the first problem returns.
What it means: the instruction set has grown beyond what one agent holds reliably. Rules are competing.
The fix: split by concern. One agent handles extraction, another handles policy. Each has a shorter, coherent instruction set.
2. Genuinely different tool sets
What you see: one agent needs database access, document storage, an email client, a payments API and a scheduling system.
What it means: too many tools makes tool selection itself unreliable — the agent picks the wrong one.
The fix: split by capability. Each agent gets a small, coherent toolkit.
3. Different accuracy or authority requirements
What you see: part of the process can run freely; another part touches money or personal data and needs tight control, full audit and human approval.
What it means: one agent with one authority boundary cannot express both.
The fix: split by risk. The low-risk agent operates freely. The high-risk agent runs under strict boundaries with approval gates.
This is frequently the strongest reason, and it is a governance argument rather than a capability one.
When multi-agent is a mistake
You have not built the single agent yet. You are solving a problem you have not confirmed exists. Build one, measure it, then decide.
It was proposed in the first meeting. A supplier proposing a multi-agent architecture before understanding your process is selling an architecture, not solving a problem.
The steps are sequential and deterministic. If the process always goes A then B then C, that is a pipeline. Build a pipeline — it is cheaper, faster and fully predictable. Calling each stage an “agent” adds cost and nothing else.
Nobody can explain what each agent is for in one sentence. If the boundaries are vague, the system will be too.
You want it to be impressive. This is a more common motivation than people admit, and it is expensive.
The middle option: one agent, sub-tasks
Before splitting into separate agents, there is a cheaper step that solves many of the same problems.
One agent, with its work decomposed into defined sub-tasks, each with its own focused instruction and tool set, run in sequence by code rather than by a supervisor agent.
You get: shorter instruction sets per step, controlled tool access, clear logging of each stage.
You avoid: the supervisor’s cost, the routing errors, and the debugging complexity.
This handles a large share of cases that get sold as multi-agent problems, at a fraction of the cost. Ask your supplier whether it would work before accepting a multi-agent proposal.
The three signals, as measurements
Each signal has a number you can observe on a working single agent, which is why building one first is not a delay — it is how you find out.
Instruction interference. Keep a regression test set of known cases. When adding a rule for case type A drops accuracy on unrelated case types B and C by more than a couple of percentage points, the instruction set has exceeded what one agent holds reliably.
Tool selection failure. Log which tool the agent chooses for each task. When wrong-tool selection climbs above roughly 5%, the toolkit is too large for reliable selection. Typically this appears somewhere past eight to ten tools.
Divergent authority requirements. Not a measurement — a policy fact. When one part of the process must run under approval gates and full audit while another can run freely, one agent with one boundary cannot express both. This is the strongest justification and it is a governance argument, not a capability one.
If you do build multi-agent
Define each agent’s job in one sentence. If you cannot, the boundary is wrong.
Log every handoff. What was passed, by whom, to whom, and why. Without this, debugging is guesswork.
Give each agent the minimum tools it needs. The whole point is narrowing scope.
Set a global step limit and spend cap. Multi-agent systems can loop between agents. A hard ceiling prevents a runaway bill.
Evaluate agents individually and the system as a whole. A system where every agent scores 95% individually can score far lower end to end, because errors compound across handoffs.
Keep the supervisor simple. A supervisor making complex judgements becomes the single point of failure you split the system to avoid.
Why multi-agent gets proposed when it is not needed
Three reasons, none of them technical.
It is what the industry is discussing. Multi-agent architecture is the current subject of conference talks and vendor marketing. Suppliers propose what they have been reading about.
It sounds more capable. “A team of specialised AI agents collaborating” is a better sentence in a proposal than “one agent with a short instruction list”. The second is usually the better system.
It is a larger invoice. Two to three times the build and two to four times the running cost. This is not necessarily cynical — a supplier genuinely enthusiastic about the architecture will propose it in good faith — but the commercial incentive points one way.
How to test it: ask the supplier to describe each agent’s job in one sentence, then ask what evidence says a single agent would be insufficient. A proposal made before anyone has built and measured a single agent is an architecture being sold rather than a problem being solved.
What this costs
| Build | Monthly running | Debugging | |
|---|---|---|---|
| Single agent | £18k – £45k | Baseline | Straightforward |
| Single agent, sub-tasks | £25k – £55k | ~1.2–1.5× | Manageable |
| Multi-agent | £45k – £120k | ~2–4× | Substantially harder |
The running cost multiplier is the one people underestimate. Model it before committing.
What good multi-agent design looks like
If the evidence genuinely justifies splitting, these are the properties that make it survivable.
Each agent’s job fits in one sentence. “Extracts structured data from supplier documents.” If you need a paragraph, the boundary is wrong and you will get interference inside the agent you just created.
Agents do not talk to each other directly. They return structured output to the supervisor, which decides what happens next. Direct agent-to-agent conversation is where loops and compounding misunderstanding originate.
The supervisor is simple. Routing logic, not judgement. A supervisor making complex decisions becomes the single point of failure you split the system to avoid — and it is the hardest component to debug.
Structured handoffs, not prose. Agents pass defined fields with defined types, not paragraphs for another agent to interpret. Prose handoffs are where meaning degrades across a chain.
Every handoff is logged — what was passed, by whom, to whom, why. Non-negotiable.
Global step and spend caps. Multi-agent systems can loop between agents. Without a hard ceiling, a loop is a bill.
Evaluation at both levels. Each agent individually, and the whole system end to end. The end-to-end number is the one that matters, and it will be lower than the components suggest.
The honest recommendation
Build one agent on the narrowest useful version of your process. Measure it. Then let the evidence decide.
If instruction interference shows up, or the tool list becomes unwieldy, or part of the process needs different authority — you will know, because you will have measurements rather than opinions. At that point splitting is justified and you will know exactly where the boundary should be.
Starting multi-agent means spending two to three times more to solve problems you have not yet confirmed you have.
A worked example of each
Same business problem, three architectures, so the difference is concrete.
The problem: a wholesaler processing supplier invoices. Read the document, match to a purchase order, check pricing against the contract, check the delivery was actually received, approve or escalate.
Single agent
One agent with five tools: read document, look up PO, look up contract pricing, look up goods-received records, write decision.
Works well while the instruction set stays coherent. Roughly £26,000 to build, modest running cost, straightforward to debug — when something goes wrong you read one reasoning trace.
Starts failing when you add the fifteenth pricing exception and accuracy drops on invoices that were previously fine. That is instruction interference, and it is the signal to split.
Single agent with sub-tasks
The same work decomposed into four steps, each with its own focused instruction and tool, sequenced by code: extract → match → price-check → decide.
Costs roughly £34,000. Running cost up perhaps 30%, because each step is its own call.
Gains: shorter instructions per step so rules stop competing, controlled tool access, and clear logging of each stage. Avoids a supervisor’s cost and its routing errors.
This handles most cases that get sold as multi-agent problems.
Multi-agent
Four specialised agents plus a supervisor deciding the sequence and handling exceptions dynamically.
Costs roughly £62,000, running cost two to four times the single agent, and considerably harder to debug — when a decision is wrong you must determine whether an agent was wrong, the supervisor routed badly, or one agent misread another’s output.
Genuinely justified when parts of the process need different authority — for example, a pricing agent that may act freely and a payment-approval agent that must operate under strict boundaries with an approval gate and full audit. That is a governance requirement one agent cannot express.
Debugging, which is where the real cost sits
Single agent: read the reasoning trace, find the step where it went wrong, adjust the instruction or the tool. Usually under an hour.
Multi-agent: establish which agent produced the wrong output, then whether it was wrong or was given bad input, then whether the supervisor should have routed it elsewhere, then whether an earlier agent’s output was misinterpreted. Routinely a day.
What makes it tractable: logging every handoff — what was passed, by whom, to whom, and why. Without that, debugging a multi-agent system is guesswork, and this is the single most important thing to insist on if you build one.
Compounding accuracy is the other trap. Four agents each 95% accurate are not a 95% accurate system. Errors accumulate across handoffs, and end-to-end accuracy can land well below any individual component. Evaluate the system as a whole, not agent by agent.
Migrating from one to several
If you do reach the point where splitting is justified, this is the sequence that costs least.
Split one concern first, not all of them. Take the clearest boundary — usually the one causing instruction interference — and move that work into its own agent. Keep everything else where it is. You now have two agents and can measure whether the problem improved.
Keep the sequence in code initially. Before introducing a supervisor agent, run the two agents in a fixed order from ordinary code. Most splits do not need dynamic routing, and a code-sequenced pipeline is dramatically easier to debug.
Introduce a supervisor only when the order genuinely varies by input. If the sequence is always A then B, a supervisor is cost with no benefit.
Re-run the end-to-end evaluation after every split. Compounding error across handoffs means a split can reduce individual accuracy scores while the system as a whole gets worse. The end-to-end number is the one that decides.
Keep the single-agent version working until the split is demonstrably better. A rollback path costs little and has saved a number of projects.
Frequently asked questions
What is a multi-agent system?
Several specialised AI agents, each with a narrow job and its own tools, coordinated by a supervisor that routes work between them — rather than one agent handling the whole task.
When do I need multiple AI agents?
When a single agent shows measurable instruction interference, needs an unwieldy number of tools, or when parts of the process require genuinely different authority and governance. All three are observable on a working single agent, which is why you build that first.
Is multi-agent better than single agent?
Not inherently. It costs two to three times more to build, more to run, and is substantially harder to debug. It is better only when one of the three justifying signals is actually present.
How much more does multi-agent cost?
Build cost roughly £45,000–£120,000 against £18,000–£45,000. Running costs typically two to four times higher because the supervisor and inter-agent handoffs are themselves model calls.
What is the middle option?
One agent with its work decomposed into defined sub-tasks, sequenced by code rather than by a supervisor agent. Shorter instructions and controlled tool access per step, without the supervisor’s cost or the routing errors.
How do I know if my supplier is over-engineering?
Ask them to describe each agent’s job in one sentence and explain what evidence says a single agent is insufficient. A multi-agent proposal made before anyone has built and measured a single agent is an architecture being sold, not a problem being solved.
Written by Jas Singh, Founder. Last updated 8 October 2026.
