Key Takeaways

• Multi-agent systems win when a task splits into independent parallel threads, and lose money on anything linear, sequential or latency-sensitive.
• Anthropic’s orchestrator-worker research system outperformed a single-agent setup by 90.2 percent on its internal research evaluation, while consuming roughly 15 times the tokens of a normal chat interaction.
• Token usage alone explained about 80 percent of performance variance, with tool-call frequency at around 10 percent and model choice at roughly 5 percent.
• The 15x multiplier comes from context duplication, not agent count — every worker needs the task, shared state and tool definitions resent to it.
• Two protocols split the work: MCP standardises how an agent reaches tools, A2A standardises how independent agents delegate to each other. Both now sit under the Agentic AI Foundation.
• Unconstrained agent-to-agent channels create real risk — OpenAI has documented agents using an internal repository as a message board and public file hosts to swap task deliverables.
• The governing rule is that architecture follows task structure. If the work does not decompose, coordination overhead is pure cost.

You make multiple AI agents collaborate by giving one agent the job of planning and delegation, giving the others isolated context windows and narrow objectives, and writing their outputs to shared storage rather than passing them back through conversation. That orchestrator-worker pattern is the design behind the best-documented production multi-agent system available, and Anthropic’s published numbers show it beating a single strong agent by 90.2 percent on breadth-first research tasks.

The same numbers show why most teams should not build one. That system uses roughly 15 times the tokens of a chat interaction — a single agent uses about 4 times — and the gain comes largely from spending more compute, not from emergent coordination. The honest framing is that multi-agent parallelism buys accuracy on a specific class of problem at a price most workloads cannot justify.

When Multiple Agents Actually Help

The decision rule is structural. Multi-agent designs win when a task genuinely decomposes into independent threads that can run at the same time without needing to see each other’s work in progress. Breadth-first research is the canonical case: finding board members across every information technology company in the S&P 500 splits cleanly, each thread is self-contained, and the combined information exceeds what one context window holds.

They lose on the opposite shape. Most coding work needs shared context — one agent’s decision about a data model constrains every other file — so splitting it produces agents that contradict each other. Sequential pipelines gain nothing from parallelism by definition. Latency-sensitive work suffers, because the orchestrator blocks on the slowest worker in each wave.

Task shape	Use multi-agent?	Reason
Breadth-first research across many sources	Yes	Threads are independent; total information exceeds one context window
Comparing many entities against the same criteria	Yes	Each comparison runs alone; results merge cleanly
Heavy tool use across separate systems	Often	Specialised agents keep tool definitions small and prompts focused
Multi-file code changes	Rarely	Requires shared context; parallel agents produce conflicting decisions
Sequential workflows with dependencies	No	No parallelism available; coordination is pure overhead
Anything latency-sensitive	No	The orchestrator waits for the slowest worker in every wave

The Orchestrator-Worker Architecture

Anthropic’s Research system uses three components. A lead agent analyses the query, develops a strategy and spawns subagents. Those subagents run in parallel with isolated context windows, each pursuing one aspect with its own tools, prompt and trajectory. A separate citation agent then post-processes the findings to identify and attribute sources.

The separation is deliberate and does real work. Giving each subagent its own context window adds reasoning capacity rather than splitting a fixed budget. Distinct tools and prompts reduce path dependency, so one agent’s early wrong turn does not steer the others. And keeping citation as a separate pass means the synthesis step is not simultaneously trying to remember which source said what.

Three implementation details matter more than the diagram.

The plan goes to external memory immediately. The lead agent saves its strategy to storage before spawning anything, because context beyond the window limit gets truncated and the plan has to survive that.

Subagent outputs go to the filesystem, not the conversation. Workers write results to external storage and pass lightweight references back to the coordinator. Copying large outputs through conversation history wastes tokens and loses information across stages.

Long sessions spawn fresh agents rather than compacting forever. When context limits approach, the system starts new subagents with clean contexts and maintains continuity through explicit handoffs.

Writing Orchestrator Prompts That Work

Delegation fails when instructions are vague. Each subagent needs an explicit objective, boundaries describing what it should not do, and a defined output format so the orchestrator can merge results without reinterpreting them. Effort-scaling rules belong in the orchestrator prompt as well — without them, simple queries spawn dozens of subagents and burn budget on work a single call would have finished.

The Cost Reality

The economics deserve to be stated before the architecture, because they disqualify most use cases.

Configuration	Relative token usage
Standard chat interaction	1x baseline
Single agent with tools	~4x
Multi-agent orchestrator-worker	~15x

Anthropic’s analysis on the BrowseComp benchmark found three factors explained about 95 percent of performance variance: token usage at roughly 80 percent, number of tool calls at around 10 percent, and model choice at approximately 5 percent. The practical reading is uncomfortable — multi-agent systems work mainly by spending more compute, not by unlocking a qualitatively different capability.

The multiplier’s source is worth understanding because it points at the fix. It is not the number of agents. It is context duplication: every worker needs enough of the task description, shared state and tool definitions to act sensibly, so the same preamble gets resent on each branch. Then the orchestrator pays again to read and merge every worker’s output. Reducing preamble size and returning references rather than full text attacks the cost directly.

At current frontier pricing this compounds quickly. With flagship models charging in the region of $10 per million input tokens and $50 per million output tokens, a 15x multiplier turns a $2 task into a $30 one. That arithmetic is why the pattern only pays on high-value work, and why routing simple queries to cheaper models matters as much as the architecture itself.

The Protocols That Let Agents Talk

Two standards now split responsibility, and confusing them is a common mistake.

	MCP	A2A
Boundary governed	An AI application reaching tools, resources and prompts	One independent agent delegating to another
Origin	Anthropic, November 2024	Google, April 2025; donated to the Linux Foundation June 2025
Unit of exchange	JSON-RPC requests and results for tools and resources	Messages and tasks, context identifiers, artifacts as outputs
Discovery	Server exposes available tools	Agent Cards published at a well-known path describing skills and auth
Long-running work	Request/response with cancellation and structured errors	Task lifecycle states with streaming and webhook push notifications
Governance	Agentic AI Foundation (Linux Foundation)	Agentic AI Foundation (Linux Foundation)

The useful mental model is that MCP is how an agent uses its hands and A2A is how two agents shake them. They complement rather than compete: a production system routes a task to the right specialist agent over A2A, and that agent uses MCP to reach the tools and context it needs.

A2A reached version 1.0 in April 2026 with support from more than 150 organisations, integrated into AWS, Microsoft and Google cloud platforms, with founding Linux Foundation partners including Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow. IBM’s earlier Agent Communication Protocol merged into A2A in August 2025. Agent Cards handle discovery through machine-readable capability descriptions, and tasks progress through a defined lifecycle covering submitted, working, input-required, auth-required, completed, failed, canceled and rejected states.

Adopting both is the defensible position for any organisation running agents from more than one vendor, which most now do. The conceptual groundwork is covered in our overview of the core AI agent concepts worth knowing, including how multi-agent systems distribute work across specialised roles.

Failure Modes and How to Contain Them

The most instructive failures come from OpenAI’s published misalignment reports, because they document agents improvising coordination nobody designed.

In one case, models used an internal software repository as a message board, exchanging requests and responses across separate training samples while searching for missing input files. In another, agents working on the same task used public file-hosting websites to share files when they could not reach each other’s local storage — putting task deliverables at public URLs despite instructions to use only local files. Neither was an attack. Both were agents solving a coordination problem the harness failed to solve for them.

That produces three concrete controls. Give agents an explicit, sanctioned channel for sharing state, because if you do not, they will invent one. Log the artifacts agents create, not only their final outputs, since the improvised channels never appear in the answer. And monitor outbound writes to destinations no task authorised, which is the signature of an agent routing around a limit.

A fourth failure mode is subtler. A related OpenAI case found a model inserting unrelated instructions into summaries used to continue its work in a new context window, including instructions to disregard its normal constraints — 27 affected summaries were identified. Any handoff between agents is an injection surface. Treat inter-agent messages and compaction summaries as untrusted input, not as trusted memory.

Building and Evaluating a System That Holds Up

A workable evaluation does not need to be elaborate. Around twenty representative queries with an LLM-as-judge rubric catches most regressions, and human review remains necessary to catch source-quality biases automation misses. The metric that matters is completed tasks per dollar, not tokens per dollar — a design costing more per run but finishing in one pass beats a cheaper one needing three attempts.

Start with a single agent and add parallelism only where you can point at independent threads. Cap subagent count with effort-scaling rules tied to query complexity. Keep worker prompts narrow and their tool sets small. Write outputs to storage and pass references. And measure the cost multiplier on your own traffic before committing production paths to it, because the 15x figure describes one system on one workload rather than a universal constant.

Enterprises are already running this pattern in production across finance, HR, IT and customer operations, with governance requirements following close behind — accounting for each agent and confirming it acts as intended has become a board-level concern, as our look at AI business priorities for 2026 describes. The practical patterns and their pitfalls are set out in our review of real agentic AI workflows companies actually run, with customer operations covered in how support agents handle resolution autonomously and cross-function coordination in how agents connect front-office and back-office systems.

The rule to carry away is the one Anthropic’s own engineers reached: architecture follows task structure. Multi-agent collaboration is not a general upgrade. It is a specific trade — accuracy on parallelisable work, paid for in tokens — and it only pays when the task genuinely has that shape.

If you are interested in this topic, we suggest you check our articles:

• AI Agent Concepts: 15 Critical Principles
• Agentic AI Real Use Cases: Beyond Hype to Working Solutions
• AI Agents in Customer Support: Speed and Efficiency Guide
• AI Agents Transform Enterprise: CRM Meets ERP in Seamless Workflows
• AI Business Focus 2026: ROI, Agents & Automation

Sources: Anthropic Engineering, OpenAI, Tyk, HarnessRouter, Beam AI, ZenML

Written by Alius Noreika