TL;DR: Default to a single agent or a code-orchestrated workflow; reach for multiple agents only when the task genuinely benefits from specialization (distinct skills, tools, contexts) or parallel decomposition. Common patterns: a supervisor that delegates to specialist sub-agents, or sequential handoff between roles. The pitfalls are real: coordination overhead, compounding errors, context-sharing, latency and cost multiplication, harder evaluation. More agents is usually more failure surface, not more capability.
How to approach it. Push back on the hype: most "multi-agent" needs are met by one well-designed agent or a deterministic workflow. State the conditions that actually justify multiple agents, then the orchestration patterns, then the pitfalls, because coordination is where these systems break.
A strong answer. When it is justified. Multiple agents earn their cost in two cases. First, specialization: subtasks need genuinely different tools, system prompts, or context windows (a coding agent vs a research agent vs a reviewer), so separating them keeps each focused and its context clean. Second, parallel decomposition: independent subtasks run concurrently (research several sub-questions at once, then synthesize). If neither holds, a single agent with the right tools, or a code-orchestrated workflow, is simpler, cheaper, and easier to debug. Set the bar high.
Orchestration patterns:
- Supervisor / orchestrator-worker. A coordinating agent (or deterministic controller) decomposes the task, delegates subtasks to specialist sub-agents, and synthesizes their outputs. The orchestrator owns the plan; workers own focused subtasks. Best fit for specialization and parallelism.
- Sequential handoff (pipeline). Agents pass work down a chain, each transforming or adding (drafter, critic, refiner). Good when stages are distinct and ordered.
- Debate / reviewer. One agent produces, another critiques or verifies; useful for quality but doubles cost.
Prefer code-orchestrated control flow (you decide the structure, the model fills steps) over fully autonomous agents deciding to spawn each other, which is hard to control and debug.
Pitfalls (where these systems fail):
- Compounding errors. Each agent's mistakes feed the next; across a chain, error rates multiply. Validate between steps.
- Coordination and context. Sharing the right state without flooding each agent with irrelevant context is hard: too little and they lose coherence, too much and they get confused and expensive.
- Latency and cost multiplication. Every agent is model calls plus tool round-trips; a multi-agent system can run many times slower and pricier than a single call. Parallelize independent work and price the SLO.
- Evaluation. You must evaluate the whole system's trajectory and outcome, not just individual agents; attributing failure across agents is hard.
- Loops and runaway behavior. Agents delegating to agents need hard iteration and budget caps.
The defensible stance: start with the simplest thing (single agent or workflow), add agents only for real specialization or parallelism, orchestrate in code, validate between steps, and bound the whole system.
Key takeaways.
- Two conditions justify multi-agent: distinct specialization or genuinely parallel subtasks. Otherwise use one agent.
- Orchestrate in code with a supervisor; avoid agents autonomously spawning agents.
- Validate every handoff: error rates multiply down a chain.
- Cap iterations and budget, and evaluate end-to-end trajectory, not per-agent metrics.
What interviewers probe next.
- "Single agent with tools vs multi-agent?" If one agent with the right tools can do it, that is simpler and more reliable; multi-agent is for distinct specializations or parallel subtasks.
- "How do you stop errors compounding across agents?" Validate each handoff, keep humans or gates on critical steps, and have the orchestrator verify sub-agent outputs rather than trusting them.
- "Context sharing?" Pass only the relevant slice to each agent (summaries, scoped state); shared scratchpads help but watch context bloat.
- "How do you evaluate it?" End-to-end task success plus trajectory scoring; per-agent metrics alone miss coordination failures.
Common mistakes.
- Reaching for multi-agent because it is fashionable, when one agent or a workflow suffices.
- Fully autonomous agents spawning agents with no code-level control, making it undebuggable.
- No validation between agents, so errors compound silently.
- No iteration or budget caps, so the system loops or runs away on cost.