AI Learning Hub
advanced

Multi-agent systems

One LLM with tools is an agent. Multiple LLMs cooperating is a multi-agent system. The patterns are few; the failure modes deserve respect.

What multi-agent actually does

A multi-agent system splits a task across several LLM calls, each playing a specific role — researcher, coder, reviewer, synthesiser — instead of asking a single agent to do everything. One agent (the orchestrator) breaks the work down, the specialists do their parts, and the orchestrator combines the results.

The honest payoff is specialisation, parallelism, and isolation: the orchestrator only sees a clean summary of each worker's output, not the messy details of how they got there. The dishonest version — "more agents = more capable" — is usually wrong. A single thoughtful agent often beats a sprawling multi-agent system, and costs less to run.

That's the whole concept. Below: the patterns that work (orchestrator + workers, pipelines, debate), where they fail, and the contract between agents that keeps it from descending into "agent soup."

When you'd reach for it

Multi-agent earns its keep when the sub-tasks are genuinely independent:

  • Research with parallel sub-questions — the lead asks 5 questions, 5 workers run in parallel, the lead synthesises.
  • Code review pipelines — separate security reviewer, style reviewer, correctness reviewer.
  • Routing across specialists — a billing agent vs a tech-support agent vs an escalation agent.
  • Stage pipelines — plan → research → draft → critique → revise.

You wouldn't reach for multi-agent when sub-tasks are tightly coupled, when one agent with good tools can do it, or when you don't yet have tracing — debugging multi-agent systems without observability is misery.

How it's actually built

Why multi-agent at all?

Three honest reasons: specialisation (different sub-tasks want different prompts, models, or tools), context isolation (the lead gets a summary of each worker's work, not the full transcript), and parallelism (independent sub-tasks run simultaneously).

The dishonest reason: "it sounds cool." Multi-agent often gets worse results than a single thoughtful agent — use it when sub-tasks are genuinely independent. If a worker needs the parent's full conversation history to do its job, you didn't need a worker; you needed a tool call.

The dominant patterns

Orchestrator + workers — most common production pattern:

The orchestrator decomposes, dispatches in parallel, and synthesises — workers never talk to each other.

Orchestrator decomposes → dispatches → synthesises. Workers don't talk to each other.

PipelinePlan → Research → Draft → Critique → Revise → Final. Each stage operates on the previous stage's output. Predictable, debuggable.

Debate — proposer + critic, with a moderator synthesising. Robustness for subjective tasks; watch the cost.

Routing — coordinator decides which specialist handles a request. "Billing vs. technical question" splits.

Where it bites in real life

Under the hood (optional)

A real-but-minimal orchestrator-workers loop in ~15 lines: decompose the goal, dispatch workers in parallel, collect findings, critique, optionally fill gaps, write the final brief. Skip if you don't code — the contract between agents (typed inputs and outputs) is what matters more than the code shape.

Show example code (Python, ~15 lines)click to expand
async def orchestrate(goal: str) -> str:
    plan = await llm("Decompose into 3-6 sub-tasks", goal=goal, schema=PLAN_SCHEMA)
 
    # Parallel worker dispatch
    findings = await asyncio.gather(*[
        worker_research(task) for task in plan["tasks"]
    ])
 
    critique = await llm("Critique these findings", findings=findings, schema=CRITIQUE_SCHEMA)
    if not critique["ok"]:
        gaps = await asyncio.gather(*[worker_research(q) for q in critique["missing"]])
        findings = findings + gaps
 
    return await llm("Write the final brief", findings=findings)

The orchestrator is a normal Python function; workers are LLM calls with their own prompts and tools. No "framework" required.

Check your understanding

  1. 1. Main reason to split work across multiple agents instead of one big agent?
  2. 2. In orchestrator + workers, the orchestrator typically:
  3. 3. Two workers produce contradictory outputs. The right architectural fix:

Found this useful? Share it with someone learning AI.

Further reading

Related lessons in this track