Multi-Agent System Design Interview (2026 Playbook)

The multi-agent system design interview is now its own round in 2026 agentic-AI hiring loops. You get a vague task, a whiteboard, and 45 minutes to justify a topology, define shared state, handle failures, and explain how you'd evaluate the thing. Most candidates draw boxes and arrows and stop there. The ones who pass treat it like a real system: they justify why multiple agents are needed at all, name the orchestration pattern, and put numbers on cost and eval. This guide gives you the patterns, the questions, and the rubric the interviewer is grading against.

There are two different rounds and people confuse them. The fundamentals screen asks "what is a ReAct loop, what is tool use, define reflection." That is covered in agentic AI interview questions. The design round is different. You get a problem like "design a system that researches a company and writes a diligence memo" and you architect a multi-agent system out loud.

Who asks it: AI infra startups, frontier labs, and big-tech AI platform teams. Reported base comp for these roles tends to run in the low-to-mid six figures, depending on city and stage, with the top bands at frontier labs and well-funded infra companies (treat any specific figure as an estimate and verify against live levels data before you negotiate). The bar moved up this year because everyone has now shipped an agent and the failure modes are public knowledge.

The interviewer grades five things, and they map cleanly to the sections below:

Miss any one of these and you read as someone who has read blog posts but never run an agent in production. Hit all five with concrete tradeoffs and you sound senior. The rest of this guide is one section per signal, each anchored to a question you'll actually get asked.

The first move in the round is not drawing. It is justifying that you need more than one agent at all. Strong candidates open with a sentence like "before I add agents, here's what a single agent costs me and what it buys me." That alone separates you from the field.

Multi-agent is not free. The token overhead is real: splitting work across agents is reported to run on the order of 4x to 15x the tokens of a single agent on the same task, because each agent re-establishes context, passes messages, and often re-reads shared state. Treat that as an order-of-magnitude estimate, not a measured constant — the right move in the room is to name that the multiplier exists and that you would instrument it, not to defend an exact figure. Latency goes up when steps are serialized. Debugging gets harder because a failure can hide three agents deep. You are buying that complexity to gain something specific.

A single agent usually wins when:

Multiple agents start to pay when:

The decision checklist to say out loud: parallelism, context size, tool-scope separation, and model heterogeneity. If none of those apply, say so and stay single-agent — that is a strong answer, not a cop-out. Reference this tradeoff mentally but make the call live.

Worked example — how the call sounds in the room. Prompt: "Design a system that summarizes a 200-page contract and flags risky clauses." A weak candidate splits it into five agents on instinct. The strong answer runs the checklist out loud: "One contract, one skill — read and flag — so parallelism buys me nothing; the document is large but chunk-and-map fits one agent with a sliding window; tool scope is just read plus a clause classifier, no separation needed; and one strong model handles both. So I'd start single-agent with a map-reduce pass, and I'd only split out a separate 'legal-citation lookup' agent if clause flagging needs an external case-law tool with its own scoped credentials." That last sentence is the senior tell: you stayed single-agent on the checklist, but you named the exact future trigger that would justify a second agent. In practice, the single most common failure I see candidates make here is reaching for multi-agent because the prompt sounds big, when the prompt is actually one skill applied repeatedly — and that instinct is precisely what the topology-justification signal is built to catch.

This is the core of the round. You need to be able to sketch each pattern in ten seconds and name the signal it sends. Interviewers are not looking for the "right" pattern — they are looking for whether you map task shape to topology and own the tradeoff.

A central coordinator decomposes the task, assigns subtasks to worker agents, and aggregates results. Workers don't talk to each other; everything routes through the hub. This is the default and the most common production pattern because it is easy to reason about and easy to observe — every decision flows through one place.

Draw it when the task decomposes cleanly into independent subtasks that one orchestrator can fan out and collect. The risk to name: the coordinator is a bottleneck and a single point of failure. Its context can balloon as it holds the state of every worker, and it serializes decisions. Mitigate by keeping the coordinator's prompt lean, letting workers return summaries instead of raw dumps, and budgeting the coordinator separately. Grading signal: do you recognize the bottleneck before the interviewer points at it?

A tree. A top coordinator delegates to mid-level managers, each of which owns a cluster of workers. This adds a layer of local state — a manager aggregates its subtree before reporting up, so the root never sees raw worker output.

Depth pays off when the task is genuinely nested (a research org chart: regions, then countries, then companies) and when a flat hub would drown in context. The tradeoff: more layers mean more latency and more places for an error to get swallowed silently. The interesting design decision here is local vs global state — what does a manager summarize before it reports up, and what does the root actually need? Grading signal: can you justify the extra layer instead of adding it reflexively?

Agents don't get assigned work by a coordinator. They watch a shared workspace (the "blackboard"), claim tasks they can do, post results back, and other agents pick up from there. Control is decentralized and emergent. This pattern shines on problems where the decomposition isn't known upfront and specialists opportunistically contribute.

The evidence to cite, carefully: blackboard-style coordination has been reported to improve task success over rigid pipelines on open-ended problems (published gains vary widely by benchmark, so quote it as a reported range rather than a fixed number), because agents self-organize around whatever state is currently available instead of waiting on a fixed plan. The cost: you need careful claim/lock semantics so two agents don't grab the same task, and the shared state becomes the consistency problem you must solve (next section). Grading signal: do you reach for blackboard on the right problem — open-ended, decomposition-unknown — instead of forcing it everywhere?

Mesh lets every agent talk to every other agent directly. It's flexible but the communication cost is O(N²) in the number of agents, and it's a nightmare to observe and debug. Reserve it for small N (3-4 agents) where genuine negotiation between peers is the point — debate, adversarial review, consensus.

Pipeline / sequential chains agents in a fixed order: agent A's output is agent B's input, like an assembly line (extract, then transform, then summarize, then format). It's the simplest to reason about and the cheapest to observe. Use it when the task has a genuine fixed order of stages. The downside is no parallelism and a stall anywhere stalls everything.

Memorize this table. In the round you point at a row and say "the task looks like this, so I'd start here, and here's the failure mode I'm accepting."

Once you've drawn the topology the interviewer often asks "how do these agents actually talk?" Two models: direct calls (the coordinator invokes a worker like a function and gets a return value) and a message bus (agents publish and subscribe to a shared channel). Direct calls are simpler and the default for hub-and-spoke. A message bus fits blackboard and mesh where you don't know upfront who needs what.

The senior move is talking about structured handoffs. An agent should hand off a typed, schema-validated payload — not a free-text blob the next agent has to re-parse and possibly misread. Define the handoff contract: what fields, what's required, what a worker returns on partial success.

The cost trap to flag: re-retrieval overhead. If every agent re-fetches and re-embeds the same documents because context wasn't passed cleanly, you pay the multi-agent token tax twice. Decide deliberately between context-passing (each agent gets exactly the slice it needs in its prompt) and shared state (agents read from a common store). Passing context keeps agents independent but bloats prompts; shared state is leaner but introduces consistency questions. Naming that tradeoff out loud is the point.

This is where candidates either sound like they've built systems or like they've read about them. Memory in a multi-agent system comes in three kinds, and you should distinguish them:

The framework to lead with is the latency-consistency-cost triangle. You can't max all three. Strong consistency across agents (everyone sees the same state immediately) costs latency and coordination overhead. Low latency with eventual consistency is cheaper and faster but agents can act on stale state and step on each other. Cheap, in-memory, no durability is fastest but loses everything on a crash. Every shared-state decision picks a corner of that triangle, and saying which corner you're picking, and why, is the gradable answer.

Then talk durability. Checkpointing — periodically serializing the full system state so a crashed run can resume instead of restarting — is what makes a long multi-agent task recoverable. Frameworks like LangGraph build this in with persistent checkpointers; you don't need to name a framework, but knowing serializable recoverable state exists is the signal. For consistency across agents writing the same blackboard, you need claim/lock semantics or a single writer per key, otherwise two agents overwrite each other. Grading signal: do you treat shared state as a real distributed-systems problem, not a global variable?

Tools are how agents touch the world, and routing them is a design decision. The question: given a task step, how does the system pick the right tool and the right agent at runtime? Options to mention — a router model that classifies intent and dispatches, a coordinator that owns the routing table, or letting each agent's own model choose from its scoped tool list.

Per-agent tool scoping is the access-control answer. A research worker gets read-only search and fetch. A worker that writes to a database gets exactly that write tool and nothing else. You scope so a hijacked or hallucinating worker has a small blast radius — it can't spend money or delete data unless it was explicitly handed that capability. Tie this to the single-agent-vs-multi point: tool-scope separation is one of the real reasons to split into multiple agents.

Two more things that read as senior: schema design for tools (tight JSON schemas with required fields and enums so the model can't emit garbage, plus clear error returns) and model routing — a cheap fast model for classification and routing, a strong model for synthesis. Anthropic's tool-use docs and OpenAI's platform docs both formalize the function-calling mechanic; the design problem is which tools each agent gets and how you validate the boundary. Put guardrails at that boundary — validate inputs before a tool runs and outputs before they propagate.

This section is where most candidates go thin and where you can pull ahead. A multi-agent system has more failure surface than a single agent: any agent, any tool call, any handoff can fail, and failures compound. Walk through the layers:

Grading signal: do you design for failure as a first-class concern, with specific guards and numbers, rather than assuming the happy path?

Eval is the section that fails the most candidates, because it's the part nobody practices and the part interviewers weight heavily. Generic listicles give it two lines. Here's the gradable version.

Golden trajectories. A golden trajectory is a recorded reference run — the ideal sequence of agent decisions and tool calls for a known input. You evaluate a new run by comparing its trajectory against the golden one, not just its final answer. This catches an agent that got the right answer by luck through a broken path.

Step-level vs end-to-end accuracy. End-to-end measures whether the final output is correct. Step-level measures whether each intermediate decision (right tool, right handoff, right sub-answer) was correct. You need both — end-to-end tells you if the system works, step-level tells you where it breaks. In a multi-agent system, a 90% per-step accuracy across 8 steps compounds to about 43% end-to-end. Saying that math out loud is a senior signal.

LLM-as-judge pitfalls. Using a model to grade outputs scales, but it has known failure modes: position bias, verbosity bias, and self-preference. The fix is a judge-of-judges — validate your judge against human labels on a sample, calibrate, and don't trust an unvalidated judge. Flag that the judge itself needs eval.

Cost-per-task and latency as eval metrics. Correctness isn't the only axis. A correct system that costs $4 and 90 seconds per task may be unshippable. Bake cost-per-task budgets and latency targets into the eval suite as first-class pass/fail criteria, not afterthoughts.

For the broader eval question bank and how this shows up across agentic rounds, see agentic AI interview questions and the data-retrieval angle in RAG interview questions. In the design round, the move is to volunteer the eval plan before you're asked — most candidates have to be dragged to it.

You already flagged the 4x to 15x token multiplier in Step 0. Here's where the cost actually goes and how you'd cut it.

Where multi-agent cost lives: re-establishing context in each agent's prompt, re-retrieving the same data across agents, coordinator context that grows with every worker, and reflection/retry loops that double or triple calls. Name these specifically.

How you'd budget it down:

State a target: "I'd budget X cents per task and Y seconds p95, and instrument cost-per-task in the eval suite so a regression fails the build." Numbers make you sound like you've paid an OpenAI or Anthropic bill, because you have.

Here's how to run the clock so you hit all five graded signals without rushing the end.

The pacing matters as much as the content. Candidates who burn 20 minutes on the diagram and never reach eval fail even with a beautiful topology. This is the same time-management discipline as a classic system design interview prep round — budget the clock against the rubric.

Each answer ends with the grading signal so you know what's actually being scored.

1. Why use multiple agents instead of one bigger prompt? Because of parallelism, tool-scope separation, context-window limits, and model heterogeneity — not because multi-agent is trendy. If none of those apply, one agent wins; multi-agent costs 4x-15x the tokens. Signal: you justify from task structure, not hype.

2. Design a system that researches 10 companies and writes a comparison memo. Coordinator fans out 10 research workers in parallel (parallelism is the whole point), each scoped to read-only search and fetch, returning structured summaries. Coordinator aggregates and a synthesis agent writes the memo. Hub-and-spoke because decomposition is clean and known upfront. Signal: pattern matches task shape; you scope worker tools.

3. When would you pick blackboard over a coordinator? When the decomposition isn't known upfront and specialists should opportunistically claim work — open-ended problems. Cite the reported task-success uplift on those problems (as a range, not a hard number), and flag the claim/lock consistency cost you take on. Signal: right pattern for open-ended work, with eyes open on the tradeoff.

4. How do agents share state without re-retrieving everything? Shared store agents read from, or clean context-passing where each agent gets exactly its slice. Cache shared context so you pay once. The tradeoff is the latency-consistency-cost triangle — name which corner you pick. Signal: you treat shared state as a distributed-systems problem.

5. Two agents need to write the same shared key. What happens? Race and overwrite unless you add claim/lock semantics or a single-writer-per-key rule. Eventual consistency lets agents act on stale state; strong consistency costs latency. Signal: you anticipate the race before it's pointed out.

6. How do you stop a runaway loop that burns $1000s? Hard caps on total steps, recursion depth, and total cost; per-tool timeouts; per-agent token budgets; a circuit breaker on repeated failures. The budget guard is non-negotiable. Signal: you design for the signature multi-agent failure mode.

7. One worker fails mid-task. What does the system do? Partial-failure isolation: coordinator collects successes, marks the failure, retries if retryable, and decides if the partial result is usable. One worker dying never kills the run. Signal: graceful degradation, not all-or-nothing.

8. How do you evaluate this system? Golden trajectories for path correctness, step-level plus end-to-end accuracy (and the compounding math), an LLM judge validated against human labels, and cost-per-task plus latency as pass/fail metrics. Signal: you have a real eval plan, not "we'd test it."

9. Your LLM judge gives inconsistent scores. What's wrong and how do you fix it? Position, verbosity, or self-preference bias. Fix with a judge-of-judges: calibrate the judge against human labels on a sample before trusting it. Signal: you know the judge needs eval too.

10. Where does the cost go in a multi-agent system, and how do you cut it? Re-establishing context per agent, re-retrieval, coordinator context growth, and retry/reflection loops. Cut it with prompt caching, model routing cheap subtasks to a small model, and summary-only handoffs. Signal: you've paid the bill and know the levers.

11. When do you gate an action behind a human? By blast radius: anything that spends money, leaks data, or writes to prod gets a human checkpoint. Read-only research runs autonomously inside a budget. Signal: you reason about blast radius, not blanket rules.

12. How does this differ from designing a generative-AI feature with one model call? A single call is stateless and one-shot. A multi-agent system has persistent state, control flow across agents, compounding failure modes, and a 4x-15x cost multiplier. The hard parts are orchestration, state consistency, and eval — not the prompt. Signal: you understand what the multi-agent layer actually adds.

For adjacent rounds these questions feed into, see AI engineer interview questions.

Reading patterns isn't practice. The skill is talking through tradeoffs under a clock without freezing. Three drills:

Is multi-agent always better than single-agent? No. It costs 4x-15x the tokens and adds failure surface. It wins only when you need parallelism, tool-scope separation, a context too big for one window, or different models per subtask. Defaulting to multi-agent is itself a red flag in the round.

How is this different from a generative-AI system design interview? A generative-AI feature round centers on one model call: prompt, retrieval, output quality. The multi-agent round centers on orchestration, shared state, and failure handling across many agents. The hard problems are control flow and eval, not prompting.

What should I draw first? Not the diagram. Justify single-agent vs multi-agent first, then draw the orchestration. Drawing before justifying is the most common mistake and it signals you skip the "why."

How deep should I go on eval? Deep. It's the section that filters candidates. Golden trajectories, step-level plus end-to-end, a validated judge, and cost-per-task budgets. Volunteer it before you're asked.

Do I need to name a framework like LangChain or LangGraph? No. Knowing the concepts — checkpointing, supervisor topology, persistent state — matters more than naming a tool. If you do reference one, LangChain and LangGraph are the common ones, but a framework name without the underlying reasoning earns nothing.

Interview Coder helps you practice the multi-agent design round and the full agentic-AI loop with timed mocks and live feedback. Full disclosure: this guide is published by Interview Coder, its own product. The desktop app ships 20+ stealth features and serves 100K+ users; coding answers run on Claude Sonnet 4.6, Anthropic's latest Sonnet. Plans: Free $0, Monthly Pro $299, or Lifetime Pro $799 one-time. Start at interviewcoder.co and run a real 45-minute design round before your onsite.