Module 8 — Multi-Agent Systems 👥

Goal of this module: Learn what happens when you use multiple agents together as a team — why you’d do it, how they coordinate, the common patterns (orchestrator, pipeline, debate), and the trade-offs. By now you understand a single agent deeply; this module scales it up.

8.1 The idea: a team beats a soloist (sometimes)

So far we’ve built one agent that plans, uses tools, remembers, and reflects. But some jobs are too big or varied for a single agent. Just like a company hires specialists instead of one person who does everything, you can build a multi-agent system: several agents, each with a role, working together.

Definition: A multi-agent system is multiple AI agents — often with different roles, tools, or instructions — that collaborate (or sometimes compete) to accomplish a goal.

Analogy: A newspaper. You don’t want one person who is reporter, editor, fact-checker, and publisher all at once. You want a reporter to gather facts, an editor to polish, a fact-checker to verify. Each is a specialist agent.

8.2 Why use multiple agents?

Splitting work across agents helps because:

Specialization: Each agent has a focused job, a tailored prompt, and only the tools it needs. A “researcher” agent and a “writer” agent each do their one thing well.
Focus / less confusion: A single agent juggling 20 tools and 5 goals gets confused. Smaller scope = better decisions.
Separation of concerns: Easier to build, test, and debug one specialized agent at a time.
Parallelism: Multiple agents can work at the same time (e.g., three researchers each cover a different topic simultaneously), saving time.
Checks and balances: One agent can review another’s work (like the critic from Module 7), improving quality.

But beware (important!): More agents = more complexity, cost, and ways to fail. Don’t reach for multi-agent unless a single agent genuinely struggles. Start with one agent; split only when needed.

8.3 Roles: giving each agent a job

In a multi-agent system, each agent gets a role defined by its system prompt. Common roles:

Orchestrator / Manager: The “boss.” Breaks the goal into tasks and assigns them to other agents. Doesn’t do the detailed work itself.
Worker / Specialist: Does one type of task (research, coding, writing, data analysis).
Critic / Reviewer: Checks others’ work for errors (reflection, but as a separate agent).
Planner: Designs the overall approach (sometimes separate from the orchestrator).

Example team for “Write a market research report”:

Orchestrator  → plans the report, assigns sections
Researcher    → gathers facts and data (has web_search)
Analyst       → interprets the data, finds insights
Writer        → turns insights into clean prose
Critic        → reviews for accuracy and clarity

Each is a separate agent with its own prompt and tools, coordinated toward one report.

8.4 The main coordination patterns

How do the agents actually work together? Here are the patterns you must know.

(a) Orchestrator–Worker (manager delegates)

A central orchestrator breaks the goal into sub-tasks and hands them to worker agents, then combines their results.

                ┌──────────────┐
                │ Orchestrator │
                └──────┬───────┘
          ┌───────────┼────────────┐
          ▼           ▼            ▼
     Worker A     Worker B     Worker C
   (research)    (research)    (research)
          └───────────┼────────────┘
                      ▼
                Orchestrator combines results → final answer

✅ Clear control, easy to add workers, supports parallel work.
❌ The orchestrator is a bottleneck/single point of failure.
Best for: tasks that split cleanly into independent sub-tasks.

(b) Pipeline / Sequential (assembly line)

Agents work in a fixed order, each passing its output to the next.

Researcher → Analyst → Writer → Critic → Final
   (facts)   (insights) (draft)  (polish)

✅ Simple, predictable, each stage specialized.
❌ Rigid; a mistake early flows downstream; no parallelism.
Best for: workflows with clear, ordered stages (like our report example).

(c) Debate / Collaboration (agents discuss)

Multiple agents discuss or argue to reach a better answer. One proposes, another challenges, they refine together.

Agent 1: "I think the answer is X because..."
Agent 2: "But that ignores Y, so maybe Z..."
Agent 1: "Good point — then the answer is Z."
→ Consensus: Z

✅ Catches errors, explores more options, improves reasoning.
❌ Slower, more expensive, can go in circles.
Best for: hard problems where multiple perspectives help (analysis, decisions).

(d) Hierarchical (teams of teams)

An orchestrator manages sub-orchestrators, who manage workers — like a company org chart. Used for very large, complex tasks. (Connects to hierarchical planning from Module 3.)

8.5 How agents communicate

Agents need to pass information to each other. Common ways:

Messages: Agents send text messages to each other (like a group chat). The orchestrator reads worker replies.
Shared memory / scratchpad: All agents read and write to a shared “whiteboard” (often a shared memory store from Module 6). Agent A writes findings; Agent B reads them.
Handoffs: One agent finishes and explicitly passes the task (and relevant context) to another. (“Researcher → here’s the data, Writer, your turn.”)

   Agent A ──writes──►  ┌──────────────────┐  ◄──reads── Agent B
                        │  Shared scratchpad│
   Agent C ──reads───►  └──────────────────┘  ◄──writes── Agent A

Watch out: Passing too much context between agents wastes tokens and causes confusion. Pass only what the next agent needs — a clean handoff, not a brain dump.

8.6 A worked example (orchestrator + workers + critic)

Goal: “Create a one-page summary comparing three smartphones.”

ORCHESTRATOR: "I'll split this by phone. Assign one researcher per phone,
               then have the writer combine and the critic review."

  Researcher-1 → gathers specs/price/reviews for Phone A  ┐
  Researcher-2 → gathers specs/price/reviews for Phone B  ├ run in PARALLEL
  Researcher-3 → gathers specs/price/reviews for Phone C  ┘

ORCHESTRATOR: collects all three reports → hands to Writer.

  WRITER → writes a clean comparison table + summary.

  CRITIC → "The price for Phone B looks outdated; double-check."
ORCHESTRATOR: sends Phone B back to Researcher-2 to verify → fix → done.

FINAL: polished one-page comparison.

Notice the patterns combine: orchestrator–worker + parallelism + pipeline (research→write→review) + a critic. Real systems mix patterns.

8.7 Single agent vs. multi-agent: which to use?

Use a single agent when…	Use multi-agent when…
The task is small/medium	The task is large or has distinct phases
One set of tools covers it	Different parts need different specialties
Speed and simplicity matter	Quality benefits from review/debate
You’re starting out	A single agent is clearly overwhelmed

The golden rule: Start simple. A well-built single agent solves most problems. Add agents only when one agent genuinely can’t cope. Every extra agent adds cost, latency, and failure modes.

8.8 Challenges of multi-agent systems

Being honest about the hard parts (this is what experts watch for):

Cost & latency: Many agents = many LLM calls = more money and slower.
Coordination overhead: Agents can misunderstand each other or duplicate work.
Error propagation: One agent’s mistake can spread to the whole team.
Looping: Agents can get stuck passing work back and forth.
Debugging difficulty: Harder to trace which agent caused a problem (Module 10 helps here).
Context juggling: Deciding what info each agent sees is genuinely tricky.

The fixes echo earlier modules: clear roles, clean handoffs, step limits, good observability, and a human in the loop for big decisions.

8.9 Common mistakes

Mistake	Result	Fix
Using multi-agent for a simple task	Needless cost/complexity	Start with one agent
Vague roles	Agents overlap or drop work	Give each a sharp, distinct role
Dumping all context to everyone	Confusion, wasted tokens	Clean, minimal handoffs
No coordinator	Chaos, duplicated effort	Use an orchestrator
No step/round limits	Infinite agent ping-pong	Cap total steps

8.10 Check yourself ✅

Give two reasons to use multiple agents instead of one.
Describe the orchestrator–worker pattern in one sentence.
What’s the difference between a pipeline pattern and a debate pattern?
What’s the “golden rule” about when to adopt multi-agent systems?

Answers

Any two of: specialization, focus/less confusion, parallel work, separation of concerns, checks-and-balances (one agent reviews another).
A central orchestrator breaks the goal into sub-tasks, assigns them to worker agents, and combines their results.
A pipeline passes work through agents in a fixed order (assembly line); a debate has agents discuss/challenge each other to reach a better answer.
Start simple with one agent; only add agents when a single agent genuinely can’t handle the task.

8.11 Summary

A multi-agent system = several specialized agents collaborating on a goal.
Benefits: specialization, focus, parallelism, separation of concerns, peer review. Costs: complexity, money, latency, harder debugging.
Agents get roles (orchestrator, worker, critic, planner) and coordinate via patterns: orchestrator–worker, pipeline, debate, hierarchical.
They communicate via messages, shared memory, or handoffs — pass only what’s needed.
Golden rule: start with one agent; go multi-agent only when truly necessary.

Next up: Module 9 — Frameworks & Tools. You understand the concepts; now meet the real software (LangGraph, CrewAI, AutoGen, LlamaIndex…) that helps you build agents. 👉 09_Frameworks_And_Tools.md