Incidents, on-call and runbooks

An AI incident is any unplanned event that harms, or threatens to harm, the work the agent does: the classic outage, but also a model provider slowing down, drafts that are fluent and wrong, personal data leaking into telemetry, token spend running away, a tool used outside policy, or a model reaching end of life. Many of these throw no errors, so detection has to include quality checks, guardrail spikes, cost monitors and user reports, not only uptime. Every alert routes through the customer's incident tool (PagerDuty at Halden) to a named on-call responder via a schedule and escalation policy, with severity set by an agreed matrix and a runbook link in the payload. Runbooks list symptoms, triage queries and mitigations in order of risk: kill switch, rollback, model fallback, autonomy down, tenant off. Each mitigation is pre-approved so a stranger can pull it without a meeting. Afterwards, a blameless review produces actions, new monitors and new eval cases. Game days prove all of it before peak.

• Quality incidents are silent. Detect them with deterministic checks and user reports, not error rates.
• Severity is a business judgement written down in advance. If unsure, take the higher one.
• Mitigate first, diagnose second. The levers must exist and be pre-approved before go-live.
• Mitigations are changes. A fallback model can cause the next incident.
• Keep the evidence. You cannot reconstruct a model's output tomorrow; you can only replay what you recorded.