A Buildbook is an agent-executable document that installs a capability — a self-contained guide a coding agent follows once per adopter to build a system, after which re-running it does nothing new.
A buildbook converges. It moves an environment toward a declared target state — tools configured, templates created, schema in place — and it is finished the moment that state exists. Executed twice in a row against the same environment, the second pass is a no-op. "Once" means once per adopter, not once ever: each new person who adopts the system runs the buildbook once against their own environment, and never again. The document assumes nothing beyond its own text — an agent holding only the buildbook can complete the build end to end.
The counterpart is the 📝Runbook, which operates a recurring process rather than installing one. The litmus test that separates them: run the document twice in a row — if the second execution does nothing, it is a buildbook; if it does new work, it is a runbook. The two are phases of one lifecycle: a buildbook installs the machinery that a runbook then exercises.
Buildbooks are distributed behind a human-facing overview memo that explains the system's value and ends with a kickoff prompt handing the buildbook to the reader's agent, keeping the human's reading and the agent's execution cleanly separated.
We coined this term on 2026-07-10 while promoting our SEO bolstering experiment into a recursive process — we needed names that tell an agent what to do with a document on sight, and "build" is the verb: construct once, verify, stop.