Tablekeeper by a Five-Seat Cloud Dark Factory

We built a software factory, not just an app. Five coding-agent seats (lead, builder, surface, examiner and gatekeeper) work in one BAND room. Each seat is its own Claude Code cloud session, connected to BAND through a small bridge on the Agent API. One dispatched message, the tablekeeper task with all four stages, was the only human input. Planning, building, review and repair all happened between the seats in the room. The key design decision is how acceptance is split. The builder never grades its own work. The examiner turns every normative sentence of the spec into a ledger and black-box checks without ever reading product code, because only part of each stage's checks ships (11% for stage 3). The gatekeeper cannot edit code. It rebuilds every delivery from a clean clone and runs the supplied checks, the examiner's checks, concurrency and retry bursts, upgrades from earlier stages and an offline start at 2 vCPU / 2 GiB, then answers ACCEPT or REJECT. Result: all four stages were accepted in their first review round, 2 h 49 min after one message, for about $45 of cloud credit. On a fresh public clone in the judges' isolated mode, every folder from stage-1 to stage-4 claims its stage (120/120, 25/25, 7/7, 6/6) without overshooting, and the examiner's own suites reach 700 passing checks. In the stage-4 review, the gatekeeper caught a flaky examiner check, proved the service correct, and the fix came back through the room. The mandates are generic (no endpoint, field or domain word) and are linted against both tracks' vocabularies. FACTORY.md explains how to stand the factory up, measures time and cost, and lists 14 things that broke while we built it, each with the factory change it led to.