A runbook is a written set of step-by-step procedures for operating a system and responding to known situations: routine tasks, alerts, failures and emergencies. For an AI agent, the runbook tells the people who run it what to check each day, what each warning means, and exactly what to do when the agent must be slowed, stopped or restored.
Why does a runbook matter for agents?
Agents are usually built by one team and run by another. The builders know how the agent works; the operations team knows the process it works in. When something goes wrong at the end of a busy day, the person on shift needs neither a design document nor a call to the builder. They need clear instructions they can follow under pressure.
A runbook also turns governance into routine. Policies say that agents must be monitored, that certificates must be renewed, that incidents must be contained. The runbook says who does which of those things, when, and how.
What should an AI agent runbook contain?
- Identity: the agent, its owner, its capabilities and the depth of each.
- Daily checks: held queue age and size, hold and refusal rates, reviewer edits, connected system errors.
- Alerts: each alert, what it means, and the first response.
- Stop: how to suspend a capability or the whole agent, and who may do it.
- Rollback: how to restore the previous version, and how to confirm it worked.
- Fallback: how the work gets done by people while the agent is down.
- Certification: when each certificate lapses and how recertification is booked.
- Contacts: owner, operations, engineering, risk, and the model provider's support route.
What an AI agent runbook should contain expands each item, and the AI agent runbook template gives a ready format.
What does an example look like?
A US consumer lender runs an agent that drafts payment arrangement offers. One entry in its runbook reads:
Alert: refusal rate for "draft arrangement" above normal range for one hour. 1. Check the verdict record for the deciding bound on recent refusals. 2. If the bound is sources, check the arrangement policy feed for errors. 3. If the feed is stale, drop the capability to depth 1 and notify the collections lead. 4. Route new arrangement requests to the collections team queue. 5. Restore depth only after the feed is confirmed current, with the lead's approval.
An operations analyst who has never seen the agent's code can follow it. The setting is described in AI agents in US consumer lending operations.
How is a runbook different from a playbook?
A runbook is specific and procedural: for this agent, when this happens, do these steps. A playbook is broader: how to approach a type of situation or process, with judgement left to the reader. A firm might have one incident playbook that applies to every agent, and a runbook for each agent that applies the playbook to its particular capabilities, sources and contacts.
It also differs from the agent's brief. The brief instructs the agent. The runbook instructs the people running it.
How do you keep a runbook useful?
Test it: run drills where someone follows the runbook exactly and notes where it was unclear. Update it with every change to the agent, as part of change management, so it never describes a version that no longer exists. Review it after every incident. See our guide to deploying AI agents for where the runbook fits before go-live.
Questions people ask
Who should write the runbook?
The operations team that will use it, with input from the builders. A runbook written only by engineers tends to describe the system rather than the decisions the operator must make.
Should the runbook be automated?
Some steps can be, such as alerts or routing work to a fallback queue. Decisions to stop, restore or raise depth should stay with named people and be recorded.