The Multi-Agent Pattern: Supervisor and Workers

Once you have built one agent, the temptation to reach for multi-agent systems is strong. This module covers when that reach is justified and how to build multi-agent systems that actually work.

What a Multi-Agent System Is

A multi-agent system is a collection of specialised agents that coordinate to accomplish tasks no single agent could handle well. Each agent has its own tools, its own prompt and often its own model tier.

The two most common architectures:

Supervisor and workers. One agent (the supervisor) reads the incoming request, decides which specialist should handle it and dispatches the work. The specialists have narrow, deep expertise. When a specialist is done, control returns to the supervisor which either dispatches to another specialist or produces a final response.

Peer-to-peer. Agents talk to each other directly, without a central supervisor. Each agent knows about the others and can hand off when it recognises the task is not for it.

Supervisor-worker is easier to reason about and debug. Peer-to-peer is more flexible but more likely to produce emergent chaos. Start with supervisor-worker.

Why Not Just One Big Agent

A single agent with 50 tools works badly. Reasons:

• Every tool description is in every request. Fifty tools means thousands of tokens of tool definitions consumed on every LLM call
• Claude has to reason about which of 50 tools is right. More tools means more chances to pick wrong
• Adding a new capability means editing one giant prompt and one giant tool list; hard to test in isolation
• Different capabilities need different context (billing needs financial history; support needs ticket history) and shovelling everything into one context is wasteful

Splitting into specialists with 5 to 10 tools each solves all four. Each specialist is easier to prompt, easier to test and cheaper to run.

When Multi-Agent Is Overkill

Multi-agent adds real complexity. Coordination bugs, state passing bugs, harder debugging, harder observability. Do not reach for it unless the problem justifies it.

Signals that a task is genuinely multi-agent:

• The tools naturally cluster into 2 to 5 groups with little overlap
• Different tasks need different reasoning depths or different model tiers
• Some tasks need context or permissions that others should not have
• The workflow has stages (research, then write, then review) that map to different specialisations

Signals it is not:

• The tools all touch the same domain
• Everything can be done with a single well-prompted agent
• You are drawn to multi-agent because it feels sophisticated, not because the problem needs it

Complexity is a real cost. Only pay it when the benefit is clear.

A Concrete Example

A support system with three specialists:

• Billing specialist. Tools: lookup_invoice, list_payments, issue_refund. Model: Sonnet.
• Shipping specialist. Tools: lookup_order, track_shipment, request_reship. Model: Sonnet.
• Technical specialist. Tools: lookup_ticket, search_kb, escalate_engineering. Model: Sonnet.

Plus a supervisor that classifies the incoming message and routes to the right specialist. The supervisor uses Haiku (cheaper, smaller) because classification is a simple task.

The result: three focused agents, each with tight prompts and specific tools. The supervisor keeps everything coordinated. Total complexity is higher than a single agent, but each piece is much easier to reason about.

Cost and Latency Implications

Multi-agent runs are more expensive and slower than single-agent runs. Every handoff between agents is another LLM call. A three-stage workflow (supervisor plus two specialists) is at least three round trips, likely more.

Mitigations:

• Use cheap models for supervisor and routing steps
• Cache stable prefixes aggressively
• Parallelise specialists when the work is independent (research two topics at once, for example)

Do not use multi-agent as a way to distribute a single conceptual task across many LLM calls just because you can. That is a way to pay more for worse output.

Key Takeaway

Multi-agent systems are the right tool when work genuinely splits into specialisations that share little tooling or context. Supervisor-worker is the sensible default. Start there, add complexity only when you can point to a specific reason. Every extra agent is an extra round trip and an extra thing that can go wrong.