The model is not the institution

Neither the implementation agent nor the reviewer earns trust by being smart. Trust comes from a system that forces claims through evidence, policy, tests, and limited authority. Disagreement between agents produces claims that someone has to resolve, and two models arguing is no proof.

Intelligence and authority are separate properties. Capability determines what work a model is useful for. The system determines what it is allowed to do, and what evidence is required before its result is accepted.

The other design has a case: a capable model with a large shell works well for reversible changes with one owner and fast feedback, where the ceremony costs more than it returns. This argument covers the rest, and it holds up as models improve. Separation of powers exists for reasons unrelated to competence. You route authority around a capable person for reasons that outlast their competence: attribution, reversibility, and enforcement that does not depend on the judgment being enforced.

Adding a reviewer moves the trust problem#

The obvious answer is a second agent: one writes the code, another checks it. That moves the trust problem downstream. Why believe the reviewer? Two models agreeing tells you very little, since they can accept the same mistaken assumption or miss the same requirement.

So the rule we ended up with is harder than "get a second opinion." No review pass votes on another pass's finding, because a second opinion from a model that did not investigate adds nothing. A verdict with no investigation behind it gets rejected and retried.

One production failure came from a missing database permission for governed tool binding reads. The obvious repair granted the SELECT and scoped the main binding read under row-level security, and that would have closed the ticket. The review followed the neighboring path and found a second defect: another read of the same table with no tenant context installed. The repair grew. That path now runs in its own scoped transaction, released before downstream authorization performs further reads. A regression test asserts that an ordinary channel stays visible while another actor's binding is filtered out.

The claim named a specific read, the repair was checkable, and the invariant is now a test that holds next quarter under a different reviewer, model, and provider.

The implementation agent must not be able to make the gate green by weakening a test or granting itself permissions. Two controls cover this:

• Prevention. The reviewer holds credentials the candidate code never touches.
• Attribution. A person can still override a correct finding, and that decision carries a name.

What the review contract has to own#

A model can produce an implementation, a critique, an argument, a proposed test, or a recommended disposition. The state machine, the authority boundaries, the definition of sufficient evidence, and the permission for each transition all sit outside the model.

Models can recommend state transitions. They should not unilaterally define or execute them.

Swapping a review model takes one API change. The institution stays intact: which version was reviewed, what evidence supports a finding, which checks are mandatory, who authorizes the next action, and what happens when review is incomplete.

Rules:

• An approval applies to the artifact that was actually reviewed, and a later change starts over.
• A timeout records as a timeout.
• Missing evidence stays missing.
• Every exception carries an authorizer.

Reads resolve against the immutable reviewed head, so a verdict cannot quietly attach to different code. A pull request cannot modify the lesson file that instructs its own review, because the review runs from the trusted base, which owns the reviewer and its credentials, while candidate source is data. The regress ends somewhere the agent cannot reach.

Only an explicit maintainer mark records an outcome. Merges, silence, and bot reactions record nothing.

Authority ends at a person, with five dispositions: confirmed, false positive, duplicate, accepted risk, unresolved. accepted risk is a human overruling a correct finding on purpose. The system allows it and makes the decision carry a name, which is its own design problem.

The control software is software too, so failures in the reviewer become tests like any other.

Model choice as a routing problem#

Once authority and verification live outside the model, the model is a configuration value. A recent change in our application repository was implemented through Codex and reviewed by Gemini 2.5 Pro, on the same runtime with the same context and tools. How we turned our coding agent into our own bugbot covers that machinery.

Each role needs a model that clears the threshold for that role under a specific policy, and the globally best model is unnecessary. Model choice becomes a scheduling decision.

Cost is the obvious objection, and the marginal numbers are small: an 8.4 KB diff reviewed with a security specialist took 18.3 seconds at an estimated $0.0716, and identical reviews are reused from a fingerprint. The expensive outcomes are a cheap reviewer raising endless false alarms, or a fast one that ships the defects it missed.

Limits#

We cannot estimate our own recall. We hear about misses when someone reports them, and a small historical corpus does not establish recall.

Our bug database is our Git history, so the review loop improves on failure modes it already catches and stays blind where it was already blind. Ground truth is rationed by attention: only an explicit mark counts, so the loop runs at the speed of a person willing to read carefully. Rules ossify too, so ours expire unless renewed.

Every example above is code review, the easy case, with a diffable artifact and executable evidence. The general gate evaluates any action against identity, resource, arguments, run context, and policy version, but comparable evidence for a refund, an outbound send, or a production delete is harder to get.

Claude, GLM, GPT and other model families sit closer to labor pools than to products. Above them sits the machinery: assignment, authority, review procedure, evidence requirements, escalation, and recordkeeping.

I want to know what an agent was authorized to do, what evidence justified the decision, and which rules were enforced before the action happened.