Operations & Incidents

What changes

Incident work has two halves: finding out what is wrong, and doing something about it. AI changes them in opposite directions.

Diagnosis is reading. An agent that ranks root-cause hypotheses or points at a suspect change has written nothing to production. If it is wrong, a human loses time on a bad lead. The best-measured results in this phase are all of this kind. Alibaba Cloud's BiAn cut the time operators took to find a network incident's root cause by 20.5% over ten months (SIGCOMM 2025, T2), and Google reports that its Incident Hypothesis tool cut mean time to mitigate (MTTM) by 10% in an A/B test (Google SRE, T3). In both, a human still decided and acted.

On independent benchmarks, though, agents rarely get root cause exactly right. Across eleven frontier models, OpenRCA 2.0 found the exact root-cause set recovered in 20.7% of 500 cases on average. The models found at least one correct root-cause service in 76.0%, but only 61.5% of those were grounded in a verified causal path. On ORCA-bench, whose ground truth was signed off by expert SREs, the best of five frontier agents reached 25.3% accuracy on medium tasks and 10.0% on hard ones, and the weakest model "hallucinates an implausible root cause in 40% of incident reports".

An output that is right a fifth of the time is still useful as a ranked list a human checks. It is not a basis for action.

Mitigation is writing to production. Elsewhere a change passes through a branch, a review and a pipeline before users see it. An ops action has no such stage: draining traffic, restarting a task or deleting a volume is the change, and whatever the agent's credentials reach, it can change at once. PocketOS lost its production database and backups to an agent working on a staging task. Replit's agent deleted a production database during a declared code freeze. In Amazon's Kiro case, the FT's account has the agent choosing to "delete and recreate the environment", Amazon blames "misconfigured access controls", and both accounts put access scope at the centre. In each, granted authority set a level nobody had chosen: the maturity model's Rule 2.

So the two halves climb at different speeds. Diagnosis can move up as fast as you can measure its accuracy. Action can move up only as far as its effects can be undone, and only inside a boundary the agent cannot widen.

The ladder for this phase

The criteria below are the same as the operations row of the maturity model's grid. This section adds what each cell means in practice and how thin the evidence behind it is.

L1 is where the measured value is. Meta's AI-assisted root-cause system ranks candidate code changes for an investigation. Backtested with only the information available when each investigation opened, "42% of these investigations had the root cause in the top five suggested code changes". The design choice matters more than the number: the system withholds low-confidence answers, trading coverage for precision, because AI "can potentially suggest wrong root causes and mislead engineers". Confidence gating is what makes an L1 tool safe in front of a tired on-call engineer.

L2 is defined by a closed set, not by approval alone. Approving whatever the agent typed is a weak control; the maturity model records Anthropic's figure, for its own product, that users approve 93% of permission prompts. Google's SRE walkthrough is the clearest published design of a better one (Google Cloud blog, 22 January 2026). It starts from a vocabulary, "a defined, closed, set of standard classes of mitigations (e.g., drain traffic, rollback, restart, add capacity)", and puts five layers around it. The agent "doesn't write random bash scripts; it selects from strictly typed tools (via Model Context Protocol)". Every tool definition carries metadata about its potential impact ("safe, reversible, destructive"). A policy layer checks the context ("No global restarts during peak traffic" or "Requires 2-person approval"). The CLI forces a confirmation step: "The agent proposes the mutation, but Ramón authorizes it." Every proposal and approval is logged.

L3 has one serious design and no outcome data. Google's SRE page describes an AI Operator that requires "a human SRE to review and accept the mitigation suggestion for critical operations" (its L2) and "will safely execute mitigations autonomously for minor incidents" (its L3). Google's numbering lines up with this book's here (see the crosswalk). What makes the design credible is the way down, covered under Guardrails. The page publishes no error rate or MTTM for the autonomous class, so it shows that L3 operations exists at Google, not that it beats L2.

L4 is empty except for failures. No organisation has published LLM auto-remediation for an enumerated alert class with a verification record. The three incidents in the cell are de facto L4: credentials allowed an irreversible action without per-item approval, whatever the team believed its level to be.

The case: Alibaba Cloud BiAn

Level: Operations, L1–L2. The system ranks suspect devices; operators decide and act.

BiAn is the best-measured operations result in the public record, and it is a diagnosis result. Alibaba Cloud built it to localise failures in its production network: an LLM pipeline ranks the devices most likely to be at fault, and operators investigate from that list. The paper, by authors from Nanjing University, Alibaba Cloud, NYU Shanghai and Peking University, was peer-reviewed at ACM SIGCOMM 2025.

The method sets it apart. Rather than counting incidents "handled", the team compared investigations done with BiAn against those "done fully manually", and added a variant of Microsoft's RCACopilot as a second comparison. On-call operators set up "two shadow operator roles to perform the root causing", one with BiAn and one with RCACopilot, with "operators of comparable expertise" assigned "at best effort". Time to root cause runs from the start of the investigation to identifying the root cause and the faulty device. The headline is that BiAn "has been deployed in our network infrastructure for 10 months … reducing time to root causing by 20.5% (55.2% for high-risk incidents)", with accuracy 9.2% above the baseline on 17 months of real cases.

One detail in the paper explains why diagnosis is where the gain sits. Once the root cause and device are known, mitigation takes "a relatively fixed duration (around 2 minutes)". In that network, nearly all the time from alarm to recovery goes on working out what is wrong. Faster diagnosis shortens the incident; automating the two-minute mitigation would save little and add the risk of acting on a wrong diagnosis. That is one system's ratio, not a law, but it is the question to ask of your own incidents before automating their last step.

What it does not show. That an agent can be trusted to act, because none did. That it transfers to application incidents, where root causes include deploys, configuration and feature flags. Or a controlled result: operators were matched "at best effort", and the authors concede that "absolute fairness is hard to achieve".

The counterweight. Independent work shows why a human still has to check the list. The Waterloo group's FORGE 2026 study (T1) ran six open models over 48,000 fault scenarios and found the most common reasoning failures were fabricated evidence and evidential insufficiency. Performance fell to "sub-guessing" levels as agentic workflows grew more complex, especially for the smaller models. A separate run of 1,675 agent sessions on OpenRCA found hallucinated data interpretation and incomplete exploration "across all models", and found that prompt engineering alone did not fix them (Kim et al., T1). One vendor, Traversal, argues that some OpenRCA labels are not recoverable from the telemetry, so the benchmarks understate real performance. That is a fair point about one benchmark, made by a company selling an AI SRE product, and it does not touch ORCA-bench's expert-signed ground truth.

Google's A/B figure belongs beside BiAn. Google writes that its scale "provides the statistical rigor necessary to A/B test SRE practices like Incident Hypothesis", and that "informational assistance alone delivered a 10% reduction in Mean Time to Mitigate (MTTM)". It is the only A/B-tested MTTM result in this book's evidence base. The same page reports "a roughly 44% reduction in Mean Time to Mitigate (MTTM) for supported incidents" from its Investigation Dashboards, with no method, over a selected subset.

The product claims in this phase are vendor-reported, and none publishes a method.

The comparison to carry forward is between self-reports and benchmarks, not between vendors. Products reporting MTTR halved sit beside independent agents that find the exact root cause a fifth of the time. Both can be true if the vendors count narrow, repetitive incident classes, which is why a figure must name its incident class before it can be used. Read these numbers by the rules in the economics chapter: direction, not magnitude.

Migration steps

Each climb below is for one named incident class or task type, recorded as the maturity model's Rule 3 asks: "Operations: L2 for capacity incidents on stateless services; L1 for everything else", not "Operations: L2".

L0 → L1: measure diagnosis before you trust it.

1. Give the tool read-only access to telemetry, runbooks, recent changes and past postmortems. Nothing it holds should be able to write.
2. Backtest before going live, as Meta did: replay closed incidents with only the information available when each one opened, and record how often the real root cause is in the top one, three or five.
3. Gate on confidence. Decide the threshold below which the tool says nothing, and accept the lower coverage.
4. Run a shadow comparison, as Alibaba did: for a period, one responder works with the tool and one without (or with the current tool), and you compare time to root cause by incident class.

A low-risk place to start is learning from incidents rather than responding to them. Zalando has used LLMs to analyse its postmortems for two years (Zalando Engineering, September 2025). Early small models showed "up to 40% probability for hallucination at summary and analysis phases", so humans curated every summary "until the effect of hallucination became less than 15%", then moved to "10-20% of randomly sampled summaries". An insight from the work led to a validation check that "is able to shield us from 25% subsequent datastore incidents". Zalando is equally plain that "Reliable accuracy in extracting numerical data … from postmortems was not achieved." That is the climb in miniature: measured error, a threshold, then sampled review, and an honest note of what the model could not do.

L1 → L2: write the catalogue before the agent proposes anything.

1. Enumerate the mitigation classes you already use by hand. Google's list (drain, rollback, restart, add capacity) is a starting point; yours comes from your own runbooks.
2. Expose each as a typed tool with a risk tag and an undo path. Anything without an undo path is either not exposed or tagged destructive.
3. Put a policy layer in front of the tools that knows context: time of day, traffic level, how many instances an action touches, and whether two people must approve.
4. Force a human confirmation on every action and log what was proposed, approved and executed.
5. Run the agent under its own identity. Google's page is blunt: "Agent identities must be distinct from human users". If an agent borrows the on-call engineer's credentials, it inherits everything that engineer can do.

The worked example below shows what such a catalogue looks like. It is the book's proposal, built from the five layers in Google's walkthrough; the entries and limits are illustrative, not drawn from any organisation.

Illustrative mitigation catalogue (the book's proposal; no organisation).
Built from the five layers in Google's SRE walkthrough.

tool               risk tag      undo path         max level  policy
drain_traffic      reversible    undrain           L3         one cell at a time
restart_task       reversible    none needed       L3         rate-limited per task
add_capacity       reversible    remove_capacity   L3         quota cap per incident
rollback_release   reversible*   roll forward      L2         *check intervening changes
change_config      reversible    revert_config     L2         2-person approval
delete_volume      destructive   none              never      not exposed to the agent

Every call: typed tool only; logged as proposed / approved / executed;
runs under the agent's own identity, scoped to one environment.
Downgrade L3 -> L2 on: elevated risk score, anomalous production state,
any policy denial, or a health signal moving the wrong way after the action.

Two choices deserve a word. Rollback sits at L2 because Google warns that "a simple binary rollback to a 'last known good' version becomes highly risky" when other fixes have landed since: reversible in principle, destructive if it undoes someone else's repair. And the destructive tool is not in the agent's vocabulary at all. An agent cannot misuse a tool it was never given, a stronger guarantee than any approval prompt.

L2 → L3: one minor incident class, with the way down built first.

1. Pick one class whose mitigations are in the catalogue at L3 and whose incidents are minor by your own severity scale. Google draws the same line: autonomous "for minor incidents", human-approved "for critical operations".
2. Build the downgrade before the upgrade: machine-enforced conditions under which an L3 request falls back to L2 and pages a human.
3. Build a stop control that pauses every in-flight agent action and revokes L3 at once, and exercise it in a game day.
4. Add agent-specific rate limits and circuit breakers, so a confused agent cannot restart the fleet one task at a time.
5. Meet the maturity model's L3 criteria, including a comparison of agent-mitigated incidents against a human baseline over at least 90 days. Google has not published one; you will be producing evidence nobody else has.

L3 → L4: there is no public path. If you attempt it, the L4 criteria apply in full: one enumerated, reversible alert class, a verification record, continuous monitoring with a kill switch, and a named person who has signed the risk acceptance. For most teams, L3 for a narrow class is the ceiling, and a sensible one.

Guardrails

The guardrail that matters most in operations is not about the model. It is the set of credentials the agent can use, and every incident on record shows what happens when that set is wider than the task.

PocketOS: a staging task, a production token. In April 2026 a Cursor agent "reportedly running Anthropic's Claude Opus 4.6 deleted PocketOS's production database and volume-level backups through Railway while working on a staging-environment task", using "a broadly scoped API token" (AI Incident Database). The OECD's incident monitor records it as nine seconds and an outage of about 30 hours. Secondary coverage, not confirmed at a primary, adds the mechanism: the token had been created for custom-domain management and was found in an unrelated file, the backups lived on the volume they protected, and Railway afterwards moved API deletes to a 48-hour soft delete. Every fact that made it a disaster was environmental: a credential that reached production, an API with no undo, and backups inside the blast radius.

The two other incidents in the L4 cell point at the same fix. After Replit's agent deleted a production database during a code freeze, Replit separated development and production databases; its documentation now says the agent "can't touch" production (Replit Docs, as of October 2026). After the Kiro incident, Amazon, which disputes the FT's account of the cause and duration, added "mandatory peer review for production access" (Amazon, 20 February 2026). The case studies tell Replit and Kiro in full, with Kiro's two accounts side by side. Neither company's fix was a better model. Each changed what could reach production.

From those incidents and Google's design, five guardrails follow, each from the level named and upward.

• Environment-scoped agent identity (L1 up). The agent has its own identity, and for a task in one environment it holds credentials for that environment only. "AI agents are not granted full production access from day one," Google's page says. Audit credentials in files and environment variables the agent can read, not only those you issued to it. In the secondary accounts of PocketOS, the token was found, not issued.
• Backups outside the blast radius (before L2). Nothing the agent can delete should be able to delete the copy you would restore from.
• Irreversible means ineligible (L2 up). An action without an undo path stays out of the agent's catalogue or behind two-person approval. The maturity model's risk ceiling already rules out L4 wherever an action is irreversible; in operations, apply that test tool by tool.
• Automatic downgrade and a stop control (L3). Google's are the template. "If an agent requests an L3 (High Automation) execution, but the agent detects an elevated risk score or an anomalous production state, it will automatically downgrade the request to L2 (Partial Automation), intercepting the execution and routing an approval request to a human SRE." And: "emergency 'Red Button' endpoints that allow SREs to instantly pause all in-flight agentic actions, block new actions, or globally revoke L3 permissions across the fleet". Chapter 17, Measuring Success and When to Roll Back, returns to this as the model of a pre-wired level downgrade.
• Rate limits and circuit breakers (L3). "Systems must implement strict, agent-specific rate limits and automated circuit breakers." A wrong action repeated quickly is a bigger incident than the one being mitigated.

Operations also inherits the toolchain risks covered in CI/CD & Release: an agent that reads text written by others while holding a privileged token is an exfiltration path, and alert payloads, tickets and logs are text written by others. The full permission envelope per level, with the incidents behind each row, is in Security, Permissions & Blast Radius. The wiki covers the mechanics in human-in-the-loop, kill switches, undo and reversibility and DevOps and SRE agents, and argues the authority point at length in agent CVEs are authorization bugs.

Metrics

Most published numbers about AI in operations are counts: incidents handled, investigations run, hours saved. None can tell you whether a climb worked. Use the measures the credible cases used, and pair each speed measure with one that would catch the agent making things worse.

• MTTM per incident class, against a baseline. Google's A/B design is the template. If you cannot randomise, use a before-and-after window per class and say so. Never report one blended MTTM across classes: an agent that clears many easy incidents fast can lower the average while the hard ones get no better.
• Time to root cause against a shadow comparison, as BiAn measured it, with the start and end points defined.
• Top-k accuracy by backtest, as Meta measured it, re-run whenever the model or the prompt changes.
• Fabricated-evidence rate, by sampling. Take a random sample of the agent's incident write-ups and check every cited log line, metric and change against the source. FORGE found fabricated evidence the most common failure. Zalando's 15% threshold for moving from full to sampled curation shows how to turn the rate into a decision.
• The paired stability measure: incidents caused or worsened by agent actions. Count mitigations that were reverted, that preceded a further degradation, or that a human overrode. No vendor in the box above publishes it.
• Downgrade and stop-control events. How often L3 requests fell back to L2, and why. A rising rate means the risk model is seeing something; a rate of zero for months may mean it is not looking.

Do not use "incidents handled autonomously" or hours saved as success criteria. They measure volume, not outcome, and the one public series of hours saved jumped from over 20,000 to 50,000+ within a month, unexplained. Outage statistics need the same care: the wiki's analysis of why one in ten outages is not about agents shows how an industry-wide incident share gets misread as evidence about agents. For how error budgets can bound an agent's actions, see SLOs and error budgets.

Anti-patterns

• A broad token for a narrow task. PocketOS's agent was working on staging; its credential reached production.
• An instruction used as a boundary. Replit's code freeze was declared in conversation. A freeze the agent's credentials can ignore is a request, not a control.
• Acting on a confident root cause. An agent that diagnoses and mitigates with no human or deterministic check between the two steps turns a wrong guess, which ORCA-bench and FORGE say is common, into a production change.
• Tuning prompts to fix diagnosis. Kim et al. found prompt engineering alone did not fix the dominant RCA failures, while a richer inter-agent protocol cut communication failures by up to 15 percentage points. Fix what the agent can see, and keep a human on the result.
• Treating rollback as always safe. A rollback that removes an intervening fix is a new incident.
• Autonomy with no way down. An L3 without an automatic downgrade and a tested stop control is an L4 with less paperwork.
• Reporting volume as the outcome. "Thousands of incidents handled" says nothing about how many were made worse.

When the agent itself is the incident, the wiki's incident response for agents covers the response.