When you put an agent in charge of writing code, the first impulse is to put another agent in charge of reviewing it. That part is fine. The part most people get wrong is picking the second agent from the same model family as the first.
I had Claude writing PRs against Freebo for weeks. Then I had Claude reviewing those PRs. Everything looked good. Diff summaries came back clean, tests passed in CI, the ledger updated. I merged a few, and then I started catching the kind of mistake that only a specific family of model makes — a shape of wrong answer Claude is temperamentally comfortable with, and therefore the review Claude was temperamentally comfortable rubber-stamping.
A reviewer that shares the author’s blind spots is a cheering section with extra steps.
So I rewrote the rule, and it’s now the load-bearing line in the whole Freebo agent pipeline:
Never verify with the author. Pick the other model family.
— FD Coordinator skill, standing orders
The setup
The pipeline has three roles. They do not overlap.
The Coordinator is the thing that decides what gets built. It reads my goal, scopes a unit of work into one PR, writes a brief, and dispatches an owner agent. It never writes code. It never merges. It never promotes. The whole point of its existence is routing and bookkeeping — it keeps a program tracker that reads like a line in a terminal:
The Owner is the agent that writes the code. One owner per unit. Default is Claude, but it can be any model. The owner works in a git worktree with its own branch, its own port slot, its own scoped task file. The merge/promote/deploy commands are denied on this agent at the harness level — if it tries to merge its own PR, nothing happens. It can only produce code and push the branch.
The Verifier is a fresh agent that reads the PR at a specific SHA, runs the local app end-to-end against that commit, screenshots the result, and writes a verdict. CI passing is an input to the verifier. It is never the verdict. The verifier owns result.json.
The verifier picks the other model family. If the owner is Claude, the verifier is Codex. If the owner is on a codex/* branch, the verifier is Claude. The coordinator makes this call automatically — I don’t choose it per PR.
That one rule is doing almost all of the work.
Why family matters more than skill
The appealing explanation would be “the verifier is smarter than the owner.” It isn’t. Both models are first-class. The thing that matters is that they are differently wrong.
Claude has a specific way of being overconfident. It likes clever abstraction, it likes consolidating three cases into one function, it likes giving you a comment that explains why its choice was correct instead of a test that proves it. When Claude reviews another Claude’s PR, those exact moves read as hallmarks of a careful engineer. The reviewer nods at the thing it would have done too.
Codex is wrong in different directions. It will happily restate a problem instead of fix it. It is less likely to compliment architectural choices and more likely to grind on whether the input validation handles the empty-string case. When Codex looks at Claude’s PR, the clever abstraction is not read as a sign of care — it’s read as “what is this doing, and does it handle null.” The verdict comes back with the questions a cheering section would skip.
Flip it. When Codex writes a PR, Claude is the one asking “wait, why is this three branches instead of one,” which is exactly the question Codex won’t ask itself.
What the Coordinator actually does
The Coordinator’s standing orders live in a skill file in the repo. The parts that matter:
- Never write or edit application code
- Never commit to an owner's branch
- Never relay messages between agents
- Never merge, approve, mark ready, push to main/production
- Ask Brett only for a real decision: an irreversible action,
a product call, or a dead end that survived a replan.
Retries, flakes, rebases and "should I continue" never reach him.Every one of those lines is there because it broke before.
The coordinator that writes code starts rewriting other agents’ work. The coordinator that merges forgets to wait for the verifier. The coordinator that relays messages becomes a game of telephone. The coordinator that asks the human about retries wakes you up at 2am to say Supabase hiccupped.
Stripping jobs away from the coordinator is what makes the whole thing fast. It has one call to make per unit of work, and the call is “has the verifier (not me, and not the owner, and from the other family) said yes at this SHA, and is CI green at this SHA.” If both are true, it hands the PR to me with the merge command. I merge.
The part that scales
The reason this matters for a one-person project: once author and verifier are forced to be different families, the number of concurrent owners stops being bounded by my attention. It’s bounded by whether the two model families can each handle a slice of the work.
I ran twelve owners in parallel last week. The coordinator was Claude. Nine of the owners were Claude. Three were Codex. Every PR Claude wrote was verified by Codex; every PR Codex wrote was verified by Claude. Nothing merged without the opposite-family verdict landing on the exact SHA I was about to merge.
I didn’t review the diffs. I read the verdicts.
The takeaway
If you’re running multi-agent pipelines and you only pay attention to one line of this, make it this one: the author’s model family is not allowed to be the verifier’s model family. Not “the same prompt but a fresh session.” Not “the same model with a different temperature.” A different family of training, a different company’s biases, a different shape of wrongness.
Agents don’t disagree enough by default. You have to engineer disagreement in. The cheapest way to engineer it in is to make sure the two agents reviewing each other’s work weren’t raised in the same house.