Pebble: a payments app built by an agent factory

Most multi-agent demos add agents and hope. We measured what actually goes wrong, then redesigned the team around it. THE PROBLEM. In run 1, our five agents built a payments app, but a reviewer rejected a batch while three more batches were stacked on the broken code, and it flagged the same blocker three times. Stale branches blocked merges, a fixed-interval timekeeper sent 49 of 65 wake-ups while nothing was wrong, one room hit Band's 10,000-message cap, and a human had to step in. THE FIX IS COORDINATION, NOT MORE AGENTS. Same five seats, new operating model, written into the mandates: work is a dependency graph; a batch starts only when what it builds on is merged; one branch per batch; one review per batch; the reviewer checks screenshots at phone and desktop width; a close-out roll call gates every stage report; the timekeeper speaks only when the room is quiet. Claude Sonnet plans and reviews; a low-cost model writes code and tests. THE RESULT, FROM THE ROOM LOGS. Four stages built and verified from one dispatch, with zero human messages after it (run 1: 5). Batches stacked on a rejected one: 4 to 0. Needless timekeeper wake-ups: 75% to 2%. Rejections fixed and merged in 7 to 58 minutes (median 15), against 3 h 31 min and still unmergeable in run 1. 35 committed screenshots. Stage 4 acceptance suite: 70 passed, 0 failed, 1 expected skip. THE APP. Pebble: pay, request, split, hold and refund. Payments are retry-safe: 50 concurrent identical requests produce exactly one payment, so money is never spent twice. WHAT DID NOT IMPROVE. Run 2 cost more messages (+28%), time (25.6 h to 29.8 h) and spend (about $10.50 to $25). Claude session limits stalled both runs for about 30% of the clock, and our process did not fix that unless we use api keys without any limits. We went with Claude sessions for now. The mandates name no product, so the factory can be pointed at a new problem.