Five reviewer agents, or one review five times?

Graph Engineering pattern 3 of 15: the PR Review Graph. Independent reviews converge on one accountable decision — assigned concerns, read-only review edges, and a gatekeeper that verifies coverage.

Five reviewer agents are not five reviews if they share a context. They are one review, five times — same findings, same blind spots, with a confidence boost none of it earned.

Context for new readers: this is pattern 3 of 15 in the Graph Engineering series — designing agent organizations as graphs, one topology per class of work. Review is where most teams first discover that more agents is not the same as better output unless the topology enforces independence.

The problem

A change is proposed. It must be examined across several orthogonal concerns — correctness, security, architecture, tests, performance — and a single accountable approval decision must result. The two halves pull in opposite directions: the examination parallelizes; the decision must not.

The topology

             Reviewer 1
            /
  Author --+- Reviewer 2 --> Gatekeeper --> Merge
            \
             Reviewer N

The author submits to N reviewers, each assigned one concern. Reviewers work in parallel and — critically — without edges to each other, so their findings are independent. Each reports to a gatekeeper, which aggregates, deduplicates, weighs severity, and produces one decision: approve, or return to the author with consolidated changes requested. The gatekeeper alone faces the merge gate.

The two structural rules

Reviewers read and report; they never write. N agents independently "improving" a PR produces a merge disaster and destroys the trail of who found what. Review edges are read-only by construction.

Findings converge on one node. Without a gatekeeper, the author receives N partially contradictory review streams and becomes the de facto integrator of their own reviews — the exact conflict of interest review exists to remove.

Independence comes from assignment, not from copies

Running the same reviewer prompt five times buys almost nothing: shared prompt, shared context, correlated findings. Assigned concerns are what make the parallelism real — the security reviewer is reading for injection and authorization, the performance reviewer for allocation in hot paths, and neither can recruit the other into its story.

The gatekeeper's real job

Silence is not approval. A gatekeeper that approves whenever no reviewer objects has turned an unrun security review into a clean one. The gatekeeper verifies coverage — did every assigned review actually run and report? — and weighs severity, which is also what prevents committee deadlock: minor findings inform; they do not block.

Where it breaks

• Correlated reviewers — copies instead of concerns.
• Rubber-stamp gatekeeping — counting objections instead of verifying coverage.
• Review-by-committee — every reviewer with a veto turns nits into blockers.

The dimension answers

The examination parallelizes. The decision must not. That asymmetry is the whole pattern — and it is a property of the graph, not of any reviewer's diligence.

Next: pattern 4, Feature Fan-Out/Fan-In — why parallel agents producing individually correct components does not produce a correct system.

Building this with design partners → rysh.ai/design-partner