Information in this post reflects publicly available sources as of October 17, 2026.
A team builds a research assistant out of five agents. A planner breaks the question down, a researcher searches the web, a writer drafts the report, a critic reviews it, and an editor polishes the result. The demo is impressive: you can watch the agents hand work to each other like a small, tireless consulting firm.
Production is less impressive. Reports take four minutes and cost five times what the prototype did. The critic and the writer sometimes pass a draft back and forth until they hit the step limit.
Two researchers occasionally chase the same lead, and the final report contradicts itself because the writer never saw half of what they found. Meanwhile, a single agent with good search tools, tried as a baseline, does nearly as well at a fraction of the cost.
Splitting work across several agents can genuinely help. It can also add cost, latency, and new ways to fail. This post is about telling the difference, and about A2A, the protocol for agents that need to talk across team and company boundaries.
Where one agent runs out
The agents post in this series described a single loop: one model, one context window, one set of tools. That design goes surprisingly far. It runs into four limits, and each one is a legitimate reason to bring in more agents.
The first is context: a long task fills the window with tool output, and quality drops as it fills, as the context engineering post showed. The second is speed: one loop does one thing at a time, even when ten independent lookups could run at once. The third is focus: one system prompt and tool set has to cover every role the agent plays. The fourth is ownership: sometimes the capability you need belongs to another team or another company, which runs its own agent behind its own API.
The first three are design problems inside your system. The fourth is an interoperability problem between systems. They call for different solutions, and the rest of this post takes them in that order.
How it works
Four patterns
Almost every multi-agent system is built from a few recurring shapes. They differ mainly in who decides what happens next, and in whether agents share context or work in isolation.
Orchestrator and workers is the workhorse. A lead agent breaks the task into independent pieces, hands each to a subagent with its own fresh context window, and synthesizes what comes back. Each worker can read fifty pages and return a ten-line summary, so the orchestrator's context stays clean. Independent workers can also run in parallel.
Sequential handoff passes control from one specialist to the next. A triage agent works out what a customer needs, then hands the conversation to a billing agent with its own instructions and tools. Each specialist has a short, focused prompt instead of one giant prompt covering everything.
Generator and reviewer pairs an agent that produces work with one that critiques it. The reviewer works best with a fresh context: it sees the output the way a user would, without the reasoning that led to it. Code review is the classic case.
The free-form swarm, where agents converse freely and decide among themselves who does what, is the pattern that looks best in demos. It is also the hardest to predict, test, or debug, because no single agent owns the outcome.
What the evidence says
In June 2025, Anthropic published how it built the multi-agent system behind Claude's Research feature: a lead agent that spawns parallel subagents to search different angles of a question. On its internal research evaluation, the multi-agent setup outperformed a single agent using the stronger model by 90.2%.
The same write-up is candid about the price. Agents used about four times as many tokens as ordinary chat, and the multi-agent system about fifteen times as many. In their analysis of one browsing benchmark, token usage alone explained 80% of the variance in performance. Part of why multi-agent research works is simply that it spends far more compute on the problem, spread across many clean context windows.
The write-up also lists where the approach fits poorly: tasks where every agent needs the same context, tasks with many dependencies between agents, and most coding work, which has fewer truly independent pieces than research does.
Reads fan out, writes stay single-threaded
The most useful design rule comes from the coding-agent company Cognition. In 2025 it published an essay titled "Don't Build Multi-Agents," arguing that every action carries implicit decisions. Two agents writing different parts of the same codebase will make different choices about naming, error handling, and edge cases, and the result does not fit together.
In an April 2026 follow-up, Cognition described which multi-agent patterns had worked in practice. They share one property: extra agents contribute intelligence, not actions. Many agents can read, search, and review in parallel. Only one thread makes changes.
Subagents are just tools
Implementation is less exotic than the diagrams suggest. A subagent is usually a tool whose implementation runs its own agent loop. The orchestrator calls it like any other tool and receives a short string back:
def research_subagent(question: str) -> str:
"""Investigate one question in a fresh context. Returns a short report with sources."""
return run_agent(
goal=f"{question}\n\nReturn at most 200 words, citing your sources.",
tools=[web_search, fetch_page], # read-only: subagents gather, they don't act
max_steps=15,
)
answer = run_agent(
goal="Compare three vector databases for a 50-million-document corpus.",
tools=[research_subagent], # the orchestrator's only tool is delegation
max_steps=25,
)The run_agent function is the loop from the agents post. The subagent starts with an empty history, so whatever it reads never reaches the orchestrator's window; only its 200-word report does. If the harness supports parallel tool calls, the orchestrator can launch several research subagents in a single step.
Notice the two levers in that code. The output limit controls how much context comes back, and the tool list controls what a subagent can do. Read-only tools for workers, and write access only in the main thread, is the single-writer rule expressed in code.
Crossing boundaries with A2A
Everything so far happens inside one system you control. The fourth limit is different: the agent you need belongs to someone else. Your travel assistant needs the airline's booking agent, and your procurement agent needs a supplier's quoting agent. You cannot import their code, and they will not expose their internals.
The Agent2Agent protocol (A2A) standardizes this conversation. Google introduced it in April 2025 and donated it to the Linux Foundation that June, and version 1.0, the first stable specification, was finalized in March 2026. The project has since joined MCP in the Agentic AI Foundation.
A remote agent describes itself in an Agent Card, a JSON document published at /.well-known/agent-card.json. It lists what the agent can do, where to reach it, and which features it supports:
{
"name": "Travel Booking Agent",
"description": "Searches and books flights and hotels within corporate travel policy.",
"version": "2.1.0",
"provider": { "organization": "Example Travel Co." },
"supportedInterfaces": [
{ "protocolBinding": "JSONRPC", "url": "https://agents.example.com/a2a", "protocolVersion": "1.0" }
],
"capabilities": { "streaming": true, "pushNotifications": true },
"defaultInputModes": ["text/plain"],
"defaultOutputModes": ["text/plain", "application/json"],
"skills": [
{ "id": "book-trip", "name": "Book a trip",
"description": "Find and book flights and hotels for given dates and travelers." }
]
}Work happens as a task with a lifecycle. The client sends a message, and the remote agent moves the task through states such as WORKING, INPUT_REQUIRED when it needs more information, and finally COMPLETED, FAILED, or REJECTED. Results come back as artifacts, such as an itinerary document. Long tasks can stream progress over server-sent events or call a webhook when they finish.
A2A defines three equivalent ways to carry these messages: JSON-RPC, gRPC, and plain HTTP with JSON. Version 1.0 also added signed Agent Cards, so a client can verify that a card really comes from the organization it claims.
The relationship with MCP is the part people most often get wrong. MCP connects an agent to tools and data: you see each tool's schema and decide exactly when to call it. A2A connects an agent to another agent: you hand over a goal, and the remote agent decides how to pursue it with its own model, tools, and judgment. A single system often uses both, MCP for its own tools and A2A for partners' agents.
When to use multiple agents, and when not to
Start with one agent and good tools, and add agents only when you can name which of the four limits you are hitting. If the context window floods during long tasks, add read-only subagents that return summaries. If independent lookups could run in parallel, use orchestrator and workers. If one prompt is trying to serve several very different roles, use handoffs between specialists.
If output quality matters more than speed, add a reviewer with a fresh context. Each of these changes is easy to measure: run your eval suite on the single-agent baseline and on the multi-agent version, and compare quality, cost, and latency side by side. If the extra agents do not move the numbers, remove them.
Use A2A when the other agent is genuinely someone else's: another team with its own release cycle, or another company. Inside a single codebase, a subagent called as a tool is simpler, faster, and easier to debug than a network protocol.
Avoid agents defined by job titles rather than by limits. A "CEO agent," a "product manager agent," and an "engineer agent" passing memos to each other make an engaging demo. In production they mostly add hops, each of which loses context and adds cost.
What goes wrong
Handoffs lose context. Every time work passes between agents, it is compressed into a message. Details the sender thought unimportant disappear, and the receiver fills the gaps with assumptions. Give subagents complete, specific task descriptions, including the goal behind the task, not just the task itself.
Parallel writers make conflicting decisions. Two agents editing the same codebase, document, or customer record will each make reasonable choices that do not fit together. Keep writes in one thread, and treat parallel agents as researchers and reviewers.
Agents get stuck in loops. A writer and a reviewer with slightly different standards can pass a draft back and forth forever, and two agents can each wait for the other to act. Cap the number of review rounds and give one agent the final say.
Nobody can see what happened. A bad answer from a five-agent system could have started in any agent, any handoff, or any tool call. Without tracing that links every subagent's steps to the parent task, debugging is guesswork. Set up tracing before you add the second agent, not after the first incident.
Remote agents are untrusted input. Text returned by another company's agent lands in your agent's context like any web page, so it can carry a prompt injection. An A2A partner is a stranger on the network with a well-formatted reply. Apply the same permission rules you would to any external content.
Cost, latency, and complexity
Multi-agent systems trade money for time and quality. Take a research task that a single agent finishes using 200,000 input tokens. An orchestrator using 100,000 tokens plus five subagents using 150,000 each comes to 850,000 tokens, more than four times as much. At an illustrative $3 per million input tokens, that moves the task from $0.60 to about $2.55.
Latency can move the other way. If those five subagents each take three minutes and run in parallel, the research phase takes about three minutes instead of fifteen. Sequential handoffs and reviewer loops get none of that benefit: each hop adds a full round of model calls to the user's wait.
The largest cost is often engineering complexity. Each agent needs its own prompt, tools, evals, and traces, and the interactions between agents need testing too. A system with three agents is not three times as hard to debug as one; it is closer to the number of ways they can interact.
The current landscape
The major agent frameworks all support multi-agent patterns. The OpenAI Agents SDK provides handoffs and agents-as-tools, and the Claude Agent SDK supports subagents with their own context and tool permissions. Google's Agent Development Kit builds hierarchies of agents and supports A2A natively. LangGraph offers supervisor patterns as explicit graphs, and CrewAI and Microsoft's Agent Framework provide role-based multi-agent orchestration.
A2A reached version 1.0 in March 2026, and by its first anniversary the Linux Foundation counted more than 150 supporting organizations, including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow. Support has landed in Azure AI Foundry and Copilot Studio, Amazon Bedrock AgentCore, and Google's agent platforms. Version 1.0 changed the card format and endpoint name from earlier drafts, so check which version a partner supports before integrating.
The research picture keeps evolving. Anthropic's results show orchestrator and workers paying off for broad research, and Cognition's experience shows narrow patterns with a single writer holding up in coding. Both point the same way: structured delegation works, while open-ended agent conversation mostly does not.
Summary
Adding agents is not a way to make a system smarter. It is a way to work around specific limits of a single agent: a context window that fills up, a loop that runs one step at a time, a prompt stretched across too many roles, and capabilities owned by someone else. Each extra agent buys one of those things and pays for it in tokens, latency, and lost context at every handoff.
So design multi-agent systems the way you would design any distributed system: as few components as the problem needs, clear ownership of every decision, and one writer for any shared state. Let agents fan out to read and review, keep changes in a single thread, and reach for A2A only when the other agent truly belongs to someone else.
Part of the Applied AI series: AI from the builder's side.