Multi-Agent Orchestration

Multi-agent systems are the pattern interviewers watch candidates reach for too early. Ask "design an agent that researches a topic and writes a report," and a candidate who has read a few blog posts will sketch a supervisor spawning five research agents and a synthesis agent before establishing whether the task needs to be split at all. That instinct isn't wrong so much as premature — it skips the question every senior AI engineer asks first: does this task actually decompose into independent pieces, and is the coordination overhead and cost multiplication of running N agents instead of one worth paying for this task? A single well-scoped agent working sequentially, with a bigger context window or a stronger model, solves most tasks that look "multi-agent-shaped" at first glance, for a fraction of the token cost and with a debugging story that doesn't require reconstructing which of five agents introduced the error.

This subject is deliberately vendor-neutral: it covers the patterns — supervisor/worker decomposition, handoffs, shared state versus isolated workers, parallel fan-out and synthesis, and the cost arithmetic that should govern the decision — the way you'd be expected to reason about them in a system-design interview, independent of any specific product's API. Where it helps to see the abstract pattern made concrete, it points at mcp-and-subagents, which walks through the same ideas as they're actually implemented in Claude Code (fresh vs. forked subagents, parallel fan-out, git-worktree isolation for concurrent writers), and at plan-and-loop-modes, which covers the pipeline-vs-barrier synchronization question and adversarial verification in more mechanical depth than this subject repeats. Two siblings worth knowing exist alongside this one: agent-architectures-and-the-agentic-loop, which is the single-agent loop (plan → act → observe → reflect) that multi-agent orchestration scales out to N copies of, and mcp-and-tool-integration-protocols, which covers how an individual agent reaches external systems — orthogonal to, and composable with, everything here.

What an interviewer is actually testing when they ask a multi-agent design question is whether you can justify the added coordination cost, not whether you can describe the pattern. Every extra agent is extra token spend, extra latency to spin up, extra surface area for a context-passing error, and one more place a wrong answer could have originated. The pattern earns its complexity only when the task's structure demands it — genuine independence between sub-problems, or a genuine need for multiple independent "perspectives" on the same finding. This subject is built around making that judgment call defensible with numbers, not just describing the architecture diagram.