Chapter 5.6 — Incident response and runbooks¶

🎯 Objective¶

Ensure that when an AI incident happens — and it will — there is a known path for diagnosis, mitigation, communication and postmortem. Without a runbook, every incident becomes improvisation under stress.

🧠 Runbook components¶

When to trigger. Signals that fire (alerts, complaints, a metric breaching the SLO).
Initial diagnosis. Which dashboards to open, which queries to run, which traces to look for. Ideally, direct links.
Mitigation actions. Rollback (model, prompt, tool, policy); kill switch (disable an agent or tool); fallback (alternative route); provider failover.
Communication. Who to notify, in which channel, with which initial message.
Postmortem. Format (blameless), deadline (usually 5 business days), mandatory items (timeline, impact, cause, countermeasures, prevention actions).

🧰 Typical scenarios with their own playbook¶

High fallback rate in a support agent.
A sudden cost increase (loop, large prompt, retries).
Cross-tenant leakage detected.
Indirect prompt injection with an observed effect.
The provider's model degraded after their release.
An external tool is down during peak hours.
Indexing lag above the SLA with critical documents outdated.

🧠 The difference between an incident, a bug and a behavior change¶

In AI, a behavior change after a new model, prompt or index version is not a bug, but it can cause an incident. Treating every deviation as a bug leads to useless regressions. Treating every deviation as "that's just how it is" leads to silent degradation. The operational difference: a regression is measurable against eval; a change without regression is a product decision.

EX-OPS-01 — an incident runbook for "high fallback rate in a support agent".

🏢 Hermes Logística — wave 5¶

On a Thursday, Hermes's weekly LLM bill jumped 4x. The per-tenant cost alert fired, and the trace showed a single agent in a loop: the internal search tool returned "truncated result", the agent retried with a larger prompt, hit the limit, retried again. The immediate fix: a per-agent circuit breaker + reduced max_steps. The structural fix: a per-agent budget as a contract, not a suggestion. The incident ended in a permanent runbook; the agent eval gained a regression case for "tool with a truncated result". The lesson: observability is only worth it if there is a trigger and a runbook.