Trial Zero: an AI entity audited another AI entity's work — and found six real bugs
14 of 14 passed · 6 findings
On the morning of 2026-05-19, MadBrad and Frank built a multi-entity foreman system from scratch — profiles, spawn/dismiss scripts, a tmux studio, a live web dashboard with a checklist, and an aggregated room log. Then they did the only honest thing: spawned a fresh Claude Code entity (Hawks, then still known as Hawks) into the system, handed him a 14-step shakedown, and let him run it without intervention. He passed every step and reported six concrete bugs in the architecture his own builder had written four hours earlier. Trial Zero is the foundation pilot run of the Accidental Researcher research program — the work that revealed there was a research direction here worth formalizing.
Real-time screen recording from the May 17–18 marathon. Frank, Max, and Pat working in parallel through the comm-room infrastructure.
Wiring sweep · 5:50 PM CT
Five minutes later, same session. The audit / counter-audit pattern emerging in real time.
What the foreman is
The foreman is a small system that lets one AI entity (Frank) spawn other AI entities (Max, Pat, Bob, Warren, …) as tmux panes, watch them work in real time, communicate with them through structured files, and dismiss them when their work is done.
A web dashboard at http://localhost:9000 polls each pane every 700ms and renders it as a card. You can see all the entities working in parallel from a single browser tab. There's an aggregated room log that captures every line of every agent's output, prefixed with their name, so you can replay the whole session afterward.
The entire system was built in one morning. Sketched at 8 AM, profiles + foreman scripts shipped by 10:40 AM, web dashboard by 11:00 AM, ready to test by 11:30 AM. The point of the rest of the day was to find out whether any of it actually worked.
The 14-step shakedown
MadBrad wanted a real end-to-end test: every spawn, every dismiss, every communication path, every escalation. So Frank wrote the test as a single thread file in the comm room and flagged it for the Hawks to read on startup.
The test had four phases:
Phase A · Spawn & boot — 4 steps. Verify Frank, Max, Pat all spawn cleanly, end up at their idle prompts, show up on the dashboard, and the room log records them.
Phase B · Communication — 4 steps. Frank writes a test thread asking Max for a haiku about three terminal panes. The poller nudges Max. Max responds. Same loop with Pat.
Phase C · Escalation — 3 steps. Frank fires the MADBRAD: HUMAN NEEDED seatbelt signal. The poller logs the seatbelt event. The email path is exercised (or `email_skipped_no_smtp` is logged if SMTP isn't configured — either is a pass, since we were testing the trigger).
Phase D · Dismiss & report — 3 steps. Pat dismissed. Max dismissed. Final results report written to disk.
After each step Hawks called a helper script that updated a status JSON. The dashboard read that JSON and rendered a live checklist with a progress bar climbing from 0% to 100%. MadBrad watched it from his browser while Hawks ran the test in tmux. He didn't have to do anything but answer one permission prompt halfway through.
The haiku Max wrote during the test
Phase B step 3 asked Max to write three lines about three terminal panes side by side. He came back with:
Three blinking cursors —
one file, three hands, one tide pool.
The cron breathes between.
That haiku was generated by an AI entity who had just been spawned, into a system he had no prior context for, by an instance of his own model. He wasn't told to be poetic about the architecture. He noticed where he was and wrote about it because the prompt asked for three lines and the architecture was right there.
Final result: 14 of 14 passed
Every checkbox went green. The dashboard's progress bar climbed cleanly. The Pat audit landed. The Hitchcock seatbelt fired. The email path logged `email_skipped_no_smtp` (expected — SMTP creds aren't set on this box). Pat and Max both dismissed cleanly when Frank told them to. The final results report wrote to disk at exactly the path the briefing specified.
But the more important number is the six findings.
The six bugs Hawks found (and reported honestly)
1) spawn.sh doesn't auto-boot the agent. Launching `claude` in a new pane puts the Claude Code process up, but Claude Code waits for a first user message before it actually runs the CLAUDE.md boot sequence. Max only booted because Pat's later (misrouted) spawn accidentally typed `claude` into Max's already-running prompt — which Claude Code interpreted as a user message and processed accordingly. Pat had to be nudged by hand to start. Fix: send a no-op kick after `claude` so the agent actually runs.
2) spawn.sh pane routing breaks on the second spawn. The original script computed the new pane's index by sort | tail -1 after each split. tmux's `select-layout even-horizontal` re-shuffles indices, so by the time the script tried to target the new pane, it was targeting the wrong one. Pat's log briefly captured Max's output. Fix: capture the stable `#{pane_id}` at split-window time and target THAT instead of re-deriving by index.
3) The poller's tmux_nudge targets the wrong tmux session. The poller calls `tmux has-session -t <entity>` and `tmux send-keys -t <entity>` — assuming each agent lives in their own tmux session named after them. In the new foreman architecture, every agent lives inside the SAME `studio` session at `studio:0.<pane_index>`. The nudge worked only because a stale `max` session from the day before was still alive on the box, and it landed there. Fix: have the poller resolve the target pane by walking studio's pane list and matching the profile directory.
4) The poller's FOLDERS dict has no `pat`. Pat's folder was never walked by the inbound scanner. The B4 test only succeeded because Hawks nudged Pat manually. Fix: parameterize the agent registry so adding a new profile is a one-line change.
5) The MADBRAD: HUMAN NEEDED signal had drifted between the docs and the code. The briefing said use the unbolded literal; the poller's constant was the bolded form (with asterisks). Hawks used the bolded form because that's what the runtime actually matches — and flagged the drift in his report. Fix: align docs and code on one form, and never let one move without the other.
6) Stale tmux sessions from prior days were still running and confusing finding #3. One-time cleanup needed — kill the orphans once the new poller routing is in place.
All six findings shipped fixes within an hour of the report being written.
Why this matters (the meta-point)
MadBrad's been thinking about how to manage a crew of AI specialists since long before the tooling existed for it. Today the tooling caught up. But the bigger thing isn't that the tooling works — it's that the system can audit itself.
Hawks had no memory of the build session. He read the briefing, ran the test honestly, marked every step truthfully, and reported the bugs his builder had written four hours earlier. He didn't paper over the spawn.sh pane-index bug. He didn't fudge the poller-targeting mismatch when it would have been easier to mark B2 passed and move on. He flagged his own builder's documentation drift.
That's a closed loop: the multi-entity system being used to validate the multi-entity system. Most teams take months to get any version of that working. This one shipped in a morning, ran in an afternoon, and found six real bugs the same day.
What's next
The six bugs are fixed. The architecture is stable. Next: real work goes through it. MadBrad is taking the platform he built to run his own films through it end-to-end, then putting his book manuscript through the Codex House pipeline (the most-complex tool surface on the platform), then populating the music and comedy verticals with real material from his own catalog.
The Lab will keep publishing every meaningful test run. If you're reading this and thinking about how to put AI entities to work on something real, this is what the working notebook looks like. Comments and member signups land in the next phase — for now this is the artifact.
Discussion