AI Agent Operational Runbook Template: Define Boundaries, Guardrails, and Escalation Paths Before Launch
TL;DR
Most AI agent failures in production are definitional failures, not model failures. The agent did something it was technically capable of doing but that the product team never intended and never wrote down. This template is the operational document that prevents that failure mode: it defines what the agent is, what tools it can touch, what actions require human approval, how to detect failure, and who owns the response. Every agent going to production needs one. Use this template before you write the first line of system prompt.
The AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.
Why Agents Fail Without a Runbook
A runbook is a standard operational document in software infrastructure. Every on-call engineer has one for each critical service: what the service does, what healthy looks like, what failure looks like, and what to do when it fails. AI agents need the same document, but almost no teams write one before launch.
The failure modes that a runbook prevents are consistent across agent types. Here are the four most common:
Scope creep in production
What happened: A customer service agent sent a full product refund instead of a partial store credit because the refund tool was available and the agent was instructed to 'resolve the customer issue.' The team had defined success as resolution, not resolution within policy bounds.
Missing escalation criteria
What happened: A legal research agent marked a contract clause as standard when it was actually non-standard for the jurisdiction. No escalation threshold existed for jurisdiction-specific uncertainty. The clause went to the client unchecked.
Ambiguous tool permissions
What happened: A scheduling agent was given read access to the calendar API and write access to create events. It started deleting conflicting events on behalf of the user without being explicitly authorized to delete anything. 'Write' was interpreted as full CRUD.
No defined failure state
What happened: A data processing agent hit an API rate limit and silently dropped records rather than queueing for retry or escalating. The team only discovered the data loss three days later during an unrelated audit.
Every one of these failures could have been prevented by a document that existed before the agent launched. The runbook is that document.
Part 1: Agent Identity and Scope
The first section of the runbook establishes what the agent is supposed to do and, critically, what it is not supposed to do. Every word here reduces ambiguity that would otherwise show up as agent behavior in production.
TEMPLATE: Part 1 — Agent Identity and Scope
Agent name and version
e.g., Customer Refund Agent v1.2
Version every significant change to the agent prompt, tools, or escalation rules. Version drift is how incidents become hard to diagnose.
Primary objective (one sentence)
e.g., Process standard refund requests from customers within Refund Policy v3 without human review.
If you cannot state the objective in one sentence, the scope is too broad for a single agent.
In scope: what the agent is authorized to do
e.g., Issue store credits up to $50. Process full refunds within 30 days of purchase. Send confirmation emails from the support@ alias.
Be specific about dollar amounts, time limits, system scopes, and user types. Vague authorization is an attack surface.
Out of scope: what the agent is NOT authorized to do
e.g., Issue cash refunds above $50. Modify order records. Communicate with customers outside the support ticketing system. Access accounts other than the one in the active ticket.
This is the most important field in the runbook. The out-of-scope list should be longer than the in-scope list. If a behavior is not explicitly listed here, it may be attempted.
Intended users or triggering conditions
e.g., Triggered by customer support tickets tagged 'refund-request' with ticket age under 7 days.
Define the exact conditions under which the agent activates. An agent that activates on the wrong trigger class is a significant source of incidents.
Owner
e.g., Product owner: [name]. On-call engineer: [rotation link]. Legal review owner: [name for policy changes].
Every runbook needs a named human who is accountable for the agent's behavior and who will be paged if it misbehaves.
Part 2: Tools, Permissions, and Hard Boundaries
Tool access is the most concrete form of agent permission, and it is the most often under-specified. When you give an agent access to an API, write down exactly which operations within that API the agent is authorized to call and which it is not. "Read access to the database" and "write access to the user record" must be spelled out at the operation level.
TEMPLATE: Part 2 — Tools, Permissions, and Hard Boundaries
Tool inventory
| Tool / API | Authorized operations | Blocked operations | Rate limit / ceiling |
|---|---|---|---|
| Orders API | GET order details, POST refund (within policy) | DELETE order, PATCH order items, bulk operations | Max $500 per refund, 1 refund per ticket |
| Email / comms API | Send from support@, use approved templates | Send from other aliases, free-text email body | 1 outbound per ticket per hour |
| Customer record API | GET contact details | PATCH, DELETE, any write operation | Read-only scoped to active ticket customer |
| [add more rows as needed] |
Hard limits (enforced at the infrastructure level, not by the agent prompt)
e.g., Refund ceiling of $500 enforced via API parameter validation, not agent instruction. Rate limit of 100 tickets per hour enforced by queue, not agent self-regulation.
Hard limits are controls that exist outside the agent. Do not rely on the system prompt alone to enforce critical constraints. The agent can be confused; the infrastructure should not be.
Data the agent can access
e.g., Ticket content, order history for the ticketing customer only, product catalog (read-only). Cannot access other customer records, internal Slack, or admin dashboards.
Principle of least privilege: the agent should see only the data it needs to complete its task. Broad data access is both a security risk and a source of unintended behavior.
Confidentiality constraints
e.g., Agent must not repeat PII from the customer record in outbound communications beyond the customer's own name and order number.
Define what the agent can and cannot say about the data it has access to. This matters for customer trust and regulatory compliance.
Ship Agents That Actually Work in Production
The AI PM Masterclass covers agent design, production deployment, and the operational frameworks that separate demos from reliable shipped products. Taught live by a Salesforce Sr. Director PM.
Part 3: Human Escalation Protocol
An escalation protocol defines exactly when the agent should stop, hand off to a human, and what information it should provide in the handoff. Without a documented escalation protocol, agents either escalate too frequently (reducing automation value) or never escalate (creating liability when they should have stopped).
TEMPLATE: Part 3 — Escalation Protocol
Escalation triggers (the agent MUST escalate when any of these conditions are met)
Requested action exceeds authorization ceiling (e.g., refund amount above $500)
Customer explicitly requests to speak with a human
Policy or procedure ambiguity: the required action is not clearly covered by documented policy
Agent confidence score below threshold on a high-stakes action (define threshold per action class)
Third-party API returns an error on a write operation (do not retry silently on data-modifying calls)
Suspected fraud signal (unusual request pattern, mismatched customer identity indicators)
[Add organization-specific triggers]
Escalation destination
e.g., Route to Support Tier 2 queue. Assign to on-call agent per team rotation. Send Slack alert to #agent-escalations channel with ticket link.
Name the specific person, queue, or system the agent hands off to. 'Notify a human' is not an escalation protocol.
Handoff context the agent provides
e.g., Agent summary of the ticket, actions taken so far, specific reason for escalation, confidence level on the suggested resolution, and links to relevant policy sections.
The human receiving the handoff should need zero additional context-gathering to resolve the situation. Define this as a structured output format, not free text.
Agent behavior during escalation
e.g., Agent pauses all actions on the ticket. Sends customer an acknowledgment message using template CUST-ESC-01. Does not retry the failed action.
Define exactly what the agent does and does not do while it waits for human resolution. An agent that continues acting during an escalation is a common source of compounded errors.
Escalation SLA
e.g., Human must review and respond to escalation within 2 business hours. Agent re-escalates if no response received after 4 hours.
Escalations that sit in a queue indefinitely are failed escalations. Define the SLA and the re-escalation path if the SLA is missed.
Part 4: Success Metrics and Monitoring
An agent without a defined success condition cannot be improved. Define what healthy looks like before launch so the team can distinguish a well-functioning agent from a silently degrading one.
TEMPLATE: Part 4 — Metrics and Monitoring
Primary success metrics (define targets at launch)
| Metric | Definition | Target | Alert threshold |
|---|---|---|---|
| Autonomous completion rate | % of tasks the agent completes without escalation | e.g., >80% | e.g., <65% for 2 consecutive hours |
| Error rate (post-human review) | % of autonomous actions found incorrect in spot-check | e.g., <2% | e.g., >5% in weekly audit |
| Escalation accuracy | % of escalations that were correct to escalate | e.g., >90% | e.g., <75% (over-escalating) |
| Task completion latency (P95) | Time from trigger to completed or escalated state | e.g., <3 minutes P95 | e.g., >10 minutes P95 for 15 min |
| Customer satisfaction (post-agent interaction) | CSAT score on tickets handled by agent | e.g., >4.0 / 5 | e.g., <3.5 for 50+ responses |
Logging requirements
e.g., Log all tool calls with input, output, latency, and model version. Log all escalation events with trigger reason. Retain logs for 90 days. PII in logs is masked per data policy.
Without structured logs, post-incident investigation is guesswork. Define the schema before launch, not during the postmortem.
Monitoring owner and review cadence
e.g., Dashboard reviewed daily by [PM name]. Anomaly alerts page [on-call alias]. Weekly metric review with [team lead].
Monitoring that nobody looks at is not monitoring. Assign ownership and set a calendar for review.
Rollback procedure
e.g., To disable: set feature flag agent_enabled=false in config. In-flight tasks are routed to human queue. Rollback can be executed by any on-call engineer without PM approval.
The rollback procedure must be doable in under 5 minutes by an on-call engineer at 3am. Simplicity here is a safety property.
How to Use This Template in Practice
The runbook is a living document, not a one-time artifact. Here is the workflow that makes it useful:
Before writing the system prompt
Complete Part 1 (scope) and Part 2 (tools and permissions). The out-of-scope list and tool permission table should inform the system prompt directly: anything in the out-of-scope list belongs in the system prompt as an explicit restriction.
Before internal testing
Complete Part 3 (escalation protocol) and align with the engineering team on the infrastructure-level hard limits. These need to be implemented before the agent sees real data.
Before launch
Complete Part 4 (metrics and monitoring). Verify the dashboard exists, alerts are wired, and the rollback procedure has been tested. Conduct a tabletop exercise: walk through the failure scenarios in Section 1 of this template and verify the runbook handles each one.
After every significant incident
Update the runbook with the new escalation trigger or hard limit that would have prevented the incident. The runbook is only as useful as its most recent incident learnings.
On every model or tool update
Review and re-sign the runbook. Model behavior can change across versions. Tool API changes can alter what operations are available. The runbook owner signs off that the runbook still matches the agent after each update.
The test that tells you if the runbook is done
Hand the runbook to a new engineer who knows nothing about the agent. Ask them to answer: What is the agent allowed to do? What will trigger an escalation? What do I do if the agent is causing damage right now? If they cannot answer all three from the runbook alone, the runbook is not done.
Build AI Agents That Production Teams Trust
The AI PM Masterclass covers agent design, production readiness frameworks, and the operational patterns that separate shipped AI products from perpetual demos. Book a free strategy call to see how it fits your team.
Related Articles
Before you go: get the AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.