Running Claude and Codex side by side, with a written protocol

I run two AI coding agents on my own work — Claude Code and OpenAI’s Codex — instead of picking one. This post is about the written rule that makes that workable instead of chaotic: one agent owns a given task and its final output, the other only reviews or advises inside a bounded brief, and neither edits the same file at the same time. That’s the whole idea. The rest is what it takes to actually hold it.

Why use two agents instead of one?

The honest answer isn’t that either tool is better in some measurable way — I haven’t run a controlled comparison and I’m not going to pretend I have. The reason is more practical: they’re built by different labs, trained differently, and fail differently. When I’m deep in a piece of code and can’t tell if a fix is actually right or just looks right, a second model from a different vendor catching the same bug I missed is worth more than a second opinion from the same model asked twice. Same-family review tends to share blind spots.

The cost is real too. Running two agents means more setup, more context to keep straight, and more chances for them to step on each other’s work. That’s the problem the protocol exists to solve.

What does “one agent owns the task” actually mean?

Whichever agent gets the task first is the owner. It holds the plan, does the final integration, and is the one that has to verify the work actually holds up — not just claim it does. The other agent is a contributor: read-only by default, and only allowed to write to specific files if the brief explicitly says so.

In practice this is designed to prevent the obvious failure mode of running two agents unsupervised: both convinced they know the right fix, both editing the same function, and whoever’s watching left to reconstruct which version is actually live. Now there’s always one agent who has to answer for the final state, and the other’s job is narrower — review, a second opinion, or a bounded rescue attempt when the owner has failed at the same problem twice.

Why write the protocol down instead of just prompting each time?

Because I found I couldn’t actually hold a consistent standard in my head across sessions. Ask for “a second opinion” one day and “check this for bugs” the next, and you get two different scopes of review, two different assumptions about what the reviewing agent is allowed to touch, and no record of what either agent decided or why. A written protocol fixes the shape of the exchange: what a handoff brief has to contain, what a return has to answer, and what counts as done.

The brief format I use is short on purpose — a page, not a report. It states the objective, the one deliverable, what’s already decided, a handful of concrete pass/fail checks, and exactly what the contributor is allowed to read, write, or touch at all. The return has to answer in the same shape: what changed, what was verified and how, what’s still uncertain. If a review claims something works, I expect to see the command that was run and the result it produced, not just the sentence “this works.”

That structure is also what makes the handoff survive me stepping away. If I come back to a task a day later, the written brief and return tell me what happened without my having to reconstruct it from a long scrollback.

Where does it break?

A few places, honestly.

It adds real overhead for small tasks — writing a scoped brief for a one-line fix is slower than just fixing it, so I don’t bother for anything trivial or for routine work that doesn’t ship. The rule only earns its keep on work substantial enough that a second, independently-trained set of eyes is worth the setup cost.

It also depends on me actually verifying the contributor’s return rather than trusting it. A review or a rescue attempt is only as good as the check I run on top of it — “the other agent said it’s fixed” is not evidence, it’s a claim. I’ve caught confident-sounding returns that didn’t hold up once I ran the actual test.

And it only works if ownership is unambiguous. If both agents ever got pointed at the same task independently, the rule is that whichever one starts first owns it and the other reads that starting point rather than opening a competing thread. Miss that step and you’re back to two agents each convinced they’re in charge.

Is this worth it for one person?

For me, yes, on anything that ships — which is most of what I build, since I run my own tools on my own work rather than treating this as a side experiment. For everything else, a written protocol between two AI agents is more process than the task deserves. The value isn’t in having two agents; it’s in having a rule that stops two agents from quietly working against each other, and a record of what each one actually did.

See what I’ve built with this setup at /work.