AI Incident Response That Closes the Loop Back to Planning

Most AI-SRE and agentic-incident-response writing treats an incident as something that ends when it's fixed — a metric returns to baseline, the page gets acknowledged, everyone moves on. In an AI-native lifecycle, that definition is incomplete. An incident that doesn't re-enter planning is a fix that will happen again, because whatever produced the original gap in intent, spec, plan, or review wasn't addressed — only its symptom was.

Deterministic signals — a rolling-baseline metric breach, a repeated CI failure, an anomalous 5xx rate — trigger a bounded, stateless diagnosis. The detector is versioned and predictable; the agent is invoked only once a defined threshold is actually crossed, and confidence gates decide whether the result advances, needs more evidence, or escalates to a human.

Results return through the same intent, review, and release path as any other governed change — never as a direct production edit. That's the difference between an AI on-call assistant and an autonomous incident commander: the assistant gathers evidence, tests hypotheses, and drafts a proposed fix or a pre-approved rollback; a human declares severity, communicates externally, and authorizes production action. This division of labor holds regardless of whether the underlying models are run through OpenAI's platform APIs or another provider — it's an authority boundary, not a model capability question.

Everything above applies to production incidents generally, but AI-assisted systems add a category of failure a conventional runbook doesn't cover well: a degradation in judgment quality rather than an outage. A support-triage agent that starts routing a growing share of tickets to the wrong queue isn't throwing errors or breaching a latency SLO — the system is technically “up,” and a conventional uptime-based control band would never fire.

This is why the metric chosen for the detector matters as much as the tiering logic around it. For AI-assisted stages, that metric needs to be something that reflects output quality or policy adherence — a routing-accuracy rate, a policy-violation rate from the Test-stage eval suite run continuously in production, a rate of escalations to a human — not just the infrastructure metrics a conventional SRE practice already tracks. Both matter; only one of them is usually already instrumented.

An `UNKNOWN` observation stays `UNKNOWN` — it is never quietly reclassified as healthy just because the diagnosis was inconclusive. This single rule is what prevents an under-confident agent from accidentally clearing an incident that isn't actually resolved, simply because it ran out of permitted tools to investigate further. An inconclusive result always alerts a human; it never defaults to “probably fine.”

Compare that to a second, quieter incident the same week: a routing-accuracy eval running continuously in production notices the support-triage agent's misroute rate has drifted up gradually over ten days — no sudden breach, just a slow climb past the medium tier's baseline band. The bounded diagnosis correlates the drift to a knowledge-base update three weeks earlier that introduced ambiguous category names. No code changed, no deploy caused it, and a conventional uptime-focused monitoring stack would never have flagged it. The proposed fix is a knowledge-base correction, not a code rollback — the incident still enters the same intent-and-review loop, just with a different kind of fix at the end of it.

A rolling-baseline detector flags a 3-sigma breach in post-deploy 5xx rate within the window of a recent release. The medium tier kicks in: a bounded, read-only diagnosis correlates the breach to the specific deploy, reads the relevant logs, and finds a null-pointer pattern tied to one new code path. It proposes a rollback via the pre-approved runbook and opens a pull request with the diagnosis attached — it does not execute the rollback itself. An on-call engineer reviews the evidence, authorizes the rollback, and the confirmed failure class becomes a permanent regression test the same day, so the next release can't reintroduce it silently.

Letting the on-call agent mark its own work resolved. Confidence that a fix worked has to come from an authorized, independent measurement — the same metric that flagged the breach returning to baseline, confirmed by someone with authority to declare the incident closed. An agent reporting “I believe this is fixed” is not the same evidence as the metric actually recovering.

Skipping the regression case once things look calm again. Under the relief of a resolved incident, it's tempting to close the ticket and move on. The fix isn't actually durable until the failure class has a permanent test or eval guarding against it — otherwise the same root cause can reappear in a slightly different form next quarter, and nobody will connect it back to this incident.

Setting control bands so sensitively they page for noise. A detector tuned to fire on any deviation, however small, trains the team to ignore its alerts — the opposite of what a control band is for. Tune tiers from a genuine rolling baseline and real incident history, and treat an early wave of false positives as a signal to widen the band, not a reason to remove it entirely.

This is the final stage in the series, and the word “closing the loop” is meant literally, not just as a metaphor: a systemic incident becomes a new intent record, which re-enters the Plan stage this series opened with. The six stages aren't a one-way pipeline that ends at Maintain — they're a cycle, and the measure of whether an engineering organization has actually adopted this model isn't whether each stage exists in isolation, it's whether a real production incident can be traced all the way back through to a specific, accepted intent that started the chain.