In the previous chapter, we covered how to connect external tools to a single agent via MCP. By now you have one autonomous agent — equipped with head, tools, memory, and loop — up and running. But as the work grows, a design that crams everything into one agent breaks down somewhere. In this chapter, we sort out "multi-agent design," which splits roles and solves problems with multiple agents, along with its approach to coordination (A2A: Agent-to-Agent), at a conceptual level independent of any framework.
The goal: being able to judge "when and how splitting makes things stronger"
When one agent isn't enough
A single agent is simple, easy to reason about, and easy to follow — which is exactly why building with one agent first is the right answer. The trouble comes when you keep adding roles to it. Cram duties into one prompt — "investigate, write, review, translate, and publish too…" — and past some point the accuracy suddenly starts to drop.
There are mainly three causes. ① Instructions grow long and vague (the more you write "this and that," the more the model wavers over what to prioritize). ② The context swells (it hoards even irrelevant information, diluting the crucial instructions). ③ Too many tools (the more choices, the easier it is to pick the wrong tool). An agent overstuffed on its own is, in a sense, "a workplace in chaos because one person is juggling many roles."
💡 A shift in thinking. Rather than making one agent ever smarter, switch to the idea of "having multiple small agents, each focused on a single role, cooperate." This is the starting point of multi-agent design. By the same logic as dividing labor in a human organization, the narrower and clearer each one's duty, the more stable the whole.
That said — splitting doesn't always make things better. Division of labor carries a coordination cost. So the real subject of this chapter isn't only "how to split" but discerning "whether to split at all." Let's look at the three representative forms first, then move on to the criteria for that judgment.
Three basic patterns
You can draw countless multi-agent configurations, but the skeletons that recur in practice boil down to three. Combine these three and you can describe most configurations. Let's grasp each one — its role and where it fits or doesn't.
The parent (orchestrator) makes the overall plan, hands tasks out to children (workers) to execute, and gathers and integrates the results. The children don't know each other; they look only to the parent. Its strength is being centralized and easy to control.
Good when: the task can be split and you want to run it in parallel.
Line up the stages and pass the previous agent's output as the next agent's input, in order. For example "research → writing → proofreading." Each stage handles just one step, so duties are clear and easy to verify.
Good when: the procedure is linear and the stages are fixed.
Like "researcher," "coder," "reviewer," prepare specialist agents each with their own strength and call the right one for the situation. You can narrow each one's instructions and tools, raising expertise.
Good when: the required capability differs greatly by domain.
These three are not exclusive. Real systems often become nested — for example, "an orchestrator bundles specialist-type workers, one of which is itself a pipeline." Deciding the outermost skeleton first and using a different pattern inside only where needed — that way of stacking is easier to handle.
📊 When in doubt, start with ①. The most general of the three is orchestrator + workers. Because the parent holds planning and integration centrally, it's easy to control and becomes the basic form of many multi-agent configurations. For an overview of the patterns, see What is multi-agent; for how to think of it as a system, What is a multi-agent system.
When to split, and when not to
Once you know the patterns, you're tempted to split everything. But division of labor always carries a "coordination cost" — the effort of passing information between agents, meshing it, and waiting on one another. Multi-agent is the right answer only when the gain from splitting exceeds this coordination cost. First, let's line up both sides.
- It can run in parallel: run independent subtasks at once to cut time
- Expertise is required: narrowing instructions and tools per domain raises accuracy
- The search is broad: you want to divide up multiple perspectives or candidates
- You want to separate contexts: cut context per role to prevent crosstalk
- It's inherently simple: you needlessly complicate work one agent handles
- Cost increases: the more agents, the more LLM calls and tokens stack up
- Coordination is heavy: the overhead of hand-offs and waiting eats the gains of splitting
- Strong sequential dependency: each step depends heavily on the previous result, with little room for parallelism
⚠️ First ask "is one agent enough?" Multi-agent is powerful, but not something to reach for on the first move. The rule is to escalate in steps: one agent → refine the prompt → add tools → split only if that's still not enough. Add complexity only after confirming "the current single agent really is at its limit." You can always split later.
As a practical rule of thumb, imagine "whether, when explaining that role to a human colleague, it fits naturally into one person's job description." If you can write it under a single title, one agent still suffices. The moment you want to say "this is the research person, this is the writing person" and make them different people is the moment to consider splitting. For the full picture of this judgment, see also How to build a multi-agent system.
Coordination between agents (A2A)
Once you decide to split, the next design challenge is "how the agents exchange information with each other." In a human team, this is the work of deciding the format of hand-off notes and the rules for reporting. Get this vague and, however capable each one is, the whole won't mesh. There are two big points to nail down in coordination.
Decide what to pass and in what form. Making "the task instruction, the required input, and the expected output format" an explicit contract keeps the receiver from getting lost. A structured hand-off is more stable than tossing over free text.
The step of merging multiple outputs into one. Decide who holds final responsibility for integration. Include in the design the priority when conflicting results come back, and how to merge them (summarize, cross-check, majority vote).
The move to standardize this idea of "agents dividing roles and coordinating" is A2A (Agent-to-Agent). Where the previous chapter's MCP was the convention for connecting "agent ↔ tools/data," A2A is the convention for connecting "agent ↔ agent" — think of it as a common etiquette for knowing what a counterpart agent can do, delegating tasks, and receiving results.
💡 Remember MCP and A2A as a pair. Roughly, MCP = connect "hands" to an agent; A2A = connect agents to each other. The former is tool/data connection, the latter the etiquette of coordination. Grasping them as concepts is enough for now, and we'll touch on the concrete protocols in later chapters too. For more, see What is the A2A protocol. Reading it alongside the previous chapter's MCP and tool integration makes the difference clear.
What matters is not memorizing protocol names, but the design attitude that "coordination needs an explicit contract." Who holds which task, what input it starts with, what it returns, and to whom it goes back on failure — deciding this contract up front is the foundation of a system that doesn't collapse as it scales.
Managing context and cost
The greatest practical risk of multi-agent is the blowup of context and cost. The more agents there are and the more they pass information to one another, the fatter the context each agent holds, and the more the LLM call count and token volume stack up. Leave it alone and it tends to become a slow, expensive, unstable system. Take the reins at the design stage.
Give children only what that task needs. Don't stream the whole history through. Irrelevant context also lowers accuracy.
Long results should be summarized to the key points before passing on. The idea is to hand over "conclusion and rationale," not raw logs.
Set a cap on the number of children running at once. Grow it without limit and it breaks down on cost and rate limits.
Use different model sizes for a heavy-reasoning parent and simple-task children. Don't make everything the top-tier model.
"Narrow what you pass" in particular is a high-impact design decision. In an orchestrator + workers setup, the parent holds the big picture, but hands children only the carved-out task and the minimal input. The smaller you keep the context a child holds, the higher the accuracy and the lower the cost. Think of this as the context engineering touched on in earlier chapters, extended to multiple agents.
⚠️ Cost scales as "number of agents × number of steps." Add one agent and its calls stack up for every turn of the loop. Note that the more agents, the more each one's waste balloons manyfold across the whole. Decide the parallelism cap and each agent's step cap (when to stop) from the start. This matter of measuring "how much is being used" connects to the next chapter's observability.
Pitfalls and how design prevents them
Multi-agent has failures unique to it that didn't happen with a single agent. In every case, the rule is to prevent them by design in advance, not leave them to luck at runtime. Let's pin down three representative ones and their countermeasures.
Multiple agents do the same work twice, or it's vague "whose job it is" and no one does it.
Prevention: carve up each agent's duties with no overlap and no gaps, to a state where you can state each boundary in one sentence.
A passes to B, B passes to A… they keep pushing work onto each other, never finishing, repeating the same exchange.
Prevention: always set a termination condition and caps on round-trips and steps. Having the center (parent) hold the final judgment makes runaways less likely.
One agent's failure or wrong output flows straight to the next, stopping the whole or building up a flawed result.
Prevention: verify the output before handing off, and decide the fallback on failure (retry, alternative, escalate to a human).
The lesson common to all three is to decide "boundaries, termination conditions, and verification" before you write code. Who is responsible for what (boundaries), when it stops (termination conditions), and what to check before handing off (verification). Weave these three into the design and most of the trouble unique to multi-agent can be prevented before it happens.
📊 "You can't fix what you can't see." You only notice these failures once you're in a state where you can trace after the fact which agent did what. When multiple agents are involved, "where what happened" is even harder to see than with a single one — which is exactly why the next chapter's evaluation and observability matters all the more in multi-agent.
- Overstuff one agent and accuracy drops. Solve with the cooperation of small agents with narrowly split roles.
- There are three basic patterns — orchestrator + workers, pipeline, division of labor. They can be nested.
- Split when parallelism, expertise, or a broad search is needed. If it's simple, stay with one agent. First ask "is one enough?"
- Coordinate via explicit contracts (A2A = the etiquette of connecting agents to each other). Manage context and cost by narrowing them.
- Prevent the unique traps (overlap, hand-offs, cascading failures) by deciding boundaries, termination conditions, and verification in the design up front.
Once multiple agents start running, the next thing you need is to "measure whether it's really working well and make the behavior visible." In the next chapter, Chapter 5, "Evaluation and observability," we move on to how to measure an agent's quality and get to a state where you can trace its internal behavior.