Evaluate the handoffs, not just the agents. In a composed system each agent typically verifies its own output, which says nothing about the quality of its input — so every agent can pass its own check while the system produces a wrong answer. Splitting one agent into several doesn't make the system more wrong; it makes the wrongness unattributable, because the single trace that showed which step failed is now several traces with the failure sitting in a gap between them.
Splitting an agent into several is usually the right call, and it buys three real things: a smaller context per agent, so none of them is reasoning around instructions meant for someone else; different tools and permissions per role, which is a security argument as much as a quality one; and independent iteration, so you can replace one agent without re-testing the others.
What it costs is the thing nobody prices in. A single agent running five steps produces one trace, and the step that went wrong is in it. Five agents running the same five steps produce five traces, each ending in a local pass, with the failure sitting in the seam between two of them. The system is no more wrong than it was. It just no longer shows you which part did it.
An agent's self-check is a statement about its output, evaluated against its input as given. It contains no claim that the input was any good. So an agent handed a confidently wrong summary will do competent work on a false premise and pass its own check honestly while doing it.
This is why per-agent accuracy misleads. Each agent's score was measured on clean input. In the chain it receives the previous agent's output, and nobody has measured it on that. Errors also correlate — shared prompts, shared base model — so a confident bad handoff tends to get amplified rather than caught by the agents downstream of it.
The single highest-leverage design decision in a composed system is what crosses each boundary.
If a seam has to pass prose, that is the seam to instrument most heavily — or the argument for not splitting there at all.
Turning the whole team on at once means every failure arrives simultaneously and none of it is attributable. Promote in tiers instead, ordered by two questions: can you check this agent's output automatically, and what can it reach when it's wrong?
Agents whose output is checkable and whose blast radius is contained go first. Agents whose output needs human judgement stay advisory — proposing, not acting. An agent that both requires judgement and can reach production or the open internet is the one that stays in a sandbox longest, and the control that matters there is egress: an allowlist of what it may reach, credentials scoped to nothing else, and no path to anything real.
Lowering an agent's priority is a shipping decision, not a verdict on the agent.
The short answer above is ours, and we've written at length about how we got to it: