Single Agent vs Multi-Agent Systems: When One Agent Is Enough and When It Is Not
Usama · November 7, 2026
For most business tasks, one agent with well-designed tools is the better choice than several cooperating agents. Multi-agent systems earn their extra cost and complexity in three situations: the work is too big for one context window, parts of it can run in parallel, or you want an independent second opinion that does not share the first agent's blind spots. Outside those cases, splitting roles mostly adds tokens, delay and things that can go wrong.
This guide gives you a way to decide. It starts with the default, climbs a short ladder of designs, describes the common orchestration patterns, lists the ways multi-agent systems fail, and ends with a decision table. The reasoning leans on Anthropic's published engineering posts on building effective agents and on its multi-agent research system, which are honest about both the gains and the costs.
Why is one agent the right starting point?
Anthropic's guidance is to find the simplest solution that works and add complexity only when it clearly improves results. It adds that a single, well-optimised model call with retrieval and examples is often enough. Teams that jump straight to an "agent team" tend to be buying a diagram, not an outcome.
A single agent has real advantages you give up when you split it:
- Shared context. One agent sees everything it has done and learned. Separate agents each see a slice, and information gets lost at every hand-over.
- Fewer moving parts. One prompt, one set of tools, one trace to read when something fails.
- Lower cost and latency. Anthropic reports that agents use about four times the tokens of a chat interaction and multi-agent systems about fifteen times, and says the extra cost only makes sense for tasks valuable enough to pay for it. (Last verified November 2026 on Anthropic's engineering blog.)
- Easier testing. Our guide to testing and evaluating AI agents is hard enough for one agent. Every added agent adds behaviours to evaluate and ways to interact.
A single agent is not the same as a weak one. Anthropic puts as much design effort into tool design as into prompts: clear tool descriptions written like onboarding notes for a new teammate, with examples and edge cases, and tools built so that misuse is hard. Many "we need more agents" problems turn out to be "we need better tools and clearer instructions" problems.
What is the ladder from simple to complex?
Climb only as far as the task forces you.
- One model call with good context. Summarising, classifying, drafting. No loop.
- A fixed workflow of several calls in code-defined order. Anthropic calls this a workflow, as opposed to an agent where the model chooses its own steps. This is where a tool like n8n often fits; see AI automation with n8n.
- One agent in a loop with tools. The model decides which tool to use next. Right when the number of steps cannot be known in advance.
- One agent that calls helper agents for isolated sub-jobs, such as searching a large archive, then keeps the main thread to itself.
- Several peer or specialist agents coordinating. Rarely needed for business automation, and the hardest to run.
If rung 2 solves the problem, a fixed workflow is cheaper, faster and more predictable than any agent. Our post on AI agents versus chatbots and automation covers that choice in detail.
When does splitting into several agents help?
1. The work exceeds one context window
A single model can only hold so much text at once. If a job means reading hundreds of documents, a helper agent can dig through a subset and return a short summary, so the lead agent's context stays clean. This is the "compress the findings" role Anthropic describes for its research subagents.
2. The work can run in parallel
Breadth-first tasks with independent directions suit parallel workers. Anthropic's example is research: a lead agent plans, then several subagents explore different aspects at the same time and report back. Their internal evaluation found the multi-agent setup outperformed a single agent by 90.2% on that benchmark, and in one benchmark they analysed, token usage alone explained 80% of the performance variance. That second finding is a useful caution: part of the multi-agent gain is simply that more tokens were spent thinking about the problem.
3. You want independent checking
A reviewer that has not seen the first agent's reasoning is less likely to share its mistakes. A second agent that audits a draft contract summary against the source, or checks an extraction against the original invoice, can catch errors a self-check misses. Anthropic describes an evaluator-optimizer pattern where one model generates and another critiques in a loop, and says it works best when evaluation criteria are clear and feedback measurably improves the result.
4. Different tools or permissions should be kept apart
This is a security reason, not a capability one. An agent that reads hostile email should not also hold the tool that sends money. Separating them limits damage if one is manipulated; our post on AI agent security and prompt injection explains why. Here the split is a safety boundary, so keep it even if it costs a little extra.
What are the common orchestration patterns?
| Pattern | How it works | Good for | Watch out for |
|---|---|---|---|
| Router | A small first step classifies the request and sends it to the right specialist prompt, tool or model | Mixed inboxes (billing, returns, sales), and cost control by sending easy work to cheaper models | Misrouting; always include an "unsure, ask a human" route |
| Planner and workers (orchestrator-workers) | A lead model breaks the task into subtasks at runtime, workers do them, the lead combines the results | Tasks whose steps are not known in advance, such as research or multi-file changes | The lead's plan being wrong or too vague; duplicated work between workers |
| Parallel sections | Independent subtasks run at the same time and code merges the outputs | Checking one document against several rules at once | Merging conflicting outputs |
| Voting | The same task runs several times and the results are compared | High-stakes judgements where disagreement is a signal | Cost multiplies; agreement does not prove correctness |
| Reviewer (evaluator-optimizer) | One agent drafts, another critiques against a checklist, loop until it passes or a limit is hit | Drafts with clear quality criteria, such as policy compliance | Endless loops; a reviewer that approves everything |
| Prompt chain | A fixed sequence, each step feeding the next, with code checks between steps | Predictable multi-step jobs | Not really multi-agent, and often all you need |
The pattern names above follow Anthropic's own descriptions of routing, parallelisation, orchestrator-workers and evaluator-optimizer. Most real systems mix two of them at most.
Where do multi-agent systems break?
They fail in ways single agents do not.
- Lost context at hand-overs. A subagent only knows what you tell it. Vague instructions produce duplicated or off-target work. Anthropic's team found early versions of their lead agent gave subagents terse tasks and had to be taught to delegate with clear objectives, output formats and boundaries.
- Compounding errors. A small mistake early in a long run carries forward. Anthropic notes errors compound across long runs and describes building checkpoints so a run can resume rather than restart.
- Cost blowouts. Several agents each looping on their own can multiply spend quickly. Put a ceiling on steps and tokens per task.
- Non-deterministic debugging. The same input can take a different path each time, so a failure is hard to reproduce. Anthropic describes adding full production tracing as essential, while watching patterns in agent decisions without reading every private conversation.
- Coordination problems. Anthropic says LLM agents are not yet good at real-time coordination and delegation with each other, and that domains with heavy shared context or many dependencies between agents, such as most coding tasks, are a poor fit.
- Hard evaluation. Agents can reach the right answer by different valid paths, so Anthropic's team judged final outcomes rather than fixed steps, started with around 20 test queries, and still relied on human testing to catch things automation missed.
- Awkward deployment. Agents mid-task when you deploy a new version can break. Anthropic describes gradually shifting traffic between old and new versions so running tasks finish.
- Security surface. More agents mean more tool permissions and more places for untrusted text to enter.
How do you decide? A decision table
Answer the rows for your task. If most answers sit in the left column, use one agent or a fixed workflow.
| Question | Points to one agent or a workflow | Points to multiple agents |
|---|---|---|
| Can you write the steps down in advance? | Yes: use a fixed workflow | No, and the plan depends on what is found along the way |
| Does everything fit in one context? | Yes | No: much more material than one window can hold |
| Are sub-tasks independent? | No, each step depends on the last | Yes: breadth-first, many parallel directions |
| Do steps need shared state and rich shared context? | Yes (typical for coding, case handling) | No, only short results need to pass back |
| Is an independent check worth its cost? | Low-stakes output, a code check is enough | High-stakes output with clear review criteria |
| Must some tools be kept away from untrusted input? | No sensitive tools involved | Yes: a reader and an actor should be separate |
| Is the task worth several times the token spend? | No, margin is thin or volume is high | Yes: value per task is high |
| Can you trace and evaluate each agent? | Not yet | Yes, with logging and an eval set in place |
Three illustrative examples
These are invented examples to show the reasoning, not client projects.
A customer-email assistant
Emails arrive about orders, returns and sales questions. A router step classifies each message, then one agent with order-lookup and draft-reply tools handles it, with a person approving anything involving money. One agent plus a small router; no crowd. Splitting by topic into three agents would triple the instructions to maintain for little gain.
A market research brief
The task: compare 40 suppliers against a checklist, each with its own web pages and PDFs. The material is far larger than one context, and each supplier can be researched independently. A lead agent plans, workers each take a batch and return a short structured finding, and a final step merges them. This is the case multi-agent designs were built for, and it is worth the extra tokens if the brief is valuable.
A contract-summary tool
One agent extracts key terms from a contract. A second, with no access to the first agent's notes, checks each extracted term against the source text and flags mismatches. The reviewer is a quality control, kept separate on purpose. Nothing else needs splitting.
What does a sensible build order look like?
- Build the fixed workflow or single agent first and write the eval set.
- Read the failures. Group them: missing context, wrong tool, wrong judgement, too slow.
- Fix with better tools, clearer instructions and code checks before adding agents.
- If failures are still about context size or breadth, add helper agents for that one job.
- If failures are about confident mistakes, add an independent reviewer.
- Re-run the evals and compare cost per task before and after. Keep the split only if the numbers justify it, as discussed in our post on what it costs to run an AI agent.
Anthropic also warns that frameworks can hide the underlying prompts and responses, which makes debugging harder, and suggests starting with direct API calls and understanding any framework you adopt. If you want an architecture review or a first build done this way, we cover it under agentic AI development.
Not sure how many agents you need?
Describe the task and we will tell you honestly whether one agent, a workflow or a team is the right shape.
Discuss your architecture →Frequently asked questions
What is the difference between a single-agent and a multi-agent system?
A single-agent system has one model in a loop choosing tools to complete a task. A multi-agent system has several model-driven agents, each with its own instructions and context, that pass work to each other or are coordinated by a lead agent.
Are multi-agent systems more accurate?
Sometimes. Anthropic reported a large gain on its internal research evaluation, but also found that much of the performance difference tracked how many tokens were used. Gains depend on the task, and they come with higher cost and harder debugging.
Do multi-agent systems cost more to run?
Yes, usually a lot more. Anthropic reports roughly fifteen times the tokens of a chat interaction for its multi-agent research system, against about four times for a single agent. Check current figures and your own measurements.
Is a multi-agent setup good for coding or customer support?
Anthropic says most coding tasks have fewer parallelisable parts and depend heavily on shared context, so they suit multi-agent designs less. Customer support usually works well as one agent with good tools and human approval for sensitive actions.
Can I start with one agent and add more later?
Yes, and that is the recommended route. Build one agent, measure where it fails, and split out a helper or reviewer only for the failure that needs it.
Related Services