Lesson 1 - Why and When to Use Multiple Agents

Welcome to Why and When to Use Multiple Agents#

You’ve spent six modules making one agent better and better. It loops, uses tools, remembers, plans, and retrieves. So here’s a fair question: why would you ever want more than one? The honest answer is that you often don’t — a single well-built agent handles a surprising amount. But there’s a point where one agent trying to do everything starts to buckle: its system prompt grows into a wall of instructions, its tool list gets so long the model picks the wrong tool, and juggling several unrelated concerns in one context makes it lose focus. When you hit that point, the fix is the one human teams reach for — split the work among specialists and coordinate them. This lesson is about recognizing that point and knowing what to build.

By the end of this lesson, you will be able to:

• Explain the two real benefits of multiple agents: specialization and focused context
• Name the real cost — coordination — and why a single agent is the right default
• Recognize the signals that a job has outgrown one agent
• Identify the three coordination patterns this module teaches and when each fits

Let’s start with what actually goes wrong with one overloaded agent.

When One Agent Isn’t Enough#

A single agent works by carrying everything in one context: one system prompt describing all its jobs, one tool list covering all of them, one running conversation mixing all the concerns. That’s efficient right up until the job gets broad. Then three things degrade at once:

• The prompt bloats. “You plan trips, and estimate budgets, and check weather, and recommend food, and cite sources, and…” — the more roles you cram in, the more the model’s attention is split and the more instructions quietly get ignored.
• The tool list sprawls. With five tools the model chooses well; with twenty, spanning unrelated jobs, it starts calling the wrong one. Tool selection gets noticeably worse as the list grows.
• The context gets muddled. Budget details, weather results, and food notes all pile into one transcript, and the agent loses the thread of what it’s actually doing right now.

The insight behind multi-agent systems is that each of those problems disappears if you give each concern its own agent — its own tight prompt, its own small tool set, its own clean context. A destination researcher with just retrieval tools stays sharp on research. A budget analyst with just cost tools stays sharp on budgets. Focus is restored by division of labor.

Specialists, Coordinated#

So a multi-agent system is a set of focused agents plus a way to coordinate them. The most common shape is a supervisor (or orchestrator) that delegates to specialists:

Here’s the key idea that makes this not a new engine: a specialist agent is exposed to the supervisor as an ordinary tool. The supervisor calls research_destination(...) exactly the way it calls any tool — but behind that tool is a whole other agent running its own loop with its own tools. The supervisor doesn’t know or care that the “tool” is really an agent; it just gets a result back. That means the entire coordination story is built from the run_agent loop and tool mechanics you already have. You’re composing agents, not inventing a framework.

Three Patterns, One Loop#

When you do split the work, three patterns cover most real systems — and this module builds each one on the run_agent loop you already have:

• Agents as tools (Lesson 2) — a supervisor delegates to a specialist sub-agent exposed as a tool. Best when a hard sub-problem deserves its own focused agent (say, retrieval-grounded research).
• Routing (Lesson 3) — a lightweight classifier reads each request and dispatches it to exactly one specialist. Best when requests fall into distinct categories and you want the right expert to handle each.
• Orchestrator-workers (Lesson 4) — an orchestrator decomposes a task into subtasks, runs a worker on each (often in parallel), and synthesizes their outputs. Best when one goal breaks cleanly into independent pieces.

They combine, too: a real system might route a request to a supervisor that orchestrates workers, one of which is an agent-as-tool researcher. The module ends by assembling exactly that kind of small team as a multi-agent Atlas.

Practice Exercises#

Exercise 1: One agent or many?#

Which of these is fine for a single agent, and which is a candidate for splitting? (a) “Answer weather questions for a city.” (b) “Research a destination, estimate a budget, check the weather, recommend restaurants, and write a cited multi-day itinerary.”

Exercise 2: Why is a specialist “just a tool”?#

The supervisor calls research_destination(question) and gets an answer back. Why does that mean multi-agent systems need no new machinery beyond the agent loop?

Exercise 3: Match the pattern#

Match each to agents-as-tools, routing, or orchestrator-workers: (a) “sort each incoming message into billing, technical, or sales and send it to that team”; (b) “break ‘plan a trip’ into research + budget + itinerary, do each, then merge”; (c) “let the planner call a dedicated retrieval-grounded research agent when it needs facts.”

Summary#

A single agent carries every job in one context, which works until the job gets broad — then the prompt bloats, the tool list sprawls, and the context muddles, and quality drops. Multi-agent systems fix this by dividing work among specialists, each with its own focused prompt and small tool set, coordinated by a supervisor. The move that keeps this simple is that a specialist agent is exposed as an ordinary tool — so the whole system is built from the run_agent loop and tool mechanics you already have. The cost is coordination (more calls, more latency, more moving parts), which is why a single agent is the right default and you split only when one agent is measurably struggling. Three patterns cover most systems: agents-as-tools, routing, and orchestrator-workers.

Key Concepts#

• Why split — specialization and focused context restore quality when one agent is overloaded.
• The cost — coordination (more calls, latency, moving parts); prefer one agent until it struggles.
• Specialist = tool — delegation is a normal tool call whose body is another agent; no new engine.
• Three patterns — agents-as-tools (delegate a sub-problem), routing (classify then dispatch), orchestrator-workers (decompose, run workers, synthesize).

Why This Matters#

Knowing when to go multi-agent is as important as knowing how. Reach for it too early and you pay coordination cost for no benefit — a slower, pricier, flakier system than a single clean agent. Reach for it at the right moment and you unlock problems one agent can’t hold: broad tasks that decompose into focused expert jobs. And because every pattern is just the agent loop composed with itself, you can adopt them incrementally — turn one overloaded tool into a sub-agent, add a router in front, grow an orchestrator — without ever leaving the mental model you already have. Next, you’ll build the foundational pattern: a specialist agent exposed to a supervisor as a tool.

Next Steps#

Continue Building Your Skills#

You now know why and when to split work across multiple agents — the specialization and focus you gain, the coordination you pay, and the three patterns that structure it. Next you’ll build the foundational one: expose a specialist agent to a supervisor as a tool, so the supervisor can delegate a hard sub-problem and get a clean result back.