The Foreman Method
The written law I use to run a fleet of AI build agents. Take it.
AI agents made building cheap. They did not make it safe, legible or adoptable; that took a process document. This page is that document, made generic so you can run it tomorrow. It was earned one incident at a time on two production-grade codebases, and every rule below exists because its absence once cost something specific.
The org chart
Three roles. Only three.
The principal (one human) touches decisions, not transport: design rulings, scope, deadlines, reversals of standing rules. If the principal is routing messages between sessions or reviewing diffs line by line, the org chart has drifted. Fix the org chart, not the backlog.
The foreman (one long-lived agent per repository) holds merge authority and dispatch authority. It spawns builders, reviews their work, runs the gate and merges. It is the only thing that merges.
Builders (one short-lived agent per change) each get a brief, build on their own branch in their own isolated worktree, and report back in a standard format.
Sessions sign every report with a role tag. Instructions name their addressee in the first line. A session that receives an instruction addressed to another role bounces it back instead of executing it. Misdelivered authority is how two confident agents build two different things.
The life of a change
- Brief. What to build, what’s explicitly out of scope, which fixtures to use, what the gate expects. Demo-bound work adds three lines: deadline, demo surface, freeze window.
- Build. On a branch, in a worktree, at an absolute path. The builder verifies its own claims before reporting (see the proof culture).
- Report. A table: what changed, one commit per change, judgment calls flagged rather than buried, and open questions numbered for a ruling.
- Rulings. The principal answers the numbered questions in batches. Rulings are dated and land in the record. A later ruling beats an earlier artifact; a dated ruling beats an undated image; repo facts beat rulings.
- Gate. The foreman independently re-derives every claim it acts on: clean rebase, types, full suite, regenerated snapshots, a visual check in a real browser. Independently means it doesn’t trust the builder’s report.
- Merge or bounce. Gate-clean work merges. A bounce returns to the session that built it, with the mechanism named. Bounces fix categories, not instances.
The law: the rules doing the most work
- Ambiguity escalates; it never gets interpreted. When evidence conflicts with a standing decision, the build stops and the principal gets one yes-or-no question before anything is built. Origin: one ambiguous sentence once produced two confident, opposite implementations.
- One change per commit, and every commit passes the gate on its own. Chunks sized to fit one human code review.
- All fixture data is fictional. An invented cast with production-true shapes and zero real records, enforced by guard tests that scan for anything resembling a real name, email or account number. This rule is why the system is safe to run at full speed: there is nothing to leak.
- Design values come from the design file’s API, never from an eyedropper. Display vocabulary is a closed set ruled from the design source; a word not in the set is an invention, however sensible.
- Production reference is read-only. Structure and vocabulary may inform; values never cross.
- Snapshots regenerate; nothing is hand-merged. Fixture sets derive from a registry, and an invariant counts blocks against it. “Purely additive” is a shape, not a proof.
- Never swap code under a presenter. A freeze lifts only on the principal’s explicit all-clear.
The proof culture
The habits that keep a fleet honest, which is to say, the whole thing.
- A test doesn’t count until you break the code on purpose and watch the test catch you, by name. Then fix it and regenerate. A check that can’t fail isn’t a check: we once caught a verification step silently matching nothing and reporting success.
- A claim inherited from another session is not your finding. Find it in the diff yourself, or say you couldn’t.
- A status marker is not a process. Liveness is verified against the actual process tree, never against a registry entry. A “busy” flag once guarded a worker that had been dead for hours.
- Outbound documents get re-verified at send time. Stale claims rot fastest in summaries.
- If a stat reads as reassuring, ask whether it’s actually the tell.
The day you can trust it: when one agent challenges another agent’s already-merged conclusion, unprompted, and turns out to be right. Mine did. That’s not a malfunction. It’s the only way one person’s delivery organization scales past one person.
What each piece costs you if you skip it
- No briefs: agents solve the wrong problem, fast.
- No worktree isolation: checkout collisions.
- No numbered rulings: confident guesses.
- No independent gate: you inherit the builder’s optimism.
- No proof culture: a green dashboard over a dead process.
- No fictional-data law: you move slowly forever, or leak once.
Steal it
Rename the roles, keep the bones, and let your own first incident write rule one of your local amendments. That’s how this document got every rule it has. If you run it and it breaks somewhere interesting, I genuinely want to hear about it: email me.
Where it came from: Part One, the delivery system, and the diff that audited the design system.