Contents
Once you've grasped the concept of "coordinating multiple AIs" in What is a multi-agent system?, the next question is how to actually build one. This article walks through a 5-step practical process for beginners, using the 2026 de facto standard: the supervisor pattern.
Before any framework talk, here's the most important principle: "build with a single agent first, and only add more — minimally — once you hit a limit." Going multi from the start is usually over-engineering. The code is shown as framework-agnostic pseudo-code, so it applies whether you use MCP or any SDK.
Build small, measure, then add
— The supervisor pattern, from a minimal setup
* Steps and figures in this article are quoted from public materials, practitioner guides, and research reports (as of June 2026). The code is conceptual pseudo-code; check each framework's official docs for the real API.
1. Before you build: do you really need multi?
The first gate isn't technical — it's a judgment call. Multi-agent is powerful, but ~80% of use cases are fine with a single agent. If none of the following apply, build with a single agent first.
3 signs you should go multi
- Specialization split: the knowledge won't fit in one prompt (domains span research, legal, code, etc.)
- Parallelism: doing several tasks at once is clearly faster
- Decision separation: quality improves when you split "doer" and "verifier"
Conversely, using multi for a simple one-track process — as covered last time — inflates cost 3-10x and actually lowers accuracy on sequential tasks (Google research reports −39-70% vs single). Start from the premise that "more agents doesn't mean smarter."
2. The base shape: supervisor (the 2026 default)
If you're unsure which pattern to build, go with the supervisor pattern, full stop. Claude Code subagents, LangGraph Supervisor, OpenAI Agents SDK handoffs — the major implementations have all converged on this shape. The reasons are clear.
Widest framework support
Native support across major frameworks. Plenty of reference implementations.
Known failure mode
The main failure is "over-delegation," bounded by an iteration cap.
Easy to audit
"Who did what" is clear, making it easy to debug.
The mechanics are simple. The supervisor receives the overall task, breaks it into subtasks, delegates them to specialist workers, and aggregates the results. The supervisor needn't know how a worker does its job — only which worker to call and in what output format. The expertise lives in the workers.
3. Build it in 5 steps
Assemble a minimal supervisor setup in five steps. The rule of thumb: start with 2-3 workers, then add more only as measurement justifies it.
STEP 1. Decompose the task
Write down the "end goal" and the "specialist roles" needed. Example: for a market research report, "1) gather info → 2) analyze → 3) write → 4) fact-check." Decompose clearly up front — vagueness here collapses the whole thing.
STEP 2. Define workers (up to 3-5)
Give each worker one role, the tools it needs, and an output format. Don't be greedy at first — 3-5 max. Each worker is independent and holds only its own tools (search, code execution, etc.).
STEP 3. Design the supervisor
In the supervisor's prompt, explicitly list the worker names it may call (a hard cap). The trick: spend more time on the supervisor than on any individual worker. This determines overall quality.
STEP 4. Decide handoff & context sharing
Define what is passed between workers, and in what format. Passing the full context to everyone bloats tokens, so pass only the needed information. The standard protocol for agent-to-agent coordination is A2A.
STEP 5. Measure and run with caps
Instrument every handoff before adding agents (observability is not optional). Set caps on iterations, tokens, and cost. Set up evals and guardrails at the same time.
4. Minimal code example (pseudo-code)
The essence of the supervisor pattern is surprisingly short. Here's framework-agnostic pseudo-code showing the loop where the supervisor picks a worker and runs it (check each SDK's official docs for the real API).
# Define workers: one role + dedicated tools
workers = {
"researcher": Agent(tools=[web_search]),
"writer": Agent(tools=[]),
"factcheck": Agent(tools=[web_search]),
}
# Supervisor: hard-cap the worker names it can call
supervisor = Agent(
instructions="Decompose the goal and pick one worker to call next. "
"Return 'DONE' when finished.",
allowed_workers=["researcher", "writer", "factcheck"],
)
# Run loop (an iteration cap prevents over-delegation)
state = {"goal": "Write an AI market report", "history": []}
for step in range(MAX_STEPS): # <- a cap is essential
next_worker = supervisor.decide(state)
if next_worker == "DONE":
break
result = workers[next_worker].run(state)
state["history"].append({next_worker: result}) # share only needed context
log_handoff(next_worker, result) # <- instrument every handoffThree takeaways: 1) each worker is one role + dedicated tools, 2) the supervisor's callable set is limited, 3) the loop always has an iteration cap. Add measurement, guardrails, and evals onto this skeleton and you approach production quality. Claude Agent SDK and Claude Code subagents follow the same idea.
5. Common pitfalls and fixes
The places people stumble in multi-agent development are fairly predictable. Get ahead of them.
| Pitfall | Fix |
|---|---|
| Over-delegation (supervisor loops forever) | Iteration cap + limit callable workers |
| Token bloat (cost 3-10x) | Stop sharing full context; pass only what's needed + cache |
| Unstable, non-deterministic behavior | Keep workers few (3-5) + fix output formats |
| Accuracy drop on sequential tasks (−39-70%) | Revert to a single agent for one-track work |
| Can't tell where it failed | Instrument every handoff before scaling (observability) |
The shared lesson: "prompts, tool design, and the eval harness decide success more than the framework does." Over a flashy architecture, the discipline of building small, measuring, and adding only when it pays off is what's fastest in the end.
Summary
Building a multi-agent system isn't scary if you start with the supervisor pattern from a minimal setup. Let's recap.
Key takeaways
- 🚦 Single first. Add agents only after signs of specialization / parallelism / decision separation appear.
- 🧠 The base shape is the supervisor (2026 default). Spend the most time on the supervisor's design.
- 🔢 5 steps: decompose → define workers (3-5) → design supervisor → handoff → measure.
- ⚠️ Pitfalls: over-delegation, token bloat, instability. Fix with caps, need-only sharing, and measurement.
- 📏 Discipline: prompts, tools, and evals decide success more than the framework.
"Build small, measure, then add." Keep that discipline and a multi-agent system becomes a powerful partner for complex work. For the concept, see What is a multi-agent system?; for building a single one, How to build an AI agent.
FAQ
Q. Which pattern should I build first?
A. The supervisor pattern, no question. Major frameworks support it, its failure mode is known, and reference implementations are the most abundant. Explore other patterns once you're comfortable.
Q. How many workers should I start with?
A. Start with 2-3, and keep it to 3-5 at most. The more you add, the more unstable it gets and the more tokens balloon. The norm is to add more only once measurement proves the need.
Q. Is a framework required?
A. Not required. As the pseudo-code shows, a loop plus prompts can build a minimal setup. But if you need state persistence, observability, and recovery in production, a supporting framework is a shortcut.
Q. How do I prevent cost blowups?
A. Three things help: 1) cap the iteration count, 2) share only needed context instead of the full thing, and 3) use prompt caching. Going multi can cost 3-10x a single agent, so caps are essential from day one.
