Ask ten candidates to describe a multi-agent system and most of them will give you the same diagram: a few boxes labeled with agent names, arrows between them, maybe an “orchestrator” box at the top. That diagram is table stakes. It’s not what separates a hire from a pass.
What separates them is what happens in the follow-up question — the one where the interviewer asks “and what happens when one of those agents fails?” Candidates who’ve only read about multi-agent systems freeze here, or reach for something generic (“add retry logic”). Candidates who’ve actually built one have a specific, immediate answer, because they’ve watched it happen.
The question behind the question
“Design a multi-agent system” is rarely really asking you to design a multi-agent system. It’s asking three things at once, in order of how deep the interviewer wants to go:
Do you know when NOT to use one? The strongest opening move in this answer is restraint — naming the specific conditions that justify splitting into multiple agents (context window limits, genuinely different expertise per step, parallelizable work) rather than jumping straight to a topology diagram. Interviewers use this as an early filter: candidates who treat “multi-agent” as inherently more sophisticated than “one well-scoped agent” are signaling that they haven’t had to defend the added complexity to anyone yet.
Do you understand what the orchestrator actually does? Not “coordinates the agents” — that’s a paraphrase, not an answer. The orchestrator’s job is narrower and more concrete: decide execution order, and validate every handoff before passing it downstream. The second half of that sentence is where most candidates go vague, and it’s exactly where the interview gets interesting.
Have you actually watched this fail? This is the part that can’t be faked with reading. There are two failure modes that only show up once a system has more than one agent talking to another, and an interviewer who asks a good follow-up question is fishing for whether you’ve encountered them directly.
The failure interviewers are fishing for
The first is what’s usually called silent corruption: an agent returns bad or empty output, nothing checks it, and the pipeline finishes anyway — reporting success on a result that’s actually garbage. There’s no crash to point to. The system just quietly produced nothing of value, and unless someone built a handoff-validation check, nobody finds out until a user complains. Interviewers ask about this specifically because it’s the failure mode that separates “has operated a multi-agent system in production” from “has built a demo of one.” A demo never hits it. Production does, eventually, without fail.
The second is prompt injection carried between agents rather than arriving from a user. If one agent’s output can contain text, and the next agent reads that text as instructions instead of data, then anything upstream that can influence the first agent’s output — a compromised tool result, a scraped page, a bad retrieval chunk — can effectively issue commands to the second agent. No malicious user required. The fix candidates are expected to name is treating every inter-agent message as untrusted content, the same discipline applied to raw user input.
What a complete answer sounds like
The strongest answers in this space consistently hit five things, roughly in this order: why multi-agent is justified for this specific task, what the pipeline shape looks like, why the orchestrator is plain code rather than another LLM call, what gets validated at each handoff and what happens when validation fails, and — critically — the specific failure modes above, named with their fixes. Skipping the last one is the single most common gap. A candidate who describes a clean topology but has never had to explain what happens when a handoff goes wrong hasn’t yet been asked the question that actually differentiates.
None of this is really about impressing an interviewer, though. The reason “have you watched it fail” is such a good filter is that it’s also the actual engineering risk. A multi-agent pipeline that’s never been stress-tested against empty output and adversarial content isn’t ready for production regardless of who’s asking the questions.
If you want to see these two failure modes actually triggered — not described, triggered, with real output — Session 06 of the AI Transition Course walks through building a working 3-agent pipeline and deliberately breaking it both ways, so the debugging happens in a sandbox instead of live.