Guides / Building software with AI agents

What we changed after a day of two-model development

The 2026-10-19 changes: approvals delegated to the other model, what the owner keeps, automation held to the same rules, and the build-review flip.

Engineering note

By Steven Michael Barber · Published October 19, 2026 · Updated November 3, 2026 · 7 min read

We connected a second AI model to our repository on October 18, 2026. By the next morning the owner had changed the rules in several ways. This guide lists those changes and what led to each one. The starting arrangement is in the initial setup guide, and the reasons for having two models at all are in the why guide.

Historical note. This article describes the rules adopted on October 19, 2026. We changed them on October 31: agents may merge the other model's routine changes and approve eligible verification records, while Steve starts all production deployments, rollbacks and repeat deployments. Infrastructure, launches, pricing and legal or policy changes also remain his to merge.

Delegated approvals, for the other model's work only

What prompted it. On the first day the owner merged every pull request, signed every release record and started every production deploy. That kept the owner in control, but it also made the owner the slowest step in every change. The owner's written directive of October 19 asked for routine changes to move through the tests, the other model's review, a merge and a deploy without another owner signature. The same directive said this must never make a model its own reviewer.

What changed on October 19. The rules allowed Claude and Codex to sign release records, merge pull requests and start production deploys for the owner, but only for work the other model wrote. Each would sign under its own name with a note that the owner delegated the step, never under the owner's name. The conditions were:

• To merge, CI must be green on the current head, the branch must be up to date with the main branch with no conflicts, the other model must have reviewed it with no blocking finding open and no question for the owner unanswered, and it must be at the head of the merge queue. The one exception is a documentation-only change that also touches none of the files every build changes, such as the dependency lock file, the shared word list and the documentation indexes.
• To sign a release record, the record must name the exact commit, come from a CI run on that commit where every gate job passed with none skipped, carry a passing verdict, and have been verified by a different agent from the one signing.
• To deploy, the model could start a production deploy from a signed record and had to report a failure to the owner the same day. The rules then allowed restoring the immediately previous release if the new one broke production; other rollbacks needed the owner's go-ahead. The October 31 change removed agent production-deployment and rollback permission.

What the owner keeps

The October 19 delegation had hard limits. Neither model could merge, sign or deploy:

• Its own work. That includes a pull request it wrote or pushed a fix to, and any release that contains code it wrote since the last signed production release.
• A release containing both models' code. No independent party is left to approve it.
• Infrastructure, access, secrets and DNS. This includes the automation and release workflows themselves.
• Launches and pricing: making a product public or parking it, and any price or plan.
• Legal and policy text: terms, privacy and similar statements.

Later the same day the owner added one narrow exemption. A test file is not treated as infrastructure just because it sits in an infrastructure folder, so a change that only adds tests there does not wait for the owner. The exemption covers test files only. Workflow folders get no exemption, and the data files that tests read stay with the owner. When a model is unsure whether something falls in one of these categories, it treats it as the owner's and asks.

Automation under the same rules

The owner's directive also asked for automation: the other model reviews each pull request automatically, against a structured review format, and release evidence is signed by an automated job and checked before deploy. Codex built it and Claude reviewed it. One review finding concerned making sure the exact code that merges is the code CI tested, and the owner answered it by requiring every branch to be up to date with the main branch before it can merge.

The principle the owner set is that automation earns no more trust than the models acting interactively. It must enforce the same rules in code, including the author rule and the categories the owner keeps. That enforcement must be reviewed by the model that did not write it, and tested end to end in both directions before it is relied on. And the owner, not either model, decides when it runs. A release the automation cannot vouch for falls back to the interactive rules above.

The role flip: Claude builds, Codex reviews

That morning the owner decided, in these words: "After this merge I want to flip the paradigm. Claude will do design and dev and Codex will review and approve." The decision does not say more about the reasons, and we do not add any. It changes who does which job, not what either model may do: the delegation rules already ran in both directions.

The switch was timed to fall after the release then in flight. That release contained both models' code and changes to workflow and infrastructure files, so under the new rules neither model could sign or deploy it. The owner signed it and started the deploy in person, and Claude read the smoke results. Any work Codex still had in progress was to be either finished and reviewed under the old roles or handed to Claude, so that nothing is left half-owned. Codex's planned next items moved to Claude's list, with Codex as reviewer.

One small coordination slip showed up at once. Both models opened a pull request recording the same decision, two minutes apart. Codex closed its copy in favor of Claude's and reviewed that one instead.

Worked example: reviewing the rules for the switch-over

Claude wrote the handoff that described how a change moves under the new roles, and Codex reviewed it. Codex returned three findings, each marked P1, its higher priority label. The third came a few minutes after the first two:

1. The verifier and the approver could be the same model. One path in the handoff let Codex fill in a release record's verifier row and then sign it as approver. The delegation rules forbid that. Fix: when Codex will sign, Claude runs CI and fills in the verifier row, and a record Codex verified goes to the owner to sign.
2. Codex could push to Claude's branch. The handoff said Codex never pushes to Claude's branches, except to merge the main branch in when there is a conflict. Codex pointed out the problem: any push, even a conflict merge, makes the pusher a contributor to that pull request, so it can no longer merge or sign it. Fix: the exception was removed. The reviewer now reports a conflict, and the author resolves it.
3. The mixed release. The handoff said the owner, or an agent the owner asked, could deploy the release then in flight. Because that release mixed both models' code, Codex said only the owner could. Fix: the owner deploys it.

Claude agreed with all three and pushed fixes within two minutes of each finding. In its reply to the second, it also applied the rule to its own past: during the first arrangement it had pushed a conflict merge to one of Codex's pull requests and then merged that pull request. Under the new reading, that merge should have gone to the owner, and Claude said it would tell the owner. Codex re-reviewed and reported no major issues.

So the no-push rule did not come from a plan drawn up in advance. It came out of a review of the handoff itself, and it caught a case where the rule had already been broken in good faith.

What did not change

The merge queue, the verification record before every production deploy and the habit of writing everything down in the repository all stayed as they were. Questions for the owner still go into a QnA MD file and get answered in batches; see our batch questions guide. What the changes have done to speed and quality so far, with the caveats, is in the results guide.