Multi-agent systems.
Adding a second agent feels like hiring a teammate; most of the time it just adds a bill and a new way to fail. A system becomes multi-agent only when several independent model loops hand work to each other — and a single well-built agent with tools beats a naive crowd of them far more often than beginners expect. This entry gives you the ladder of coordination patterns, the real tradeoff, and an honest rule for when more agents actually earn their cost.
What makes a system "multi-agent" — and the topology ladder.
The most common confusion first: one agent that calls many tools is not a multi-agent system. A single model running in the agent loop — reading results, deciding, calling the next tool — is one agent, no matter how many tools it can reach. It only becomes multi-agent when there is more than one independent model context, each its own loop with its own instructions and conversation history, passing work between them.
That distinction sorts real systems onto a ladder of increasing coordination:
- Single agent with tools. The baseline. One loop, one context, many tools. Start here.
- Supervisor (orchestrator–worker). One lead agent decomposes the task, delegates subtasks to worker agents, then synthesizes their results. It is hub-and-spoke: workers report to the lead and do not talk to each other. This is by far the most common production pattern.
- Network ("swarm"). Agents hand control to one another peer-to-peer, with no boss coordinating. More flexible, much harder to keep predictable.
- Hierarchical. Supervisors of supervisors — a tree of orchestrators, each managing a team below it. For large tasks that decompose several levels deep.
"More agents" is a point on this ladder, not a synonym for "smarter." Each rung you climb adds coordination surface — more messages, more handoffs, more places for a small misunderstanding to compound. Climb only when the task actually demands it.
Roles and the three ways agents talk.
Agents in these systems play roles, but the roles are functional — defined by the job you give an agent, not built into any model. The recurring ones:
- Planner — decomposes a goal into subtasks.
- Worker / executor — carries out one subtask.
- Critic / verifier — checks another agent's output for errors before it is trusted.
- Router — classifies incoming input and dispatches it to the right agent.
One agent can play several of these at once; "planner" is a hat, not a species. Underneath the roles, all the ways agents coordinate reduce to just three communication patterns:
- Shared scratchpad / blackboard — agents read from and write to a common state, coordinating indirectly through what they leave there.
- Message passing — agents send discrete messages to each other, like a team on a chat channel.
- Handoffs — one agent transfers control and the conversation so far to another, which takes over from that point.
A popular mental image is a crowd of agents chatting autonomously like a team of people. Most production multi-agent systems are nothing like that — they are a strict orchestrator–worker tree with no peer chatter, where a human designer fixed the delegation in advance. The "autonomy" is in each agent's subtask, not in who talks to whom.
The tradeoff — and why to start with one agent.
Going multi-agent buys you three things: parallelism (workers run at the same time), specialization (each agent gets its own tools and system prompt), and separate clean contexts (no single window crammed with everything). Those are real gains. You pay for them in three currencies:
- Orchestration complexity — someone has to design and debug the decomposition, delegation, and synthesis.
- Error propagation — one bad subagent result quietly poisons the final synthesis, and the lead agent often cannot tell.
- Token and cost blow-up — every agent re-reads context and thinks separately. Anthropic reported that their multi-agent research system used roughly 15× the tokens of an ordinary chat interaction. Treat that as a real signal from one team, not a universal constant — but expect multi-agent to cost multiples more.
This is why a single well-designed agent often beats a naive multi-agent system. Splitting a job across agents fractures the context — see context engineering — and small ambiguities in one agent's instructions to another compound into failure. The durable lesson, argued sharply in Cognition's mid-2025 "Don't Build Multi-Agents" essay and echoed since, is to start with one strong agent and reach for more only when it demonstrably cannot cope. The related decision framing lives in when to use an agent.
When multi-agent genuinely wins, and how to build it.
The honest split:
- Wins when subtasks are parallelizable and read-heavy — for example, researching many independent sources at once — or when they need genuinely distinct skills, tools, or system prompts that are cleaner kept in separate contexts.
- Loses on tightly coupled, interdependent work. Coding is the classic poor fit: edits depend on each other and cannot be cleanly parallelized, so splitting them across agents mostly manufactures conflicts.
Two more things worth knowing. First, you rarely wire this by hand — frameworks such as LangGraph, CrewAI, the OpenAI Agents SDK (the production successor to the experimental OpenAI Swarm), the Microsoft Agent Framework (the merge of AutoGen and Semantic Kernel), and Google ADK (Agent Development Kit) all provide orchestration primitives; they solve the plumbing, not the design.
Second, two standards are easy to confuse. MCP connects an agent to tools and data (agent↔tool); A2A (Agent2Agent) connects agents to each other (agent↔agent). They are complementary, not competitors. A2A — contributed by Google, now a Linux Foundation project that reached v1.0 in 2026 — lets an agent publish an Agent Card so others can discover what it can do.
Beginner's rule of thumb: default to one strong agent with good tools. Add agents only for work that is parallel and independent, or that needs a truly separate specialty — and measure the token bill before you commit.
Ready to go deeper? The Multi-Agent Systems deep-dive group covers the full picture: when (and when not) to go multi-agent, the topologies and their costs, the supervisor–worker pattern in practice, and the failure modes that single-agent tooling cannot see. For the wire-level A2A story, see agent-to-agent communication and Agent Cards and discovery.