Autonomous Incident Response Works. Most Teams Are Skipping the Stages That Make It Safe.

At SREcon25 EMEA in October 2025, Solo.io’s Peter Jausovec walked the room through a before-and-after that looked too clean to be real: his team had taken incident response time from four hours to eight minutes using a set of specialized AI agents (USENIX, “From 4 Hours to 8 Minutes with AI Agents That Transform SRE Incident Response,” 2025). In March 2026, AWS announced general availability of its DevOps Agent; Western Governors University, an early customer, reported cutting a service disruption investigation from an estimated two hours to 28 minutes, a 77% improvement, after the agent surfaced the root cause in a Lambda configuration from documentation that had never surfaced through manual investigation.

Results like these are real. They are also carefully selected.

The NeuBird AI State of Production Reliability and AI Adoption report, published in April 2026 and drawn from a survey of 1,039 SRE, DevOps, and IT operations professionals, found that most engineering teams are spending 40% of their working time on incident management rather than product development. The Catchpoint SRE Report 2025 put the median time on operational activities at 30% of the engineering week, up from 25% the year before. Both figures are moving in the wrong direction, in the same period in which AI-assisted incident response has never been more capable or more accessible.

The organizations producing headline results and the organizations generating the toil statistics are not running different tools. They are running them in a different sequence.

The signal problem that precedes the AI problem

The NeuBird report surfaces a finding that explains the toil paradox more directly than any MTTR figure does. Forty-four percent of surveyed organizations experienced an outage in the past year directly linked to suppressed or ignored alerts. Seventy-eight percent experienced at least one incident where no alert fired at all, leaving engineers to discover failures only after customers were already affected. The median organization in the survey was managing incidents across four or more disconnected tools.

These are not AI failure modes. They are observability failure modes that exist before an AI agent ever enters the picture. An AI incident response system that ingests noisy, unreliable telemetry and correlates signals from four or more disconnected platforms will produce recommendations calibrated to that noise floor. When teams deploy autonomous remediation on top of a broken signal layer, they are automating the wrong response faster.

The organizations that produced headline MTTR reductions had already resolved the foundational work: coherent observability, well-curated alert signal, structured runbooks that defined what a remediation step was before any AI executed one. That work is not glamorous, it does not appear in vendor press releases, and it does not come bundled with the AI platform. It has to exist first.

Why stage-skipping produces the paradox

The intuitive adoption sequence for autonomous incident response is: evaluate platforms, pick one, configure the AI agent, turn it on. For a team that has already resolved signal quality and runbook definition, something like that sequence can work. For the majority of teams that have not, it produces a predictable failure mode.

Stage-skipping is deploying autonomous remediation before the AI’s recommendations have been validated through the earlier stages. The typical result is not catastrophic outages. It is a quieter and more persistent problem: the agent executes runbook steps that are subtly wrong for the current state of the infrastructure, the remediation resolves the surface symptom while leaving the underlying cause unaddressed, and the incident recurs. Because the agent ran a remediation, there is an audit entry showing the incident was handled. The recurrence looks like a new incident. Toil does not go down; it redistributes.

Silent advisor is the stage-two failure mode. Teams have deployed AI recommendations but treat them as low-priority notifications rather than time-sensitive inputs. The agent identifies the probable root cause and surfaces a suggested action. The on-call engineer reviews it twenty minutes later, after having already investigated the same cause through manual correlation. The AI-assisted workflow is slower than the manual one, and the team concludes the AI is not useful. The problem is not the AI; it is the workflow. Advised mode is only faster than manual if the recommendation arrives in a context where it will be acted on within the first few minutes of the incident.

Scope inflation is the stage-four failure mode. The autonomous scope expands through a series of individually reasonable extensions: add pod restart to the runbook, allow memory reallocation, permit configuration rollbacks in staging environments, then in production. No single change triggers a governance review, but the cumulative scope now covers decisions that should require human authorization. The agent is executing actions in regulated environments or against stateful services under an authorization model designed for a much narrower original scope.

The four maturity stages

The field has converged on a four-stage model for AI-assisted incident response, most recently articulated in the Rootly AI SRE Guide and in the AI SRE Summit that Komodor hosted for 2,000-plus SRE and platform engineering practitioners in May 2026. The stages are not primarily about capability; they are about calibration and governance. A team that deploys a highly capable AI agent in stage-one mode has not wasted the capability. They are building the track record that makes stage four safe to operate.

stateDiagram-v2
    direction LR
    state "Stage 1: Read-Only" as S1
    state "Stage 2: Advised" as S2
    state "Stage 3: Approved" as S3
    state "Stage 4: Autonomous" as S4

    [*] --> S1
    S1 --> S2 : Correlation ≥80% over 30d, runbooks complete
    S2 --> S3 : Acceptance ≥75% over 60d, FP rate below 5%
    S3 --> S4 : Approval ≥90% under 5 min over 60d, rollback verified
    S3 --> S2 : Accuracy breach or scope violation
    S4 --> S3 : Scope violation or accuracy regression

Stage 1, Read-Only. The agent ingests observability signals across logs, metrics, traces, and deployment events. It produces correlation summaries: a ranked list of probable root causes with supporting evidence, generated faster than any human can produce manually from four disconnected tools. The agent takes no action. Nothing changes in the production environment. Engineers use the correlation output as one input alongside their own investigation.

The purpose of this stage is measurement, not speed. You are calibrating whether the agent’s correlations match what engineers independently conclude the root cause was. That calibration data is the prerequisite for trusting recommendations in stage two. Teams that move to stage two before accumulating this record are advancing on vendor assurance, not on evidence from their own infrastructure.

The advancement criterion is confirmed correlation accuracy at 80% or above over 30 days of incidents, plus a completed runbook inventory for the failure classes the agent is targeting. Teams that advance without the runbook inventory have nothing for the agent to recommend.

Stage 2, Advised. The agent produces explicit recommended actions: restart this service, scale this resource, revert this configuration to the prior version. Engineers receive those recommendations as part of the incident workflow, not as a separate notification, and act on them or override them. The agent’s recommendation history is tracked: what it recommended, whether the engineer accepted it, whether the accepted action resolved the incident, and whether it produced secondary failures.

This stage exposes the silent-advisor failure mode in its full form. The recommendation must arrive at the right moment in the response workflow or it will not be acted on before the engineer has already reproduced the conclusion manually. Most stage-two implementations fail here not because the recommendations are wrong but because they arrive in a Slack channel nobody monitors during the first ten minutes of an incident.

The advancement criterion is a recommendation acceptance rate of 75% or above over 60 days, combined with a false-positive rate below 5%.

Stage 3, Approved. The agent recommends an action and the on-call engineer approves it with a single confirmation. The system executes the action. The distinction from stage two is that the human is not manually performing the remediation step; they are authorizing the agent to perform it. This matters for two reasons: it is faster when the step is complex to execute manually, and it is auditable in a way that stage-two is not, because every execution is logged as agent-initiated under explicit human authorization.

The rollback capability has to be verified before any approved-mode execution reaches production. The question “if this action makes things worse, what is the exact path to undo it?” is not one to answer during an incident. It is the gate that precedes approved-mode deployment.

The advancement criterion to stage four is an approval rate at or above 90%, median approval time under five minutes (if approvals routinely take longer than this, the process is not fit for autonomous execution), zero scope-violation incidents over 60 days, and documented verification that rollback mechanisms work for every action class currently in scope.

Stage 4, Autonomous. For well-defined failure classes with verified runbooks, confirmed accuracy track records, and tested rollback paths, the agent executes without per-action human authorization. Human oversight shifts from per-action to per-session: engineers review what the agent did, why, and whether it resolved the incident. Decisions outside the agent’s confidence threshold surface a human checkpoint rather than proceeding with the best available interpretation.

The scope of stage-four autonomy must be explicitly documented as a list, not as a policy statement. “The agent may take appropriate action on incidents” is not a scope definition. “The agent may execute these nineteen action types against these six service categories and may not access credential stores, modify CI/CD pipeline configuration, or invoke deployment pipelines” is.

What actually blocks the advance

Three constraints reliably prevent teams from advancing through the maturity stages, and none of them are resolved by upgrading the AI platform.

Telemetry debt means the observability infrastructure is inconsistent enough that the agent’s correlations cannot be meaningfully calibrated. Services are instrumented differently, log formats vary across teams, and the alert signal has been tuned over years for human review rather than machine correlation. Resolving this requires a deliberate observability investment before the AI platform produces return. Many teams underestimate this because observability debt is invisible until you try to build something that depends on it being coherent.

Runbook debt means incident response knowledge lives in engineers’ heads rather than in structured, executable procedures. The agent cannot recommend or execute what has not been defined. Turning unwritten practices into machine-executable runbooks is a knowledge management task, not a technology task, and it typically takes three to six months for a team that takes it seriously. Teams that skip this step either reach stage two with no actionable recommendations or reach stage three with runbooks too vague for safe automated execution.

The compliance constraint is specific to regulated industries. In healthcare, finance, and public sector contexts, autonomous modification of production systems without per-action human authorization often conflicts with change management and audit requirements. Stage three, with its explicit human authorization record per execution, is frequently the highest stage regulated organizations can reach without a formal regulatory review of the autonomous boundary. That review is not a technology decision.

The sequence is the strategy

The organizations generating headline MTTR results did not get there by deploying the most capable AI incident response platform. They got there by having the governance prerequisites in place before they added the AI layer: observability worth correlating against, runbooks worth executing, and a staged validation track record that told them the agent’s recommendations were reliable before they authorized autonomous execution.

Across the SRE and platform engineering teams we work with, the most common failure mode is not capability. It is sequence. A vendor demonstration shows stage-four results. The evaluation team configures stage-four deployment. The governance foundation that made the demonstration possible was never visible in the demo. It surfaces later, in incidents the agent handles incorrectly, in scope expansions nobody approved, and in operational toil that continues rising because the remediation layer is executing on top of unresolved signal noise.

The four-stage model is not a slow path to full automation. It is the path that produces automation reliable enough to actually reduce toil rather than redistribute it.

If you are evaluating AI incident response platforms, or if you have a deployment running and the toil reduction is not materializing, the maturity stage analysis is usually where the diagnosis lives. We have helped SRE and platform teams work through this sequence and are glad to compare notes.