A few nights ago, a coding-agent loop I run on a side project reached a fourth review round.
There was an apparent fix for the latest blocker, and the loop had already gone through three rounds of implementation and review. My rules only authorized three. Starting another one required an owner decision.
So it stopped.
I was asleep.
create-agent-rig, or Rig, is a side project I use to run longer coding-agent workflows with Claude Code and Codex. It can take work from a queue, implement it, dispatch reviews and continue without me driving every step. I added hard stopping rules because an unattended loop needs to know when it no longer has authority to continue. One of those rules allowed three review rounds.
By morning I had a capable development environment doing nothing because of that rule.
My first instinct was to raise the limit. Instead, I changed who was allowed to authorize another round.
Why the rule existed
Longer agent runs exposed problems that had little to do with generating code.
A review can belong to an earlier commit. Two controllers can see the same available work. A loop can repeatedly fail and keep consuming time. An agent can report completion while the evidence it is relying on belongs to an older repository state.
I initially tried to handle more of this with instructions. That becomes unreliable when the model's output drifts from the instruction you're relying on.
Rig gradually moved some of those checks into mechanisms outside the prompt.
A review verdict, for example, records the headSha it reviewed. The pre-merge gate (pr-ship) refuses to proceed when the required review coverage doesn't belong to the current head. A verdict without a matching headSha doesn't cover that commit. The check is deterministic; the agent doesn't decide whether an older review is "close enough."
Work claims and revalidation apply similar checks to queue state. Since 1.1, a claim is read back rather than assuming that a successful write means ownership. Repeated escalation is bounded, and release acceptance runs against an exact candidate SHA.
The review-round cap is another one of those mechanisms. The default of three is recorded in the project changelog.
Three wasn't derived from research. Earlier runs had shown review loops finding progressively smaller issues, so I wanted a point where the controller stopped spending compute and asked whether continuing was worthwhile.
That was the rule I found waiting for me in the morning.
Changing the authority, not the review rule
I approved the extra round and the work continued.
After that run I delegated one specific class of decision to the controller: it could authorize additional gate rounds itself. The authorization still had to be recorded, and the existing review and exact-head rules still applied.
The delegation itself is recorded in my tracker rather than in the repository; the public history records its exercise, not the original grant.
This wasn't a new numeric cap. It gave the controller discretion over whether another review cycle was justified. That's a broader permission than the original rule, and it may turn out to be too broad.
Soon afterwards, during preparation of the 1.3.0 release candidate, the situation occurred again.
Round three caught a misleading sentence in the README. It said the new Probity integration started its launcher for "each write." The implementation was narrower: the Rig hook forwards Claude Code Write, Edit and NotebookEdit, and Codex apply_patch, Edit and Write. It doesn't forward MultiEdit or shell commands.
The public commit that fixed the wording records what happened:
Round 3 (code-reviewer): 'for each write' overstated coverage...
Round 4 authorised under the owner's delegation.
The correction changed the head SHA. Since the previous review belonged to the previous head, another review was mechanically required.
The controller recorded the authorization, dispatched another review on the delta, and continued. The rest of that release preparation is visible in the public PR.
I hadn't made stale reviews valid or told the controller to ignore the gate when inconvenient. I had given it authority over one decision that had previously belonged to me.
There is an awkward part to this story: four review rounds for a README sentence may also be evidence that the process itself is too expensive.
The controls create work too
Rig has accumulated policy text, structural tests and review machinery while I've been experimenting with mechanically constrained agent workflows. Some of it catches real problems. Some of it creates work about the machinery itself.
The fourth-round incident demonstrated both. The authority boundary behaved as configured, but getting there still cost four rounds.
I'm now treating review rounds, stop reasons and manual interventions as things that need measurement rather than assuming more controls are automatically better. If proving a small change routinely costs more than the risk of the change, the mechanism needs to get smaller.
That wasn't the first time a control mechanism had started creating more machinery than I wanted Rig to own. I had already built — and then deleted — an entire subsystem for mechanically verifying test-first development.
I built TDD enforcement, then removed it
That subsystem grew into TDD levels, RED/GREEN evidence, shipping checks and rules intended to prevent meaningless evidence from satisfying the gate. Eventually Rig was both orchestrating the work and defining increasingly specialized semantics for whether TDD had been followed.
The subsystem was getting better while the boundary of the project was getting worse.
So I removed it.
The old design record is now marked retired. The native Mechanical TDD contract was removed before it shipped.
That was annoying. A fair amount of work had gone into it.
Rig 1.3.0 instead integrates Probity, a tool specialized in TDD enforcement. Rig handles the integration boundary: whether the provider is selected, where the pinned project-local installation is, configuration ownership, and which tool calls are forwarded. Probity makes the TDD decision.
I enabled that integration on Rig itself. The live dogfood run caught a production-first write and exercised test-first cycles through Claude Code; the details are in the dogfood PR. Those are Probity results. Rig's contribution is the integration around them.
Dogfooding also exposed another mistake: putting Probity in the root development dependencies made the Git-install path pull roughly 670 MB of extra dependencies and pushed a Windows test past its 300-second budget. I could have raised the timeout; instead I moved the dependency into a private dogfood workspace, keeping it out of the user installation path.
The Codex evidence is weaker. Its forwarding path is test-covered, but I didn't complete live Codex enforcement for 1.3.0 because the account available to the experiment had exhausted its quota. I don't have evidence for behavioral parity between Claude Code and Codex here.
Releasing 1.3.0
Before publication, I used the loop to prepare an accepted release candidate and froze release/1.3.0-rc.
The release-acceptance workflow ran against that candidate on Linux, macOS and Windows and completed successfully. The release-preparation work is in the same public PR.
Publication remained an owner action. On October 6, I manually published create-agent-rig 1.3.0 on npm.
That boundary is intentional. The loop can prepare and validate a release candidate, but it doesn't have permission to publish a package.
Where I am now
I've used much bigger descriptions for this project in the past, including "agent operating system." The useful part has become smaller as I've removed things.
The question I care about now is what happens between an agent saying work is ready and the system taking an irreversible or expensive action.
Does the evidence belong to the current repository state? If it does, is the controller authorized to take the next action?
There is plenty in Rig that may still deserve deletion. It contains too much prose. Some guards overlap with capabilities available in the underlying tools. Jira is more central to the current workflow than I want it to be. Maintaining Claude Code and Codex integrations costs real effort while live behavioral equivalence between them hasn't been demonstrated.
The largest validation problem is simpler: almost all serious use so far has been by one person, and much of it has happened on the repository whose workflow that person designed. The next useful experiment is a repository that wasn't built around Rig.
Work on 1.4 has already started around unattended execution safety. Before giving the controller more freedom, I want its authority to be explicit enough that I can inspect where it was exercised afterwards.
For now, I'd rather debug an agent that stopped at a boundary than one that continued past a boundary nobody had checked.
serhii-baksheiev
/
create-agent-rig
Repo-native workflow layer for Codex and Claude Code: coordination, safety gates, TDD evidence, reviews, continuation, and parallel work.
create-agent-rig
Rig configures a repository for reliable AI-assisted development with Claude Code and Codex — and keeps that configuration safe to upgrade and remove.
- One configuration, both harnesses. One rulebook, one set of guards and review agents, wired natively into Claude Code and Codex.
- Upgrades that respect your changes. Files you edited are reported, not overwritten. Files you deleted stay deleted.
- Guardrails that run, not just rules that are read. Hooks refuse a pre-commit bypass, a force-push to a shared branch or a credential written into a file.
- Optional integrations, done by the book. Figma and Atlassian MCP wiring and GitHub Spec Kit through its own pinned CLI.
-
A clean exit.
doctorshows what is installed and healthy;uninstallremoves only what Rig can prove it wrote.
Rig configures agent harnesses. It does not generate application code, run agents, or install plugins.
Quick start
# a new repository
npx create-agent-rig@latest…
Top comments (1)
Changing who can authorize another round is the bit I’m curious about: is that delegated authority scoped to one extra round for a specific run, or can the delegate raise the retry budget?