A Runbook is an agent-executable document that operates a recurring process — each execution consumes a fresh input and produces a fresh output, so re-running it is not just meaningful but the point.
A runbook cycles. It is triggered by recurring occasions — new data lands, a call ends, a review window closes — and each execution is a complete run against inputs that did not exist the last time. The document carries the operational weight a repeated procedure demands: preconditions checked before work begins, exact steps with literal commands, and a verification pass that closes each run. An agent holding only the runbook can execute a full run end to end.
The counterpart is the 📝Buildbook, which installs a capability rather than operating one. The litmus test that separates them: run the document twice in a row — if the second execution does new work, it is a runbook; if it does nothing, it is a buildbook. A buildbook installs the machinery that a runbook then exercises.
Recurrence is the defining property; recursion is an upgrade. A self-improving runbook writes a durable run log per execution — the empirical record of what was done and what resulted — and carries a change log of versioned edits to the process itself, each citing the run logs that motivated it. The loop closes when one run's results become the next run's improvements.
Named on 2026-07-10 when our SEO bolstering workflow graduated from experiment to recursive process — the first runbook in the library to carry the full run-log and change-log loop.