When should you use a multi-agent system versus a single agent, and what is the supervisor versus swarm pattern?
Use multiple agents when a task decomposes into distinct specialties or parallel subtasks that exceed one agent's context or reliability; avoid it when a single agent suffices, since multi-agent systems add coordination overhead, latency, cost, and error propagation. A supervisor architecture has an orchestrator routing work to specialized sub-agents, while a swarm lets peer agents hand off control to one another without a central coordinator.
How to think about it
Use a multi-agent system—a system of two or more agents, where an agent is a model-driven loop that can choose tools and next steps—when a task has genuinely separate jobs and that separation buys better context isolation, parallelism, permissions, or reliability. Use a single agent otherwise. A supervisor has a central coordinator assigning and combining work; a swarm has peer agents handing control to one another without a central per-step coordinator.
Why
The interviewer is testing whether you can distinguish complexity from decomposability. A task can be difficult but still be best handled by one agent. Conversely, a task can be straightforward but benefit from several narrowly scoped agents because its work is independent.
A single agent can already call many tools, retrieve documents, maintain state, and follow a plan. Giving it five different personas does not automatically create five independent experts. If the same model sees the same evidence and has the same failure mode, five prompts may simply produce five versions of the same mistake.
I look for three conditions before introducing multiple agents:
- The work divides into distinct subtasks with clear boundaries.
- Those subtasks need different context, tools, permissions, or evaluation criteria.
- The coordination cost is smaller than the gain from specialization or parallel execution.
The boundaries matter. A useful specialist should have a narrow contract: what it receives, what it must return, which tools it may use, and what it is forbidden to do. Without that contract, “multi-agent” often means several expensive conversations passing vague paragraphs to one another.
A multi-agent design also does not make the system truthful by magic. It can improve reliability when one agent checks another with different evidence or a different procedure. It can reduce reliability when every agent depends on a lossy summary, when agents act on stale state, or when their errors are correlated.
A concrete example
Suppose an online retailer sees checkout failures rise from 1 percent to 8 percent immediately after a deployment. The incident commander needs three kinds of investigation:
- payment-gateway responses and timeout patterns
- database connection and lock metrics
- the latest code and infrastructure changes
A single agent could inspect all three. That is attractive if the incident is small, the context fits, and the tools are safe. It is also easy to trace: one conversation, one state, one final decision.
A supervisor design would route the independent investigations to three specialists:
- a payment analyst that can read gateway logs
- a database analyst that can read metrics and query history
- a release analyst that can inspect deployment metadata and diffs
The specialists return findings with evidence, confidence, and unresolved questions. The supervisor then asks for a synthesis and decides whether to recommend rollback, escalation, or more investigation.
Imagine the following illustrative timings:
| Stage | Time |
|---|---|
| Supervisor chooses three specialists | 0.5 seconds |
| Payment investigation | 1.8 seconds |
| Database investigation | 1.2 seconds |
| Release investigation | 1.5 seconds |
| Final synthesis | 1.0 second |
If the three investigations run in parallel, the critical path is about 3.3 seconds: routing, the slowest specialist, and synthesis. If a swarm passes control through all three specialists sequentially, the same work takes about 5.5 seconds before network variance and retries. Those figures are an illustration, not a benchmark, but they show the architectural trade-off.
The supervisor version makes at least five model-level steps in this design: routing, three investigations, and synthesis. It may therefore cost more than one short single-agent answer. It may also cost less than a monolithic agent that repeatedly sends the entire log history, database output, and deployment diff through a growing context. Cost depends on token volume, model choice, tool calls, and how much state is duplicated between agents.
Supervisor versus swarm
A supervisor, also called an orchestrator, is the component that owns the plan and decides which worker runs next. The flow is usually:
- Receive the goal and constraints.
- Select one or more specialists.
- Pass each specialist only the context it needs.
- Collect structured results.
- Retry, re-route, or ask for clarification when necessary.
- Synthesize the result and enforce the final policy.
The supervisor does not have to be an LLM. For known routes, ordinary application code is often safer and cheaper. For example, a payment incident with a database timeout error can deterministically invoke the database specialist. An LLM can handle the ambiguous cases rather than making every routing decision.
A swarm uses decentralized handoff. The currently active agent decides whether to answer, use a tool, or transfer control to another peer. In the checkout example, a triage agent might identify payment timeouts and hand the conversation to a payment agent. That agent might discover that the timeout began after a deployment and hand control to the release agent.
The important difference is ownership. In a supervisor system, the coordinator remains responsible for global state and the final route. In a swarm, the active peer chooses the next owner. A handoff may include the conversation, a summary, selected evidence, and the remaining task. It should not blindly copy every previous message into every context.
| Property | Supervisor | Swarm |
|---|---|---|
| Control | Central routing | Peer handoff |
| Strong fit | Parallel investigations and workflows | Dynamic conversations and ownership transfer |
| Main advantage | Global visibility and predictable control | Local autonomy and fewer central routing decisions |
| Main risk | Bottleneck or single point of failure | Loops, hidden state, and difficult auditing |
“Swarm” is not a perfectly universal term. Some systems use it for broader decentralized or population-based algorithms. In an interview, state the meaning you are using: here, it means peer agents transferring active control.
The senior-level nuance
I would not use multiple agents merely because the prompt is long. Retrieval, context compression, a larger context window, or a deterministic workflow may solve that problem more simply. I would also avoid an agent for a fixed sequence such as “fetch a record, validate a field, write a result.” A normal function or workflow engine is easier to test and cheaper to run.
The textbook answer can also be wrong when the subtasks look separate but depend heavily on one another. If the database analyst needs the payment analyst’s exact request identifier before starting, parallel execution creates rework. A supervisor may still help, but it should use a sequential dependency rather than pretending the jobs are independent.
The common production failure is not an obvious crash. It is a system that appears busy and successful while becoming slower and less useful. You may first see p95 latency grow from 3 seconds to 11 seconds, token usage double, or traces showing a cycle such as triage to payment to triage to payment. The final incident report may contain a confident root cause but no supporting log reference.
Typical causes are unbounded handoffs, oversized shared history, agents returning prose instead of machine-checkable results, and retries that repeat an unsafe side effect. I would set a maximum step and handoff budget, use structured output fields such as status, evidence, confidence, and next_action, make writes idempotent, and give each agent the minimum tool permissions it needs. I would also record every route, tool call, input version, and final decision in a trace.
A swarm can still have global safety controls. “No central coordinator” means no central agent deciding every transition; it does not mean removing authentication, rate limits, termination checks, audit logs, or human approval for a production rollback.
What they’ll ask next
How would you choose between one agent and several in practice?
I would build the smallest single-agent baseline first, then compare it with a multi-agent version on a fixed evaluation set. I would measure end-to-end success, p95 latency, token and tool cost, incorrect handoffs, unsafe actions, and evidence quality. A multi-agent system earns its complexity only if it improves the metric that matters for the product.
Can a system combine supervisor and swarm patterns?
Yes. A supervisor can choose the incident-response team and enforce the global budget, while agents inside that team hand off locally. For example, the supervisor can start payment, database, and release investigations in parallel, then let the payment agent transfer ownership to the release agent when it finds a deployment-specific clue.
What makes a multi-agent system production-ready?
Narrow agent contracts, explicit state ownership, bounded steps, least-privilege tools, structured outputs, idempotent actions, tracing, and a clear fallback or human-approval path. I would test routing and termination separately from the quality of each specialist.
Say this in the interview
“I use multiple agents only when bounded specialties or parallel work justify the coordination cost; a supervisor centrally routes and synthesizes that work, while a swarm lets the active peer hand control to another agent, trading global predictability for local autonomy.”