Question presented to candidate: "Your team wants to rebuild its single agent as a 'team' of agents: a planner, researchers, a coder and a reviewer. When is splitting work across multiple agents actually the right call, when is it a mistake, and how would you decide for a given task?"
What a strong answer should cover:
- The default is one capable agent with good tools; split only when a concrete constraint forces it
- The real reasons to split: context isolation (a worker explores a lot and returns a short summary), parallelism over genuinely independent subtasks, and separation of role or permissions (an independent reviewer, a worker without write access)
- The costs: lossy hand-offs (summaries drop the caveat that mattered), conflicting decisions between agents that cannot see each other, several times the tokens, harder debugging and more orchestration failure modes
- A decision test: are the subtasks independent (no shared writes, no decisions that must agree)? Is the task valuable enough to pay for more tokens? Would a better tool or prompt fix it instead?
- Named patterns and evidence: orchestrator-worker and parallelisation (Anthropic, "Building effective agents"), Anthropic's multi-agent research system results and its token cost, and Cognition's argument that parallel writers make incompatible implicit decisions
- Anti-patterns: role-play org charts (PM agent, architect agent) passing messages with no isolation or parallelism benefit, and parallel workers editing the same files
Clarifying questions expected:
- Are the subtasks independent, or do later ones depend on decisions made in earlier ones?
- Is the bottleneck context size, wall-clock time, or quality, and what is the budget per task?
Code / implementation expected: Optional β an orchestrator that fans out independent subtasks and merges summaries, or the decision logic for when to fan out.