Guide
Multi-agent vs single agent: when to split
The industry assumption is that more agents is more advanced. It is not — more agents is more supervision. One capable agent handles more than people expect, and there are three specific signals that say it has stopped being enough. Until one of them appears, splitting makes things worse.
Start with one
A single agent with a clear job, a good set of tools and written procedures covers far more ground than the multi-agent framing suggests. It is simpler to supervise, cheaper to run, easier to debug, and has one memory rather than several partial ones.
The instinct to build a team immediately usually comes from the org-chart metaphor being appealing rather than from a constraint. Resist it until you hit one of the three below.
Signal 1 — Instructions contradict each other
The prompt has grown to cover several jobs, and guidance for one undercuts another. "Always be concise" for support, and "include full reasoning" for research, in the same agent. You notice because tuning for one job breaks the other, and you find yourself adding conditional language — "when doing X, ignore the instruction about Y".
That conditional is the tell. It is a job boundary written in prose, and it belongs between two agents.
Signal 2 — The context fills with debris
Unrelated work crowds the same conversation. The agent handling an enquiry is carrying yesterday's report and last week's research, and quality drops for reasons nobody can point at. Long-running agents doing several kinds of work accumulate this.
Note the cheaper fix first: a subagent handles a step in its own context and reports back, keeping the parent's conversation clean. That solves the debris problem without creating a new top-level agent to supervise.
Signal 3 — You cannot attribute a bad answer
Something goes wrong and you cannot tell which part of a two-thousand-word prompt caused it. This is the one that matters most, because it means you have lost the ability to improve the system — every fix is a guess, and each guess risks breaking something else.
Splitting restores attribution: a job small enough to describe precisely is a job whose failures you can diagnose.
What splitting actually costs
Rarely stated, and it is the reason to wait for a signal:
- Supervision. Each agent has its own instructions, memory and connections to maintain. Four agents is four times the surface.
- Coordination failure modes you did not have. Loops, duplicated work, silent handoff failure, gaps between responsibilities — all new, all yours.
- Fragmented memory. Each agent knows its own slice, and a question spanning two of them may get an incomplete answer.
- Latency and cost. A handoff is another model call and another round trip.
None of that is prohibitive, and all of it is wasted if a single agent would have done.
The rule
Add an agent when a job is distinct, not when it is big.
Distinct means it has its own success criteria, its own tools, and would sensibly have its own memory. Big just means there is a lot of it — and a lot of one job is still one job.
The practical version: if you can write the new agent's purpose on a business card without using "and", it is distinct. If you need "and", you are describing either two agents or a subagent of something that already exists.
The order to grow in
- One agent with a clear job.
- Add subagents when the context gets crowded — cheapest step, no new supervision.
- Add a peer when something genuinely owns its own domain and needs its own memory and channels.
- Add a lead once there are enough peers that you are routing requests yourself. The moment you are deciding which agent to ask, a lead should be doing it.
Most operations settle at a lead plus a handful of specialists. How many you actually need, and one that grew this way.
Related reading
FAQ
When should I use multiple AI agents instead of one?
When one of three signals appears: instructions that contradict each other so tuning for one job breaks another, a context filling with debris from unrelated work, or an inability to tell which part of a long prompt caused a bad answer. Before any of those, splitting adds supervision without adding capacity.
Is a multi-agent system better than a single agent?
Not inherently. More agents means more supervision, more coordination failure modes, fragmented memory and extra latency per handoff. A single capable agent with good tools and written procedures covers more ground than the multi-agent framing suggests.
What is the rule for adding an agent?
Add one when a job is distinct, not when it is big. Distinct means it has its own success criteria, its own tools and would sensibly have its own memory. The practical test: if you can write the new agent's purpose on a business card without using the word 'and', it is distinct.
What is the cheapest way to fix a crowded agent?
A subagent. It handles a step in its own context and reports back, so the parent's conversation stays clean — solving the context-debris problem without creating a new top-level agent to supervise.
Split when the signals say so
Starter teams if you need several from day one, and a single agent you can grow into a team later without rebuilding.