Multi-Agent Systems: When One Agent Is Not Enough

The clearest public account of why multiple agents help comes from Anthropic's write-up of its research feature, in which a lead agent plans the work and starts sub-agents that search in parallel (Anthropic, How we built our multi-agent research system). It names three benefits.

Context isolation and compression. Each sub-agent works in its own context window, explores one aspect of the question and returns only a condensed result to the lead agent. Anthropic describes search as compression, "distilling insights from a vast corpus," and sub-agents as the mechanism that does it in parallel. The lead agent never has to hold every page every sub-agent read.

Parallelism. Independent directions can be explored at the same time instead of one after another. Anthropic's example is a request to find the board members of every company in a large index: the multi-agent system split it into tasks for sub-agents, while a single agent failed with "slow, sequential searches."

Separation of concerns. Each sub-agent can have its own prompt, tools and approach, which Anthropic says reduces path dependency and allows independent investigations.

Anthropic also gives an honest explanation of the underlying mechanism: multi-agent systems "work mainly because they help spend enough tokens to solve the problem." Splitting the work across several context windows adds capacity for reasoning that one window cannot hold. That is a benefit and, as the next section shows, a cost.

Organizational reasons matter too. Microsoft's guidance on choosing between single and multiple agents lists security and compliance boundaries, separate teams owning separate knowledge areas and planned growth across many functions as reasons to start with a multi-agent design (Microsoft, Single agent or multiple agents). Its financial services example is one agent preparing transactions while another validates them, enforcing separation of duties through architecture.

Every benefit above has a price.

Tokens. In Anthropic's data, as published in its engineering write-up and read on 2026-10-17, agents used about four times more tokens than chat interactions and multi-agent systems about fifteen times more. Its conclusion is that multi-agent systems need tasks "where the value of the task is high enough to pay for the increased performance" (Anthropic).

Latency and coordination. Microsoft notes that coordination between agents adds latency at every handoff and requires explicit state management between components, and that each agent needs its own prompt engineering, monitoring and debugging (Microsoft, Single agent or multiple agents).

Failure modes that do not exist with one agent. Anthropic's early versions spawned far too many sub-agents for simple questions, searched endlessly for sources that did not exist and distracted each other with excessive updates. Beam catalogs more: an orchestrator that misroutes a task, sub-agents that disagree while a synthesis step invents a consensus, handoff loops where agents pass a task around with nobody owning it, and agents in a debate that converge on the same wrong answer (Beam).

Poor fit for tightly coupled work. Anthropic notes that domains where all agents need the same context, or where there are many dependencies between agents, are not a good fit. It observes that most coding tasks contain fewer truly parallel pieces than research does.

Before splitting an agent, try to fix it as a single agent: tighten the prompt, prune and clarify the tools, add retrieval and compact the context. If problems remain, these signals point toward multiple agents:

• The work splits into independent parts that can run at the same time, such as researching several companies or reviewing code for security, style and performance separately.
• Context overflows. The agent needs to read more material than fits usefully in one window, and quality drops as the context grows.
• Tool overload. The agent has so many tools that it picks the wrong one, and grouping them by domain would make each group clear.
• Hard boundaries. Different parts of the work must run with different data access or permissions.
• Separate owners. Different teams maintain different domains and need to change their part without coordinating every release.
• Checks that should be independent. A second agent that reviews the first agent's output with a different prompt can catch errors the first one is blind to.

If none of these apply, a single agent is usually cheaper, faster and easier to debug.

Once you decide on multiple agents, pick a structure for how they cooperate. LangChain describes four foundational patterns (LangChain, Choosing the right multi-agent architecture), and Microsoft and Beam add sequential pipelines and group discussion.

LangChain counts the skills pattern as "quasi-multi-agent": a single agent that loads specialized prompts and knowledge only when needed. It delivers much of the benefit of specialists, such as separate ownership and focused context, without running separate agent instances. It is often the right step before a true multi-agent design.

Beam's advice for choosing: if you know the subtasks at design time and want one point of accountability, use an orchestrator. If the steps are fixed and each depends on the last, use a pipeline. Reach for open-ended planning or debate only when the problem truly has no predetermined path (Beam).

Most multi-agent failures are delegation failures. Anthropic's lessons are specific (Anthropic):

• Write complete task descriptions. "Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries." Short instructions such as "research the semiconductor shortage" led sub-agents to misread the task or duplicate each other's searches.
• Scale effort to the request. Agents are poor judges of how much effort a task deserves, so Anthropic wrote explicit rules into the lead agent's prompt: simple fact-finding needs one agent and a few tool calls, comparisons need a few sub-agents, and only complex research justifies many.
• Return condensed results. Sub-agents should hand back a distilled summary, not their full working context, so the lead agent's context stays focused.
• Give each agent tools with a distinct purpose. Anthropic found that bad tool descriptions "can send agents down completely wrong paths."
• Set guardrails that stop agents from spiraling, such as limits on sub-agent count, tool calls and time.

A delegation message can be as simple as a structured block:

Objective: List the pricing tiers for the three vendors below, with monthly prices and seat limits.
Vendors: A, B, C (one sub-agent per vendor; do not research others)
Sources: each vendor's own pricing page first; ignore third-party reviews
Output: JSON array of {vendor, tier, monthly_price, seat_limit, source_url}
Stop when: every tier on the pricing page is captured, or after 8 tool calls

Multi-agent systems are harder to operate because errors compound and behavior emerges from interactions. Anthropic notes that small changes to the lead agent can unpredictably change how sub-agents behave (Anthropic). Its production lessons:

• Make long runs resumable. Agents hold state across many tool calls, so restarting from scratch after an error is expensive. Anthropic built systems that resume from where the agent failed, combined with retries and regular checkpoints.
• Trace everything. Full production tracing let Anthropic see whether a failure came from bad queries, poor sources or tool errors.
• Evaluate outcomes, not paths. Agents may take different valid routes to the same answer, so judge whether they reached the right result through a reasonable process, often with a model-based grader and a rubric.
• Deploy carefully. Agents may be mid-task when you release changes, so Anthropic shifts traffic gradually from old to updated versions while both run.

Add budgets on top: maximum sub-agents per request, maximum tool calls and tokens per agent, and a timeout for the whole job. Microsoft also recommends iteration limits even for a single agent to prevent infinite tool-call loops (Microsoft, AI agent orchestration patterns).

Specialization can also live at the product level rather than inside one request. Quanta Intelligence, for example, routes each request to one of many vertical expert agents rather than asking a single generalist to cover every domain, which is the router pattern applied across a whole catalog.