Multi-agent topologies — when one agent is not enough

Why this matters

A single agent fails when the task crosses domains (research + write + review), needs different tools at different stages, or hits cost/latency walls. Multi-agent systems split responsibility — and the trick is picking the right topology for the problem. Senior interviews always probe this.

Learning objectives

1. Recognise the 5 standard multi-agent topologies.
2. Pick the right one for a given problem.
3. Anticipate the failure modes of each.
4. Decide between LangGraph, CrewAI, and OpenAI Agents SDK as the implementation tool.

1. The 5 topologies you must know

A. Single-agent + tools (the baseline)

One agent, many tools. Default. Use until proven insufficient.

B. Sequential / pipeline

A → B → C. Each agent has one specialised job, output of one is input to the next.

• Wins: clarity, simple to debug.
• Loses: rigid, no feedback loops.
• Use for: ETL-style flows, research → outline → draft → polish.

C. Supervisor / hierarchical

A manager agent delegates to specialist workers and validates their output.

        [Supervisor]
        /     |     \
     [A]    [B]    [C]

• Wins: dynamic routing, supervisor can re-delegate or escalate.
• Loses: more LLM calls; risk of supervisor becoming a bottleneck.
• Use for: customer support triage, project execution.

D. Swarm / mesh / handoff

Agents hand off control among themselves based on the current task. No fixed hierarchy.

• Wins: flexible; mirrors how human teams pass the baton.
• Loses: harder to debug; loops easy.
• Use for: fluid problem-solving where the next-best agent depends on context.

E. Network / debate

Multiple agents discuss to reach consensus or critique each other.

• Wins: higher accuracy on hard tasks, exposes blind spots.
• Loses: very expensive, slow.
• Use for: safety-critical reasoning, scientific argumentation.

2. How to pick

Rule of thumb: start with single-agent. Add a supervisor only when you have measured that one model + many tools cannot keep accuracy above your threshold.

3. Anti-patterns (what to not do)

• One agent per tool. You will create 12 agents and orchestrate hell. Tools belong inside an agent.
• Two agents that share state directly. Communicate through a structured message protocol or shared graph state, never raw memory.
• Free-form prompts between agents. Define a typed message schema (Pydantic) for inter-agent messages.
• Unbounded delegation. Cap depth/steps; otherwise supervisors will fan out forever.
• Skipping evals before adding agents. Always measure single-agent baseline first.

4. Tool choice cheat-sheet

CrewAI is great when business stakeholders want to read your code (roles, goals, backstories — very narrative). LangGraph is what you reach for when you need every escape hatch.

5. Inter-agent message schemas

Define a typed contract:

from pydantic import BaseModel, Field
from typing import Literal

class AgentMessage(BaseModel):
    sender: str
    receiver: str
    intent: Literal["request", "response", "handoff", "ack"]
    task: str
    context: dict = Field(default_factory=dict)
    citations: list[str] = []
    confidence: float = 1.0
    requires_approval: bool = False

Every inter-agent message uses this schema. Logs become greppable. Errors are obvious. Debugging becomes a graph problem, not a prose problem.

6. Mental model picture

Prompt → [Single agent] → Answer        (start here)
                ↓ (insufficient)
Prompt → [A] → [B] → [C] → Answer       (pipeline)
                ↓ (need routing)
       [Supervisor]
       /    |    \                       (hierarchical)
      A     B     C
                ↓ (dynamic)
   [A ⇄ B ⇄ C]                            (swarm/handoff)
                ↓ (need consensus)
   [A] ⇆ [B] ⇆ [C] → arbiter → Answer    (debate)

The path of complexity is roughly top-to-bottom. Stop at the topology that meets your accuracy/cost target.

Hands-on lab (3 hours)

For your own portfolio domain (e.g., legal contracts, e-commerce, healthcare), draft a system design doc that:

• Picks one topology and justifies why with concrete failure modes that single-agent would have.
• Writes the typed AgentMessage schema.
• Lists every agent's role, tools, and entry/exit conditions.
• Adds an evaluation plan: golden tasks, success metrics, cost ceiling.

This is the kind of document a Staff AI Engineer would be expected to write before any code exists. Worth more than a thousand lines of code in interviews.

Self-check

1. When does a swarm topology beat a supervisor?
2. What is the anti-pattern of "one agent per tool"?
3. Why is a typed AgentMessage schema important?
4. Which topology is the most expensive and why?
5. How do you measure that the move from single-agent to multi-agent is justified?

References

• Anthropic: Building effective agents
• LangGraph multi-agent patterns
• CrewAI processes
• OpenAI Agents SDK
• Microsoft AutoGen multi-agent