grout

What it does

grout is a software factory on Mozaik: one command (npm run grout -- run spec.md) turns a one-page Markdown spec into a small TypeScript CLI or HTTP API whose tests pass, built by a team of agents working at the same time on one shared, versioned codebase, with no human writing code. The hazard it is built around: once agents edit the same codebase, it is shared mutable state, and two builders that read a file and write it back silently erase each other's work. grout treats the codebase like a database: every write is a compare-and-swap enforced by a Mozaik interceptor and the workspace; a stale write is refused and the agent re-applies its change on the current content. In 500 zero-token trials with the real runtime, three builders without the interlock lost updates in every trial (944 lost); with it, none, and still faster than one builder at a time. How it works: an analyst turns the spec into a ledger of requirements with verbatim quotes while an architect plans tasks with disjoint files; builders and black-box test authors then work concurrently; a verifier runs the whole suite on every change and routes each failure to the task that owns it; a reviewer checks finished tasks; an arbiter settles test-versus-code disputes from the spec; a release gate ships only when every requirement is covered by a passing test and a fresh container can npm ci, build and test it. Every run writes a trace with time and cost per task and an HTML report; replay works without a key. Hidden task: box-office ran once, unattended, zero human steps, two teams in parallel, green in 15 minutes for $9.60; the output passes an independent 68-test black-box suite. Practice: 8 unseen specs, 278/278 hidden tests over two passes, 16/16 releases green. Reviewer guide: JUDGES.md.

How the agents run concurrently

Every role is a Mozaik participant on one bus and every task attempt is its own agent loop, so the analyst and architect run at the same time, then up to three builders, two test authors, reviewers and arbiters run in parallel as concurrent loops in one runtime (with --candidates 2, two whole teams in parallel). They share one RuntimeState: the versioned workspace, the requirement ledger, a task board with leases and generations, the test matrix and the budget. They coordinate through events, not handoffs: the broker leases ready tasks to idle builders, the verifier reacts to commits, the review desk reacts to finished tasks, and messages reach a running agent mid-flight because the gate (an InterceptionHandler) delivers them into its context before its next inference. Concurrent writes are made safe by compare-and-swap: the gate enforces who may write what, the workspace refuses a write based on a stale read, and the refused agent re-applies its change on the current content. The run report shows the overlap: 4 to 8 agents running at once per run.