AITOOLS builder/auditor loop

Where it came from

In May 2026 I sketched an idea I called the MCP Dev Factory: Claude Code driving a build, with AI checking the work. I handed the concept to Aldo, a colleague, who expanded it into a v2 to v4 protocol.

So the idea came back to me improved. In October 2026 (the 9th to the 11th) I rebuilt my own portable version and proved the loop by hand.

The loop

Brief → Builder writes the change
          ↓
        Auditor reviews it against the brief
          ↓
        Fix list → Builder fixes → Auditor re-checks
          ↓
        Done when the audit passes

The builder and the auditor are kept separate on purpose. An assistant reviewing its own work tends to agree with itself.

Who does what

Role	Who	Does
Builder	Claude Code	Implementation, unit tests, fixing audit findings, docs, structured handoffs
Auditor	Codex	Independent review; returns READY or NEEDS CORRECTIONS. Only an unqualified READY qualifies a release
Planning and troubleshooting	ChatGPT	Architecture discussion, failure analysis, PowerShell help, reviewing evidence from the other two
Authority	Me	Decisions, approvals, deployment, and production acceptance

The rules

The workspace has a governance project, AITOOLS-PROTOCOL, that holds the architecture and the numbered design decisions every agent works from. The principles:

One canonical source of truth. No divergent working copies.
Separation of duties. Builder, auditor, and operator are different roles.
Audit gates. Nothing is accepted because its author says it works.
Traceability. Decisions, changes, handoffs, tests, and failures get written down.
Safe defaults. New integrations and anything that costs money start disabled.
No silent irreversible actions. Destructive or out-of-scope changes need approval.
Deterministic safeguards. Critical boundaries are enforced in code, not left to an LLM’s good behavior.

One lesson from running it: newer decisions supersede older baseline text, and an agent that reads only the oldest architecture file gets outdated instructions. Reconciling the documents with the actual Git state comes first.

Where I’m using it

Jarvis Engine, the biggest project built this way: about 930 automated tests, several audit rounds, and a release process with go-live gates
Hollowell House
Blunderbook
Cutroom
TECH-RESOURCES, the engineering documentation library

Write-ups for each of these are coming.

What’s next

RELAY, automation that would pass work between builder and auditor without me in the middle, is planned but parked. I want the manual loop to be boring and reliable first.
Applying the same loop to planning and policy design, not just code. The audit step is just as useful on a plan as on a pull request.

The broader research questions live in the AI Lab under coding workflows.