A single agent with a well-designed tool set and a decent evaluation suite can go a long way. But past a certain point - too many tools for one model to reason over well, or a task that genuinely splits into specialized sub-tasks - the fix usually isn't a bigger prompt on the same agent, it's splitting the work across multiple agents that each do one thing well.
Why split at all
The core problem multi-agent systems solve is focus: a single agent juggling twenty tools across research, writing, and data analysis has to reason about all twenty on every planning step, which increases the odds it picks the wrong one. Give three separate agents five tools each, tightly scoped to research, writing, and analysis respectively, and each one's job is simpler to reason about - the tradeoff is that now something has to decide which agent handles what, and how results move between them.
The supervisor pattern
The most common architecture is a supervisor (sometimes called an orchestrator or router): a top-level agent that doesn't do the actual task work itself, but decides which specialized sub-agent should handle the current step, sends it the relevant context, and integrates its result before deciding what happens next. This is structurally the same plan-act-observe loop from earlier in this series - the supervisor's "tools" are simply other agents instead of individual functions.
The supervisor never does the task work itself - it routes to the right specialist and integrates what comes back.
Handoffs: what actually gets passed between agents
A handoff is the moment control (and context) transfers from one agent to another, and getting it right is mostly about deciding what the receiving agent actually needs to see. Passing the entire conversation history to every sub-agent is simple but wasteful and can confuse a specialist with irrelevant context from a different part of the task; passing only a minimal, purpose-built summary keeps each sub-agent focused but requires more deliberate design of what to include. Most production systems land somewhere in between: a structured handoff object with the specific inputs a sub-agent needs, not the full raw history.
Peer-to-peer vs. hierarchical
The supervisor pattern is hierarchical - one agent directs others, and they don't talk to each other directly. An alternative is peer-to-peer, where agents can hand off directly to one another without a central router, which can be more flexible but is meaningfully harder to reason about and debug, since there's no single place that shows the full picture of what's happening. Most production systems favor the hierarchical pattern specifically because it keeps that single point of visibility, even at some cost to flexibility.
When multi-agent is worth the added complexity
Splitting into multiple agents adds real overhead: more moving pieces to evaluate, more places for handoffs to lose important context, and more latency from the extra coordination step. It's worth that cost when a single agent's tool set has genuinely grown unwieldy, when sub-tasks benefit from different system prompts or even different models (a cheaper, faster model for simple lookups; a stronger one for the reasoning-heavy step), or when you want to evaluate and iterate on one piece of the pipeline independently of the others. It's not worth it just because "multi-agent" sounds more sophisticated - a single well-scoped agent is simpler to build, evaluate, and debug, and remains the right choice for most tasks.