What belongs in an agent runbook

An agent runbook should let a second person explain what a job will do before it runs. Start with its trigger, the records it can read, the actions it can take, and the condition that ends the job. A description such as 'handles customer operations' is too broad to diagnose a failed run.

Record the owner of each outside dependency and the action to take when it is unavailable. Keep credentials outside the runbook. Refer to a secret by its configuration name, and document the smallest access scope needed for the task.

Write down the recovery path. If a job sends a message and crashes before recording success, replaying it might send the message again. A useful runbook explains how to check whether the action already happened and how to resume without repeating it.

Review the document against one real example. Follow a request from arrival through authorization, execution, and the final receipt. Any step that requires the original developer to explain it is a gap in the runbook.