When multiple agents help or hurt
“When does splitting a system into multiple agents improve it, and when does it make the system worse?”
What this tests
- Whether the candidate questions the need for multiple agents before designing them
- Concrete criteria for a split: responsibilities, context, capabilities, parallelism
- Awareness of coordination cost, latency, cost, and evaluation difficulty
- Ability to describe failure modes of multi-agent systems
Answers by level
Read the beginner answer first and notice what is missing.
A split helps when the parts have genuinely different responsibilities that would otherwise crowd one prompt, need independent context (a reviewer should not see the drafter's reasoning, or a worker needs 50k tokens of documents the coordinator does not), need different capabilities (different tools, permissions, or models, such as a cheap model for extraction and a strong one for judgement), or can run in parallel on independent sub-tasks. The boundary between agents must be a clear, typed contract. See Multi-Agent Systems Overview and When Not to Use Multi-Agent.
It makes the system worse when the agents share most of their context (you now pay to transmit it), when the task is sequential and one agent could do it with a longer prompt, when coordination requires many round trips (each is an LLM call plus latency), or when nobody can say what each agent is responsible for. Information is lost at every hand-off because agents summarise for each other, and errors compound across hops.
The precondition is always: can this be solved reliably with one agent or a deterministic workflow? If yes, the split is cost without benefit. If not, I introduce the smallest number of agents with the clearest boundaries and evaluate the whole system end-to-end, not each agent in isolation.
Green flags · Red flags
- Separation of responsibilities as a criterion, not a slogan
- Independent context or context isolation as a reason to split
- Different capabilities: tools, permissions, models
- Parallel execution of independent sub-tasks
- Clear, typed boundaries and completion signals between agents
- End-to-end evaluation against a single-agent or workflow baseline
- Explicitly accounts for added coordination cost, latency, and information loss
- Assumes more agents automatically produce better results
- No discussion of latency
- No cost awareness
- No mention of coordination complexity or information loss at hand-offs
- No evaluation strategy for the multi-agent system
- Creates a separate agent for every small task