Describe the coordination overhead that a multi-agent architecture introduces compared to a single agent system. Under what condition is this overhead worth paying?
Multi-agent systems add routing, shared-state synchronisation, and inter-agent messaging. That overhead only pays off when sub-tasks are genuinely parallel or need true specialists.
Imagine one person cooking a whole dinner. They know what is in every pot, they never have to explain anything to anyone, and they just work down their list. Now imagine a team of cooks. Someone has to decide who makes what. They have to share the one cutting board without bumping into each other. They have to shout updates so nobody salts the soup twice. All that talking and waiting is real work that the solo cook never did. The team is faster only if there are genuinely separate dishes that can be made at the same time, or if one cook is a dessert specialist who is simply better at desserts. If it is just one simple dish, the solo cook wins.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
A single-agent system is one LLM running in one loop, holding the full task in one context, and making every decision itself. A multi-agent system splits that work across several agents, typically with an orchestrator that routes sub-tasks to specialists. The interview question is not whether multi-agent is fancier. It is what concrete coordination overhead the split introduces, and when that overhead actually pays for itself.
The sharpest framing is this: the moment you split one agent loop into many, you have built a distributed system. Everything that makes distributed systems hard (routing, shared state, message delivery, partial failure) arrives with it. A single agent avoids all of it by construction, because there is exactly one process, one context, and one source of truth.
The rest of this answer walks the three concrete overheads, then covers the two design choices that interviewers probe most: how agents are wired together (supervisor versus peers) and how they communicate (shared scratchpad versus explicit messages). It closes with the one genuine upside, context isolation, and the precise conditions under which the whole bargain is worth striking. The through-line is simple: multi-agent is a cost you pay for parallelism or specialism, never a free capability upgrade.
Overhead one: routing
In a single-agent system there is nothing to route. One agent owns the whole task, picks its own tools, and works the problem end to end. In a multi-agent system, something must decide which agent handles which sub-task. That something is usually an orchestrator or supervisor.
Routing is real work with real cost. The orchestrator typically makes its own LLM call to classify the incoming sub-task and dispatch it to the right specialist. That is an extra model invocation per routing decision, which adds latency and tokens before any useful work happens. The orchestrator must also decompose the task into work units in the first place, decide how many sub-agents to spawn, and package the right slice of context for each one. None of these sub-steps exist when a single agent simply continues its own loop.
Routing also introduces a brand-new failure mode: misrouting. Send a code-review sub-task to the research agent and you get a confidently wrong result with no exception raised. Because the wrong specialist still produces fluent output, misrouting tends to surface as a subtly wrong final answer rather than a crash, which makes it expensive to catch. A single agent simply cannot misroute, because there is no routing decision to get wrong. It also cannot under-provision context to itself, since it always holds the full task. Routing, in short, converts a non-decision into a recurring decision that costs tokens and can silently fail.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Anthropic's multi-agent research system uses a lead Claude Opus 4.7 agent that spawns parallel sub-agents to search independent sources, then synthesises their reports: a textbook parallel-decomposition fit.
- OpenAI's Swarm and the Agents SDK model handoffs as explicit actions, making routing and inter-agent message passing first-class concepts the developer must wire up.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you decide between a supervisor orchestrator and a peer-to-peer handoff topology for a multi-agent system?
Compare centralised control against decentralised handoffs. A supervisor centralises routing and state, which is easier to debug and audit but is a bottleneck. Peer handoffs scale better but make global termination and consistency harder to reason about.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Reaching for multi-agent because it sounds more capable. Most tasks are sequential and tightly coupled, where a single agent with the right tools is simpler, cheaper, and easier to debug.
60 second bullets to scan on the way to the call.
Name the three coordination overheads a multi-agent system adds.
Explain why a single agent avoids all three by construction.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.