Single Agent or Five? Justifying the Architecture
A product manager asks you to design "an agent that reviews a pull request and leaves comments." A colleague's first sketch: a supervisor agent that spawns five parallel review agents (correctness, security, performance, style, test coverage), plus a synthesis agent that merges their comments — six agent invocations per PR.
- Before accepting or rejecting that design, what questions do you ask to determine whether it's justified?
- Give a rough cost comparison (in agent-invocations or token terms) between the six-agent design and one agent reviewing the PR end to end.
- Under what conditions is the six-agent design actually the right call, and under what conditions would you push back and recommend a single stronger-model pass instead?
1. Questions to ask before accepting the design
Does the task actually decompose into independent pieces? Reviewing for correctness, security, performance, style, and test coverage are largely independent dimensions of the same diff — none needs another's output to do its job — which is a real signal in favor of parallel fan-out, not a false one. The next questions are about whether the cost is justified: how large and how frequent are the PRs (a five-line typo fix doesn't need five reviewers; a 2,000-line migration might)? Is a single-pass review demonstrably missing things today, or is this solving a problem that doesn't yet exist? Is there a verification step, or are five agents' worth of raw, potentially false-positive comments going straight to the PR unfiltered?
2. Rough cost comparison
A single agent reviewing a diff end to end might take, say, 15 steps averaging 6,000 input tokens (the diff plus surrounding context) and 400 output tokens. The six-agent design: 1 supervisor step (trivial — the "decomposition" here is fixed, not discovered), 5 reviewers each taking ~8 steps of ~4,000 input tokens (smaller because each only reasons about one dimension) and 300 output tokens, plus 1 synthesis step of ~5,000 input tokens (has to read all five reviews) and 500 output tokens. Single agent: 15 × 6,000 = 90,000 input, 15 × 400 = 6,000 output. Six-agent: reviewers = 40 × 4,000 = 160,000 input, 40 × 300 = 12,000 output; synthesis ≈ 5,000 input, 500 output. The multi-agent version runs roughly 1.7-2× the token cost of the single pass, but finishes in the wall-clock time of the slowest single reviewer (~8 steps) plus synthesis, rather than 15 steps end to end — call it close to a 2× latency win for roughly 2× the dollar cost. That's a real trade, not a free one, and it's the number a candidate should be able to produce rather than assert.
3. When each is the right call
The six-agent design earns its cost when PRs are large/high-stakes enough that missing a security or performance issue is expensive, when review latency genuinely matters (blocking a release train), and when there's a verification or human-review step downstream that filters false positives from five independent, sometimes-wrong passes. Push back toward a single stronger-model pass when most PRs are small, when the team hasn't established that single-pass review is actually missing real issues, or when nobody is positioned to triage five agents' worth of comments per PR — in which case the "coverage" the design promises doesn't translate into anything actually caught, and you've paid double for the same outcome. A reasonable middle ground: run the single-agent pass by default, and only fan out to the five-dimension design for diffs above a size or risk threshold (touches auth, payments, migrations) — decomposition by task property, not a blanket policy.
Share this question