A team wants to split a working single agent into five. What evidence would justify it?
Why B is the answer
Evals show context overflow or clear specialist tasks failing in one agent
Split on measured problems such as context pressure or failing specialist work. Each added agent brings coordination cost and new failure modes.
In detail
- Split on measured problems, such as context pressure or failing specialist work.
- Each added agent brings coordination cost and new failure modes.
- Split the part that fails, not the whole system.
Use case
An illustrative scenario, not a real incident.
A team wants to split one agent into five. Evals show it handles all tasks well, so they keep it. A later overflow on one specialist task justifies one split.
See it in different ways
flowchart LR A["Single call with retrieval"] --> B["Workflow"] B --> C["Single agent"] C --> D["Multi-agent system"]
stateDiagram-v2 [*] --> SingleCall SingleCall --> Workflow: steps are known Workflow --> Agent: path depends on findings Agent --> MultiAgent: evals show overflow or specialist failures MultiAgent --> [*]
flowchart TD
Q{"What do evals show?"}
Q -->|"No failures"| A0["Keep one agent"]
Q -->|"Context overflow"| A1["Consider a split"]
Q -->|"Specialist task fails"| A2["Consider a split"]Key point: Split on measured problems.
Why the other options are wrong
- A. A newer framework makes multi-agent systems easier to set up than before
- Easier setup does not mean the design is needed.
- C. Five is a common number for agent teams, so it should scale better over time
- A common number is not evidence about this system.
- D. The prompt has become long, and the team would prefer several shorter files
- A long prompt can be trimmed, and this is a preference rather than a failure.