Picture a service pegged at 98% CPU at 2am. There's a runbook called Restart Service, and an AI agent has it loaded and ready to execute in seconds. The obvious move is to run it. Microsoft solution architect Kaustubha Shravan used exactly this scenario to open a session on AI SRE remediation, and her point lands hard: the CPU spike might be caused by a sudden traffic surge, and restarting the service in that case makes things worse, not better (StackGen). A valid runbook, executed by an agent that doesn't understand the surrounding context, can still cause an outage.
That's the uncomfortable truth for anyone writing incident runbooks that assume an AI system — or an AI agent responding to an AI system's failure — is going to behave like deterministic automation. It won't. Traditional automation had one job: alert fires, pre-approved action runs. AI incidents don't work that way, and runbooks written as if they do will eventually fire the wrong fix with full confidence.
The runbook's job is to slow the agent down, not speed it up
The instinct when something breaks at 2am is to write a runbook that lets automation move faster: detect, match, execute. For AI outages specifically — a model provider degrading, a fallback chain misfiring, a service silently returning garbage instead of an error — that instinct is backwards. What you actually need is a runbook that forces a pause for context before action, because the same symptom (elevated latency, elevated error rate, a spike in retries) can have opposite correct responses depending on what's driving it.
This isn't an argument against automating AI incident response. It's an argument against writing runbooks as flat decision trees — "if X, then restart" — without wiring in the context an agent (human or otherwise) needs to tell a traffic surge apart from a genuine failure. The practitioner literature on this is still thin, but the direction is clear enough: curated lists of AI SRE tooling are now built specifically around investigation and root-cause analysis before remediation, not remediation alone (GitHub).
Not every AI-dependent service deserves the same response tier
A second mistake teams make is writing one runbook for "the model is down" as if every AI-dependent feature in their product has the same blast radius. It doesn't. Datadog's engineering team has written about treating services uniformly in deployment and reliability decisions as something that becomes expensive at scale — applying one SLO target across services over-invests in some and under-protects others (Datadog). The same logic applies to AI outages. A model failure behind a customer-facing chat feature and a model failure behind an internal classification job are not the same incident, and a runbook that treats them identically will either over-page your on-call or under-react to the thing that actually matters.
Practically, that means your AI incident runbooks need a criticality tier baked in before the "what to do" steps — which model calls are load-bearing for revenue or trust, which are nice-to-have, and which can silently degrade to a cached or rule-based fallback without anyone needing to wake up. Writing that tiering down explicitly, rather than trusting whoever's on call to improvise it at 2am, is the actual runbook work. The restart-the-service script is the easy part.
A runbook without telemetry wired in is just a guess with extra steps
None of the context-gathering above works without the instrumentation to answer it quickly. Honeycomb's framing of what "resilience" requires — real-time telemetry, anomaly detection, and root-cause analysis that integrates with the tools teams already use for response like PagerDuty, Slack, and Jira — is really a description of what a usable AI runbook depends on (Honeycomb). If your runbook says "check whether the error spike correlates with a traffic surge," someone has to be able to answer that in under a minute, not by grepping dashboards. The teams that are making progress with AI in production right now are, by Honeycomb's own account from its recent London event, the ones who can actually see what's happening rather than the ones who've automated the most steps (Honeycomb).
The pattern across all of this: a good AI incident runbook isn't a longer script. It's a shorter decision at the top — what tier is this, what else is happening right now — followed by the steps you already know how to run. Write that decision point down explicitly, test it against a false-alarm scenario before you ship it, and revisit it the next time a "valid" runbook makes an incident worse instead of better.