The On-Call Runbook for AI-Native Teams

Traditional on-call is built around a clean assumption: the system doesn't have opinions. Code executes deterministically, and when something goes wrong, it's because a dependency failed, a resource ran out, or a human shipped a bug. The runbook reflects that assumption end to end — check the dashboards, find the failing component, roll back or scale up, done. Every piece of this series so far has been circling the same underlying fact: that assumption doesn't hold for agents, and an on-call rotation built entirely on top of it will handle an agent incident badly, not because the responders are unskilled, but because the runbook is answering a question the incident isn't actually asking.

An agent incident's first question usually isn't "what broke." It's "what did the agent decide, and should it have been allowed to decide that alone." That's a judgment question, not a diagnostic one, and it means the on-call runbook for a team running agents in production has to be built differently — not by throwing out everything that works about traditional on-call, but by adding a layer specifically built for systems that reason rather than just execute.

Start from what doesn't change

It's worth being explicit about what still applies, because the temptation when something feels genuinely new is to reinvent everything, including the parts that were already working. Clear escalation paths still matter. A defined severity taxonomy still matters, even if the criteria inside it shift — see the discussion of severity classification in the five-step incident-response playbook, where reversibility and blast radius replace pure volume as the primary axis. Postmortems without blame still matter, arguably more, because agent incidents are frequently the result of an accumulation of individually reasonable decisions rather than one obvious mistake, and a blameful postmortem culture will chase the wrong target — the specific person who tuned a prompt, rather than the system that let a single prompt change ship without the review a policy change deserves.

What doesn't carry over cleanly is the assumption that detection is obvious, that root cause is a stack trace away, and that containment means rolling back a deploy. Those assumptions need replacing with agent-specific equivalents, and the runbook needs to say so explicitly rather than leaving responders to discover the gap live, during an actual incident.

The dashboard an agent on-call rotation actually needs

A service on-call dashboard centers on latency, error rate, and saturation. An agent on-call dashboard needs those too, for the infrastructure the agent runs on, but it also needs the metrics that have no service-monitoring analogue at all: hallucination rate, broken down by task category rather than aggregated into one falsely reassuring number; policy-violation rate and near-miss frequency, showing how often the guardrail is actually being tested rather than sitting unused; escalation frequency, tracking how often the agent is routing decisions to a human versus handling them alone, and whether that ratio is drifting; and cost per request type, because on shared infrastructure a cost anomaly can become everyone's outage just as fast as a behavioral one.

None of these metrics exist by default. They have to be built deliberately, before the rotation needs them, which means the on-call runbook and the observability build-out aren't two separate projects — the runbook is only as good as the instrumentation underneath it, and a rotation handed a runbook with no working dashboard behind it is being handed a checklist for tools that don't exist yet.

Who's actually on call, and for what

A subtlety that trips up teams standardizing this for the first time: the person on-call for an agent incident needs a different mix of skills than the person on-call for a service outage, and it's worth being honest that one person may not have both. Diagnosing a stuck deploy or a saturated connection pool is a systems-engineering skill. Assessing whether an agent's reasoning went wrong — whether a prompt change shifted its interpretation of ambiguous cases, whether a policy version was too permissive for a scenario nobody anticipated — leans more on understanding the product and policy intent behind the agent than on infrastructure debugging.

The rotations that handle this well tend to pair the two rather than expect one person to be fluent in both: an infrastructure-facing on-call for the parts of an agent incident that look like a normal outage — the tool endpoint is down, the model API is timing out — and a policy-and-product-facing escalation path for the parts that look like a judgment failure — the agent did something technically successful but substantively wrong. Knowing which one to reach for, fast, is itself something the runbook needs to make explicit, because guessing wrong burns exactly the minutes that containment depends on moving quickly.

Pre-authorized levers, not live negotiations

The single biggest predictor of whether an agent incident stays contained or turns into a story people tell for years is whether the person who first notices it has pre-authorized levers to pull immediately, or has to negotiate authority in the moment. This shows up repeatedly across this series because it's the same failure pattern wearing different clothes: a kill switch with no defined owner isn't a kill switch; a guardrail that requires a committee to tighten mid-incident is a guardrail that tightens too late; a rollback that depends on someone remembering what the previous policy was, because it wasn't version-controlled, is a rollback that doesn't reliably happen at all.

An AI-native on-call runbook needs to list these levers explicitly, with the authority to use them granted in advance: who can pause an agent entirely, who can tighten a specific guardrail without a review cycle during an active incident, who can roll a policy back to a known-good version, and what the default action is if nobody with that authority is immediately reachable. That last part matters more than it seems — a runbook that assumes the right person is always available within minutes is a runbook that fails exactly when it's tested hardest, at 2am, on a weekend, during the one incident nobody staffed for.

What the postmortem needs to produce

A service postmortem typically ends with a technical fix — a config change, a new alert, a code review process for a class of bug. An agent postmortem needs to end with something broader, because the root cause is rarely a single line to point to. It typically ends with some combination of: a tightened or newly added guardrail, informed by what the audit trail showed about what the agent actually had access to and reasoned through; an adjustment to the blast-radius gates that either failed to cap the damage or weren't there for the specific action type involved; and, where the incident touched anything regulated, an honest, documented assessment of whether the incident needs to be disclosed — not deferred as an afterthought, but treated as a required output of the process, the same way a fix is.

Building the rotation before the agent needs it

Every piece of this — the dashboard, the pre-authorized levers, the paired skill sets, the postmortem template — is far easier to build calmly, in advance, than to improvise during the first real incident. That's true of on-call generally, but it's more true here, because the shape of an agent failure is less familiar to most responders than a service failure, and unfamiliarity under pressure is exactly when good judgment erodes fastest. The teams shipping agents into production well aren't the ones with the most sophisticated models. They're the ones who wrote this runbook — deliberately, with real thresholds and real named owners — before the night they needed it, rather than during it.

Part of the "Running Agents in Production" series on aiskill.market.