Multi-Agent Systems: Teams of Specialists

A single agent can handle many tasks. But some workflows are too complex, too broad, or too specialized for one agent to do well. That’s where multi-agent systems come in.

🔄 Quick Recall: In the previous lesson, you learned how agents use tools through function calling, MCP, and structured outputs. Multi-agent systems take this further — agents themselves become tools that other agents can use.

When Do You Need Multiple Agents?

Not every task needs a team. Here’s the decision framework:

Rule of thumb: Start with one agent. Split into multiple only when the single agent demonstrably struggles.

Orchestration Pattern 1: Supervisor

A central agent delegates tasks to specialized worker agents.

                    ┌─────────────┐
                    │  Supervisor  │
                    │  (Router)    │
                    └──────┬──────┘
                   ┌───────┼───────┐
                   ▼       ▼       ▼
            ┌──────────┐ ┌─────┐ ┌──────────┐
            │ Research  │ │Write│ │  Review   │
            │  Agent    │ │Agent│ │  Agent    │
            └──────────┘ └─────┘ └──────────┘

How it works:

1. User sends request to the Supervisor
2. Supervisor analyzes the request and decides which worker(s) to engage
3. Workers execute their specialized tasks
4. Results flow back to the Supervisor, which synthesizes the final output

Example: Content creation pipeline

• User: “Write a blog post about quantum computing for beginners”
• Supervisor → Research Agent: “Find 5 authoritative sources on quantum computing basics”
• Supervisor → Write Agent: “Write a 1500-word blog post using these sources” (passes research results)
• Supervisor → Review Agent: “Check for accuracy, readability, and SEO” (passes draft)
• Supervisor: Delivers the final reviewed post

✅ Quick Check: The Supervisor pattern requires the supervisor to understand the capabilities of every worker agent. What happens if you add a new “Translation Agent” but don’t update the supervisor’s knowledge? (Answer: The supervisor will never delegate translation tasks to the new agent because it doesn’t know it exists. Multi-agent systems require the orchestrator to have up-to-date knowledge of all available agents — their capabilities, when to use them, and what inputs/outputs they expect. Adding an agent without updating the orchestrator is like hiring an employee without telling the manager.)

Orchestration Pattern 2: Pipeline

Agents process work in a fixed sequence, like an assembly line.

Input → [Agent A] → [Agent B] → [Agent C] → Output
         Extract      Analyze     Format

How it works:

1. Each agent has one job
2. Agent A’s output becomes Agent B’s input
3. The sequence is predetermined — no routing decisions needed

Example: Invoice processing

Invoice PDF → [Extract Agent] → structured data
           → [Validate Agent] → validated data + flags
           → [Accounting Agent] → journal entries
           → [Notify Agent] → confirmation email

When to use: Tasks with a clear, repeatable sequence where each step transforms the data for the next step.

Orchestration Pattern 3: Peer-to-Peer

Agents communicate directly with each other without a central coordinator.

┌──────────┐     ┌──────────┐
│ Agent A   │◄───►│ Agent B   │
└─────┬────┘     └────┬─────┘
      │               │
      └───────┬───────┘
              ▼
        ┌──────────┐
        │ Agent C   │
        └──────────┘

How it works:

1. Agents decide independently who to communicate with
2. No central authority — agents coordinate through direct messages
3. Any agent can initiate a conversation with any other agent

Example: Collaborative debugging

• Code Agent: “I found a performance issue in the query on line 47”
• Database Agent: “That query is missing an index. Here’s the fix.”
• Code Agent: “Applied the fix. Testing Agent, can you verify?”
• Testing Agent: “Performance improved from 3.2s to 0.4s. Fix confirmed.”

Warning: Peer-to-peer is the hardest to debug and the most prone to infinite loops. Use it only when tasks genuinely require ad-hoc collaboration.

The Handoff Pattern

In many frameworks (OpenAI Agents SDK, LangGraph), one agent can “hand off” to another — transferring the conversation and context:

User: "I need to return a product and also ask about
       a new product."

Triage Agent: This involves both returns and sales.
  → Handoff to Returns Agent (with context)

Returns Agent: "I've processed your return for order #4521.
  Shipping label sent to your email."
  → Handoff to Sales Agent (with context)

Sales Agent: "Great! What product are you interested in?"

The handoff transfers the full conversation context so the receiving agent doesn’t start from scratch.

✅ Quick Check: In a pipeline system, Agent B receives malformed data from Agent A and crashes. The error propagates — Agents C and D never run, and the user gets no result. How do you prevent this? (Answer: Add validation at each pipeline stage. Agent B should validate its input before processing: check data types, required fields, and value ranges. If validation fails, Agent B returns a structured error to the orchestrator instead of crashing. The orchestrator can then retry Agent A, use a fallback, or report the specific failure to the user. Input validation at every boundary is critical in multi-agent pipelines.)

Common Multi-Agent Failure Modes

Gartner found 41-87% failure rates in multi-agent systems. Here’s what goes wrong:

1. Infinite Delegation Loops

Agent A delegates to Agent B, which delegates back to Agent A. Fix: Maximum delegation depth and loop detection.

2. Context Loss at Handoffs

Agent A has critical context that doesn’t transfer to Agent B. Fix: Structured handoff messages with explicit context fields.

3. Conflicting Actions

Two agents modify the same resource simultaneously. Fix: Resource locking or sequential access patterns.

4. Cascading Failures

One agent’s failure triggers failures in all downstream agents. Fix: Circuit breakers and fallback paths.

Framework Comparison

Practice Exercise

1. Pick a workflow from your work that involves 3+ distinct tasks
2. Decide: supervisor, pipeline, or peer-to-peer? Why?
3. Define 3 specialist agents: their role, tools, and what they hand off to the next agent
4. Identify the most likely failure mode and design a prevention mechanism

Key Takeaways

• Start with a single agent — only split into multiple agents when one demonstrably can’t handle the task
• Supervisor pattern: central coordinator delegates to specialists — most common and easiest to debug
• Pipeline pattern: fixed sequence of processing steps — best for repeatable transformation workflows
• Peer-to-peer: agents coordinate directly — most flexible but hardest to debug and most prone to failures
• Handoffs transfer conversation context between agents, maintaining continuity
• Multi-agent failure rates reach 41-87% without proper orchestration — validate at every boundary

Up Next

In the next lesson, you’ll learn how to give agents memory — both short-term conversation context and long-term persistent storage that survives across sessions.