Seven models reviewed the same change. They disagreed.

We changed the retry logic in our own scheduler and put the merge request through the same multi-model review playbook we run on every change: seven models read the diff, each with the same instructions, each writing its review before any of them sees another’s.

That last clause matters. If reviewers can see each other, they converge. The second model anchors on the first, the third summarises the first two, and by the end you have one opinion wearing seven names. So the playbook runs the reads as isolated stages. Nothing crosses between them until every review is filed.

Here’s the shape of what came back on a 400-line diff:

• blocker claude-opus-4-7 flagged that a failed cleanup inside the backoff path was caught and logged but never rethrown, so a run could report success after a partial teardown.
• question gpt-5.3-codex read the same lines and called them fine. It spent its review on a query that would scan a whole table once retry counts got large.
• blocker kimi-k2.5 and deepseek-v4 both landed on the swallowed error too, independently, in different words.
• question gemini-3-pro asked whether the new jitter window could starve the queue under load. Nobody else raised it.
• clean qwen3-235b and glm-5 filed short, tidy reviews: style notes, one naming complaint, no blockers.

Three of seven converged on the swallowed error. One raised a load concern no other model saw. Two saw nothing serious.

Disagreement is the product

When three models from three different labs independently point at the same line, you fix that line. No debate needed.

The lone dissent is the more interesting case. gemini-3-pro’s starvation question was the kind of thing that’s either nothing or an incident. It cost us ten minutes to check (it was nothing, the window is bounded upstream), but the point is that the panel put a bounded, checkable question in front of a human instead of a vague feeling that something might be off.

And the two quiet reviews are signal too. If every model files blockers on every diff, your panel is noise. When the quiet ones stay quiet on routine changes and light up on real ones, you learn to trust the distribution.

Why the panel crosses model families

A panel drawn from one lab fails together: models trained in the same house share blind spots, so their agreement tells you less than it appears to. Mixing frontier models with open-source ones, kimi-k2.5 sitting in the same run as claude-opus-4-7 with the same instructions and the same output contract, is what makes agreement mean something and disagreement worth reading.

What the run looks like

The whole thing is one playbook. A trigger fires when a merge request opens, seven review stages fan out in parallel, an aggregation stage judges the reviews against written merge criteria, and the merge itself waits for a person.

Two kinds of gate, and the difference is the whole design. The aggregation stage is a judged gate: a model applies criteria you wrote. The merge stays behind a held gate: a human clicks it, every time, until you decide otherwise. When the panel splits the way it did here, the run parks itself in your attention inbox with the split laid out.

Every run ends with a receipt, itemised per call. This one:

Worth noticing: the four open-source reads together cost less than half of one frontier read, and two of them found the blocker. That’s the quiet argument for panels over a single expensive reviewer, and it’s why the receipt itemises per call instead of reporting one number. You end up tuning the panel the way you’d tune anything else with a cost column in front of you.