Agent architecture — how we do code review

Ask one model to review a change and you are not getting an opinion — you are getting a set of weights. One training run, one post-training, one set of biases baked in at the factory. Whatever those weights are blind to, the review is blind to, and it states that blindness with full confidence. Run the same model twice and you do not get a second opinion; you get the same blind spot, photocopied.

So we do not. Every change here goes through a round table: four different models — different training, different strengths, different blind spots — each holding one narrow lens over the same frozen diff, with a fifth reconciling them into one verdict. Different models fail differently, and that is exactly the leverage: a mistake hidden in one model's weights is precisely what another model's weights surface.

Four angles, not four copies of the same opinion

Instead of one model asked to check everything, multiple reviewers each hold a single lens. Ask a model to check everything and its attention smears across the whole diff — every rule gets a shallow pass. Give it one lens and its entire attention lands on that one question.

• Gates — does it compile, do the tests pass, does the build hold — the mechanical bar.
• Conventions — the rules we committed to that no linter enforces: naming, structure, how failures are handled.
• Tests — did this change earn a test, or bend one to fit.
• Docs — did it move a premise the knowledge base reasons from.

Four different models hold those four lenses — not four copies of the same one. A model that is sharp at one kind of attention is mediocre at another. You stop betting the whole review on one model's attention — four overlapping beams instead of one narrow one.

A round table needs one table

What keeps four independent reviews coherent is that they all read the same frozen snapshot — assembled once, up front: the change itself, the gate results, the inventory of what moved. There is nothing to disagree about except the judgment.

The moderator runs the argument. Each reviewer reports findings in one flat format — tier, file, rule, what the code does, the fix — and the moderator reconciles them: deduplicates, prioritizes, names where they disagree, and asks for clarification until they converge. Three rounds at most, then it emits the verdict. When they don't fully agree, the moderator reports the disagreement rather than a false consensus.

one frozen diff
     │
     ├──▶ gates        ── does it build, do the tests pass
     ├──▶ conventions  ── the rules no linter enforces
     ├──▶ tests        ── did it earn one, did it bend one
     └──▶ docs         ── did it drift what we already know
                        │
                        ▼
                  the moderator ──▶ clean · N findings · blocked

A researcher briefs the table

Before any of that, a sixth role runs: the researcher. It reasons about what platform knowledge the reviewers will need, pulls it from our context engine, distills it, and hands it over as a briefing.

The roles that have to honor a strict contract get no tools. This is not theory. The first time the researcher ran with a shell available, it ignored the contract entirely — it ran a couple dozen commands and read files, investigating the change on its own, and never once did the one thing it was asked to do. We took the tools away, and the role did what it was built for. The reviewers see only the frozen snapshot and the briefing the researcher assembled — text in, text out. The review is the whole case, not a starting point for an investigation of their own.

Everything is logged — twice

This is how you debug a review. When a verdict looks wrong, you don't re-run and hope — you read the trace and see exactly which reviewer saw what, and where the reasoning turned. That trace is the whole reason we log the run at all.

Every run writes two logs. One is the high-level story — what was asked, what each model said, what the moderator concluded, and per call the tokens burned, the time it took, the cost. The other is the raw, verbatim trace — every model call, every step of reasoning, archived per reviewer. The first is for skimming; the second is for understanding why a model said what it said.

Because it is a machine-readable record, it is not just for humans. Future agents read it to answer how much a run cost, how many tokens it burned, where the time went, what this reviewer actually thought, which findings keep coming back.

the summary   one line per moment   →  the whole argument at a glance
the raw trace every call, verbatim  →  one reviewer's exact reasoning

The verdict is the fix list

The output is a flat, prioritized list — every finding with a tier, the file and line, the rule it broke, what the code does, and the fix in one line. And it lands in the same log as everything else.

So the loop closes on the agent that made the change. It reads the verdict, fixes the blockers, and re-runs. The review is a machine-readable feedback log, written for the machine that has to act on it.

Future improvements

A review that cries wolf gets ignored, so the reviewers are told to verify every candidate before it becomes a finding — discard most, report few. Five real findings beat twenty guesses.

The table is not always unanimous. It gets its three rounds; if it still disagrees, the moderator synthesizes the disagreement instead of pretending it converged. And the researcher can under-brief — answer done without pulling enough, and the reviewers judge with less context than they should have.

We are not claiming the review is infallible. Four reviewers thin out the blind spots, but the moderator that turns their findings into a verdict is still one model, one final opinion — if it misreads the table, the answer is wrong. What we do claim: when the review is wrong, the log tells you exactly where.

Code review used to be one opinion. Here it is an argument with a record: four models, one frozen diff, a briefing, a moderator, and a log the next agent reads. Same shape as everything else we build — built so the machine doing the work gets better at doing the work.

Read next

The pieces this round table leans on have their own tellings:

• The context engine — the semantic index over the codebase the researcher pulls from before the table sits. /devlog/context-engine
• MCP and the context engine — how agents reach that knowledge over the open protocol. /devlog/mcp-context-server-native-agent-tools
• Reasoning chains — how the knowledge a review leans on compounds across sessions. /devlog/reasoning-chains-how-agent-knowledge-compounds