Module 1: Why Multi-Agent (and When Not To)

Description

This is the multi-agent orchestration guide — the direct continuation of agent-fundamentals-and-tool-calling-guide. There, you built one agent: a model with tools, a loop that requests-dispatches-feeds-repeats, and up to four tools available at once for the model to learn to choose between. That agent already solves multi-step tasks, with tools that compose, and a final answer grounded in what the tools actually returned. The question that opens this guide is the one that agent leaves open: what happens when a task is too big, or too different across its parts, for a single agent?

The obvious answer — "add more agents" — is also the most dangerous one if taken without measuring. Coordinating several agents isn't free: every extra agent is one more model you have to ask for a decision, one more message to pass, one more point where something can go wrong. This entire module — the eight that follow build the patterns; this first one builds the criterion — exists to answer a single question before you write a single line of orchestration: does this task genuinely need several agents, or does a single agent with the right tools already do the job? You're going to measure that question, not just discuss it: you'll run the SAME Reservo task with one agent and with a two-agent system, count the model calls and the messages between agents on each path, and see with real numbers which one costs more.

The hard rule of this guide (read it before continuing)

We keep the same line as agent-fundamentals: each agent's decision — which tool to call, who to delegate to, what to answer — is not executed. It's a hand-written script, labeled as concept (claude-sonnet-5), never a real API call. What is actually executed, for real, with Python 3.14 and its standard library, is the orchestration: each agent's runner (reused unchanged from agent-fundamentals M4/M5), the passing of messages between agents, and — the heart of this module — the real count of how many calls and how many messages it takes each path to solve the same task. No LangChain, no LangGraph: everything hand-built, stdlib, deterministic (no random, no datetime.now()).

Where we are in the ecosystem

agent-fundamentals-and-tool-calling-guide (already complete)
  -> built ONE agent: tools, protocol, the loop, multi-tool, memory, robustness

multi-agent-orchestration-guide (this guide)
├── Module 1: Why multi-agent (and when not to)  ← YOU ARE HERE
│   → The decision criterion, measured with real numbers
├── Module 2: The supervisor/router pattern
├── Module 3: Sequential pipelines
├── Module 4: Parallel fan-out and aggregation
├── Module 5: Handoff and delegation
├── Module 6: Shared state and the blackboard pattern
├── Module 7: Orchestrating Reservo's full system
└── Module 8: Project — Reservo's multi-agent system

Every "agent" in this guide is an agent-fundamentals agent: same runner, same tool_use/tool_result protocol, same canonical tools. What changes is the scale: instead of one agent with four tools choosing which one to use, you'll have several agents — each with a narrower set of tools and a more specialized role — choosing among each other. The loop's while and a tool's contract aren't re-explained; they're assumed built and reused as-is.

Analogy: putting together a team of people

Picture a work task. If it's small — drafting an email, calculating a total — you do it yourself, without asking anyone for help: asking for help there only adds a meeting to explain the task, time waiting for the other person to understand and solve it, and then merging their result with yours. None of those three things makes the email get written any faster.

But if the task is genuinely big — organizing an event with catering, logistics, and invitations — a single employee with no experience in any of the three areas takes much longer, and makes more mistakes, than three specialists each working on their own piece. The difference isn't "more people always helps" or "fewer people is always simpler" — it's whether the task genuinely splits into distinct parts, each requiring expertise the others don't have.

A multi-agent system is exactly that team. It's worth it when the work is genuinely separable and each specialist brings something the others don't have. For a task that one person — or one agent with the right tools — already solves well, adding more people only adds meetings (coordination) without finishing any sooner. This whole module is about learning to tell when you're facing an event with catering and logistics, and when you're facing an email.

The case running through this guide: Reservo's multi-agent system

agent-fundamentals built a single agent with four canonical tools — list_rooms, get_quote, book_room, cancel_booking — over the same Reservo, the coworking room-booking system used across the whole ecosystem. This guide takes that agent and, where it genuinely calls for it, splits it into three specialists:

booking_agent — the four canonical tools, unchanged. Quotes, books, cancels.
policy_agent — a new tool, search_docs(query) -> str, a minimal stub (2-3 fixed keyword-indexed entries, with the same document names — no-show-policy, cancellation-policy — as the real index from production-rag-and-document-ingestion-guide, without rebuilding that full index). Answers policy questions.
pricing_agent — no new tool: it composes booking_agent's get_quote to compare the cost of several rooms or tiers in a single answer. This is the example of a specialist whose "expertise" is a different way of using a tool that already exists, not a new tool.

The usual anchors don't change: Focus basic 3h = 7500 / Focus pro 3h = 6000 (a flat 20% pro discount, * 80 // 100), rooms Focus 2500 / Studio 4000 / Boardroom 8000 per hour, money always in cents (int). You'll see them come back in every lesson of this module.

Boundary with `building-ai-agents-guide` Module 8

Before continuing, a clarification that heads off a real confusion: building-ai-agents-guide — another guide in the ecosystem, already published — has a Module 8 also called "Multi-Agent Orchestration" that also teaches Supervisor, Handoffs, Subagents, and Router. If you've already taken that guide, the vocabulary will sound familiar. The real difference:

	`building-ai-agents-guide` M08	This guide (all 8)
Framework	LangGraph/LangChain (requires a real API)	None — Python 3.14 stdlib, $0
Case	Generic Research Agent (Supervisor/Researcher/Analyst/Writer)	Reservo: `booking_agent`/`policy_agent`/`pricing_agent`, real expertise
Scope	5 lessons in one module of an 80-lesson project	Full 8-module guide, one pattern per module
The angle	"Here are the patterns, implement them"	"Does this even need a pattern, or not?" — this whole module
Coordination cost	One framing paragraph	Measured, executed, with real numbers (lesson 05)

You won't relearn what an agent is or the tool_use/tool_result protocol — you already built that in agent-fundamentals, the foundation of the whole ecosystem, not just that guide. And you won't use LangGraph here: every pattern is built by hand, so you understand what an orchestration framework does under the hood before deciding whether to adopt one. Lesson 07 revisits this boundary in more detail, pattern by pattern.

Prerequisites

Required knowledge:

✅ agent-fundamentals-and-tool-calling-guide complete: a tool's contract, the tool_use/tool_result protocol, the loop's while, multi-tool and selection, parallel tool calls with concurrent.futures, grounding.
✅ Python: dataclasses, dictionaries, functions, concurrent.futures at a usage level (no need to rebuild it).

NOT required:

❌ You don't need an API key or an internet connection: each agent's decision is concept, hand written.
❌ You don't need to know LangChain, LangGraph, CrewAI, or any orchestration framework — this guide builds the patterns from scratch, on purpose.

Environment:

✅ Python 3.14.0 with its standard library. Nothing to install.

Module roadmap

Lesson 01 — Module introduction (this one)

The decision criterion, the Reservo case with its three specialists, and the boundary with building-ai-agents-guide M08.

Lesson 02 — What a multi-agent system is

Several agents collaborating, each with its own loop and its own tools — the formal definition, contrasted with a single agent that just has more tools.

Lesson 03 — The cost of coordination

More agents means more model calls, more steps, more surface for error. Measured with an executed formula, not with intuition.

Lesson 04 — One agent with many tools vs. many agents

The referee between two ways to grow: an ever-larger tool set (whose cost was already measured in agent-fundamentals M5) vs. splitting those tools across several specialized agents.

Lesson 05 — The executed comparison

The centerpiece of the module: the SAME Reservo task solved by one agent and by a two-agent system, with the calls and messages actually counted.

Lesson 06 — When multi-agent actually helps

The other side of the scale: genuinely separable tasks, tools that collide when combined, and contexts worth isolating.

Lesson 07 — A preview of the patterns

A map of the five patterns that modules 2 through 6 build — what each one solves and when to use it — plus more detail on the boundary with building-ai-agents-guide M08.

Lesson 08 — Mini-project: decide single or multi

You apply the module's full criterion to several new scenarios, with a decision function you run yourself and then question.

Progression map

Lesson 01 (this one) → The criterion, the case, the boundary
Lesson 02             → What a multi-agent system is (and isn't)
Lesson 03             → The cost of coordination, measured
Lesson 04             → One agent with more tools vs. splitting tools
Lesson 05             → The executed comparison (the dense one)
Lesson 06             → When multi-agent is genuinely justified
Lesson 07             → The five patterns coming up
Lesson 08             → Project: deciding with criteria

Difficulty: ⭐⭐ ──────────────────▶ ⭐⭐⭐

What you'll achieve in this module

By completing the 8 lessons, you'll be able to:

Define a multi-agent system and precisely distinguish it from a single agent with several tools.
Quantify the cost of coordinating — model calls, messages between agents, error surface — instead of assuming or ignoring it.
Choose between growing a single agent or splitting tools across several, with the cost of each path measured, not guessed.
Run and compare, with real numbers from your own terminal, the same task solved by one agent and by a two-agent system.
Recognize the three signals that actually justify multi-agent: genuine separability, distinct expertise, need to isolate context.
Place the five upcoming patterns (supervisor, pipeline, fan-out, handoff, blackboard) and know, broadly, when to use each.
Apply the full criterion to a new scenario and justify the decision with evidence, not intuition.

Before and after

BEFORE the module:
→ "More agents always solves things faster and better"
→ "If one agent does a lot, the solution is splitting it into several"
→ "Coordinating several agents has no real cost, just more capacity"
→ "Roles (supervisor, researcher, critic) always help thinking"

AFTER the module:
→ Multi-agent helps ONLY when the task is genuinely separable
→ One agent with the right tools solves a non-separable task better
→ Coordinating costs: more calls, more messages, more error surface -- MEASURED
→ A role without a real tool or expertise behind it is decoration, not architecture

Traps to avoid while taking this module

1. "A system with 3 agents is more sophisticated than one with 1"

No. Sophisticated isn't a synonym for better. A 3-agent system that solves in 8 calls what one agent solves in 3 isn't sophisticated — it's more expensive, slower, and has more failure points, for the same result. Lesson 05 measures it.

2. "Roles like CEO, researcher, or critic give structure to reasoning"

Sometimes. But a role without a tool or a data domain setting it apart from the others is theater, not architecture — it costs the same in calls and messages as a real role, without adding any new capability. Lesson 06 shows the difference with a measured example.

3. "This module already teaches me how to build the supervisor"

Not yet. This module measures whether a pattern is needed — the full supervisor, with rule-based and model-decided routing, is Module 2. Here you build the criterion you'll apply in every module that follows.

4. "If `building-ai-agents-guide` already covered this, this guide is redundant"

No. That guide teaches the patterns with LangGraph, over a generic research case, in 5 lessons of one module. This guide builds them without a framework, over Reservo, with the cost of every decision measured — a depth that guide has no room to give.

5. "The decision about which agent to delegate to is actually being executed"

No. Hard rule: what each agent does and who it delegates to is concept (claude-sonnet-5). What gets executed is each agent's runner, the passing of messages between them, and the count of that coordination cost.

How to work through this module

Run lesson 05's comparison yourself. It's the piece that holds up the whole module — seeing it with your own numbers, not just reading it, is what makes the criterion feel real.
Don't assume multi-agent is "more advanced" or "better architecture." Every lesson asks you to justify with a concrete signal (separability, expertise, isolation), not intuition.
The mini-project is the synthesis. Lesson 08 gives you new scenarios and a decision function — practicing with it before Module 2 makes every pattern that follows feel justified, not arbitrary.

Estimated time:

Lesson 01 (this one) →  15 min reading
Lesson 02             →  20 min + running the demo
Lesson 03             →  25 min + running the demo
Lesson 04             →  25 min + running the demo
Lesson 05             →  35 min + running the demo (the densest one in the module)
Lesson 06             →  25 min + running the demo
Lesson 07             →  20 min reading
Lesson 08             →  30 min + applying the criterion

Total: ~3.2 hours

Evidence of success

Before moving on to Module 2 (The supervisor/router pattern), you should be able to:

✅ Explain what a multi-agent system is in your own words, without confusing it with an agent that just has several tools.
✅ Cite from memory the result of lesson 05's executed comparison: how many extra calls and messages the two-agent system costs versus the single agent, for the same task.
✅ Name the three signals that justify multi-agent, and give a Reservo example for each.
✅ Place which of the five patterns (supervisor, pipeline, fan-out, handoff, blackboard) applies to a new scenario, broadly.
✅ Apply the module's criterion to a scenario you haven't seen before, and justify the decision with evidence.

Summary

This guide orchestrates several Reservo agents — each the same type of agent you built in agent-fundamentals, with a narrower role — to solve tasks a single agent doesn't handle well.
Module 1 doesn't build any pattern yet: it builds the criterion for deciding whether one is needed, and measures it with real numbers, not intuition.
Hard rule: each agent's decision is still concept (claude-sonnet-5); each agent's runner, the passing of messages, and the count of coordination cost are actually executed with Python 3.14.
The case is three Reservo specialists — booking_agent, policy_agent, pricing_agent — with genuinely distinct expertise, not decorative roles.
Clear boundary with building-ai-agents-guide M08: same pattern vocabulary, completely different depth and focus — no framework, with the cost of every decision measured.

Next lesson: 02 — What a multi-agent system is. We precisely define what sets several agents collaborating apart from a single agent with more tools, and why that distinction matters before building anything.

Additional resources

Anthropic — Building effective agents — The principle of starting with the simplest solution and adding complexity (more tools, more agents) only when the task demands it; the throughline of this entire module.
Anthropic — Multi-agent research system — A real Anthropic case study on when a multi-agent system was justified and what coordination cost they had to solve for.
Anthropic — Tool use (function calling) overview — The protocol every agent in this guide keeps following, unchanged, for its own tools.
Python 3.14 — What's New — The version this guide's entire orchestration runs on.

Next →What a multi-agent system is