Multi-Agent Systems
One agent is a worker. Many agents, coordinated, are a team — and a team needs an org chart. This is the top rung of the autonomy spectrum: you set policy and the agents do the work.
Instead of one helper doing everything, you can have a team: a “boss” hands out jobs to specialist helpers (one searches, one writes, one checks), then puts their work together — like a group project with a leader.
Why use more than one agent?
☺ Like you’re 10: One super-helper trying to cook, clean, and do homework all at once gets muddled — but a small crew where each kid has one job, and they all work at the same time, gets more done and can double-check each other.
Three reasons, and they mirror why human teams exist:
- Specialization. A focused agent with a tight toolset and a narrow prompt outperforms one generalist juggling everything. A “database agent,” a “frontend agent,” and a “test agent” each do one thing well.
- Parallelism. Independent subtasks run at the same time. While one agent writes tests, another updates docs and a third refactors a module — wall-clock time drops.
- Safety & separation of duties. The agent that writes code shouldn’t be the only one that reviews it. Separate roles create checks and balances, exactly like requiring a second human reviewer.
Multi-agent systems add real coordination cost — context-passing, error propagation, and debugging across agents. Most problems are solved better by one good agent with the right tools. Add agents only when a single one is genuinely overloaded or when separation of duties matters. Complexity is a cost, not a feature.
The four coordination patterns
☺ Like you’re 10: There are a few ways a team can be arranged — a captain handing out tasks, an assembly line where each person passes their work to the next, a writer with an editor who checks it, or captains-of-captains for a really big job — just like different ways to set up a group project.
1 · Orchestrator–worker (manager / sub-agents)
A lead agent breaks a goal into subtasks, delegates each to a worker, and synthesizes the results. The most common and most useful pattern.
2 · Pipeline / sequential
Agents form an assembly line; each one’s output is the next one’s input. Natural when stages have a real order.
3 · Reviewer / debate (generator + critic)
One agent produces, another critiques, and they iterate until quality clears a bar. This is exactly what the cloud agent does when it self-reviews before opening a PR.
4 · Hierarchical
Orchestrators of orchestrators, for genuinely large efforts: a top-level agent coordinates mid-level leads, each of which coordinates its own workers. Powerful and complex — reserve it for big problems that truly decompose this way.
A worked example: a research pipeline
☺ Like you’re 10: Imagine the boss helper wants to compare three toys, so it sends three friends to each study one toy, then hands all three reports to a fourth friend who writes the winner — but that last friend only knows what’s written in the note handed to it, nothing the others saw in their heads.
Make it concrete. Say the goal is “research how three libraries handle rate-limiting and recommend one.” A natural design is one orchestrator plus a few workers:
- The orchestrator splits the goal into three identical sub-tasks — one per library — and spawns a search worker for each, in parallel.
- Each search worker reads the docs and source for its library and returns a short, structured finding: approach, limits, caveats.
- A synthesis worker compares the three findings and drafts the recommendation.
- The orchestrator returns the final answer.
Here’s the part people get wrong — and the single most-tested idea in this topic: sub-agents don’t share memory. The synthesis worker can’t “see” what the search workers found just because they ran in the same system; there is no shared scratchpad and no automatic history passing. If the synthesiser needs those three findings, the orchestrator must place them, explicitly, into the synthesiser’s prompt.
Olly the Octopus: One big job — compare three libraries — so I hand one library to each arm and they all read at once.
Foxy: So the friend who writes the winner already saw everything the others found, right?
Professor Owl: No — that’s the trap. Each helper only knows the note you hand it. Olly must copy the three findings into the writer’s brief, or it’s writing blind.
Timmy the Turtle: And check before you split: three libraries, three arms — fair. But don’t give one tiny task ten arms; the extra chatter costs more than it saves.
Every piece of context a sub-agent needs must be passed in explicitly. Treat each agent like a contractor who started this morning and can only see the brief you hand them. (Anthropic’s CCAR-F tests this directly — and it’s why over-large hand-offs are the other failure mode: pass enough, but no more.)
How agents coordinate: shared context
☺ Like you’re 10: The tricky part isn’t having helpers — it’s handing each one exactly the right sticky-notes: too few and they get confused, too many and they can’t find the one that matters, like packing a school bag with just what you need for today.
The hard part of multi-agent systems isn’t spawning agents — it’s passing the right context between them without drowning each in irrelevant detail. Common mechanisms: a shared scratchpad or memory all agents read and write; structured handoffs where one agent’s output is formatted as the next’s input; and an orchestrator-mediated approach where the lead holds the global picture and gives each worker only what it needs. The principle: each agent needs enough context to do its job and no more — too little and it flounders, too much and it loses focus and burns tokens.
Multi-agent in real tools
☺ Like you’re 10: You don’t have to build the team machine yourself — the tools already come with a “mission control” that hires and arranges the helpers for you, a bit like a board game that comes with the rules and pieces already in the box.
You don’t have to hand-build orchestration — today’s coding platforms ship it at several levels. GitHub Copilot, Anthropic’s Claude Code, and OpenAI’s Codex CLI each provide their own take on the same ideas:
- A control plane / mission control. Most platforms give you one place to launch agents and watch many tasks run in parallel. GitHub’s Agent HQ lets you run agents from multiple providers (Anthropic, OpenAI, Google, Cognition, xAI) on a unified platform across GitHub, VS Code, the CLI, and mobile; the GitHub Copilot app’s “My Work” view does the same on the desktop; and Anthropic’s Claude Code offers a parallel model through its own dashboard and background/cloud sessions. It’s the “mission control” for orchestrating many agents on your codebase.
- Built-in specialized sub-agents. Rather than making you wire up roles by hand, the tools spawn them for you. The Copilot CLI runs parallel specialized sub-agents (an Explore agent, a Plan agent, a Code agent, a Code-Review agent) under one task; Claude Code ships the same idea as its sub-agents, where a lead agent delegates to focused workers with their own tools and context. Either way, that’s the orchestrator–worker and generator–critic patterns shipped as a product feature.
- An SDK for custom orchestration. When you need custom coordination, you compose multiple sessions and custom agents in code, applying the patterns above to your own domain. The Copilot SDK, the Claude Agent SDK (see building with Claude), and OpenAI’s Agents SDK all serve this role.
Pitfalls to respect
☺ Like you’re 10: A bigger team also brings bigger headaches — it costs more snacks to feed everyone, one early mistake gets copied down the line like a wrong step in a recipe, and it’s hard to tell who spilled the milk when there’s a whole crowd in the kitchen.
- Cost multiplies. Five agents can mean five times the premium requests. Multi-agent runs get expensive fast.
- Errors propagate. A mistake early in a pipeline contaminates everything downstream — like a bad merge that ripples through later commits.
- Debugging is harder. Tracing which agent made which decision needs good observability (a major theme of the pipelines and operations topics).
- Coordination overhead can swamp the benefit. If agents spend more effort talking to each other than doing work, collapse back to one agent.
If you have an agentic CLI with sub-agents (GitHub Copilot CLI, Anthropic’s Claude Code, or OpenAI’s Codex CLI), give it a task complex enough to trigger them (e.g. “explore this repo, plan a refactor of the auth module, implement it, and review your own changes”) and watch the explore/plan/code/review roles work in parallel. Otherwise, design a multi-agent solution on paper for “take a feature request and ship a tested, documented PR”: name each agent, its tools, its inputs/outputs, and where a human gate belongs. Then ask: could one good agent do this instead?
(1) Give the three reasons to use multiple agents. (2) Match a pattern to each: “stages in a fixed order” / “a manager splitting work” / “write-then-critique.” (3) What’s the single hardest part of multi-agent coordination? (4) Name two real pitfalls.
Check your answers
- Three reasons: Specialization (a focused agent with a tight toolset beats one generalist juggling everything), parallelism (independent subtasks run at the same time, cutting wall-clock time), and safety & separation of duties (the agent that writes code shouldn’t be the only one that reviews it).
- Pattern matches: “Stages in a fixed order” is the pipeline / sequential pattern (each agent’s output is the next one’s input). “A manager splitting work” is orchestrator–worker (a lead breaks a goal into subtasks, delegates, and synthesizes). “Write-then-critique” is the reviewer / debate pattern (generator + critic, iterating until quality clears a bar).
- Hardest part: Passing the right context between agents without drowning each in irrelevant detail. Sub-agents don’t share memory, so every piece of context a worker needs must be placed explicitly into its prompt — enough to do the job, and no more.
- Two pitfalls: Any two of — cost multiplies (several agents can mean several times the premium requests), errors propagate (a mistake early in a pipeline contaminates everything downstream), debugging is harder (tracing which agent decided what needs good observability), and coordination overhead can swamp the benefit.