Most teams already use AI somewhere in on-call work. Used well, it makes engineers better at incident response, provided its limits match the risk of each action. Below is how we recommend setting those limits.
Five levels of autonomy
We use five levels of AI autonomy (how much the AI may decide and do without a person), applied across the work of an incident: watching, investigating, approving a plan and carrying it out.
| Level | What the AI does | What people do |
|---|---|---|
| L0 Manual | Monitors only | Investigate, decide and act |
| L1 Assisted | Monitors, investigates and offers hypotheses (possible explanations) | Approve and carry out every action |
| L2 Partial | Can carry out an action once a person approves the plan | Approve each plan |
| L3 High | Approves and acts alone within set limits for well-understood scenarios | Get notified, and handle anything new |
| L4 Full | Plans, acts, checks the result and closes the incident end to end | Oversee the system as a whole |
Before a system moves up a level, we want to see four things in place: good test coverage, a working way to roll back (undo a change), error budgets (the amount of failure a reliability target allows) and a track record at the current level. Not every system should reach L4: where the risk of a wrong action outweighs the time saved, a well-run lower level can be the better choice.
How far a mature agent goes today
Google has published how its first-responder agent for alerts, AI Operator, works. It forms and tests hypotheses, then picks from a fixed catalogue of mitigations (actions that reduce the harm to users, such as draining traffic away from a failing cluster). It works at L1 for all alerts and at L2 for actions such as drains and rollbacks, where it shows the exact commands and its reasoning for a person to approve. It acts alone, at L3, only for narrow low-risk actions such as restarting a single misbehaving task or clearing a known cache, and only after careful evaluation. Full autonomy at L4 is described as a long-term aim that depends on advances in reasoning, risk assessment and provable safety.
An organisation with years of SRE (site reliability engineering) practice behind it keeps its own agent mostly at the assisted and human-approved levels, which suggests a sensible starting point for a startup. Our recommendation is to introduce AI through detection and triage first (deciding how serious an alert is), where the main risk is escalating too readily rather than doing harm. The same ladder applies to ordinary automation. When a monitoring fault fires every alert at once, automation that acts on each alert by itself can make things worse, while a person can see that the alerts themselves are wrong.
The controls to put in place first
Safety controls come before any automatic fixing, because AI can’t simply be added on top of existing processes.
- Least privilege and a read-only start. The AI gets only the access it needs, and begins by reading telemetry (metrics, logs and traces). It moves on to proposing actions, and later to acting on low-risk tasks, only once its record justifies it.
- Evidence and confidence with every finding. The agent should show the signals it used, its reasoning and how confident it is, so the engineer can check its work.
- Hide low-confidence suggestions. Below a set confidence level, we recommend that a mitigation isn’t shown to the on-call engineer at all, so a weak guess never looks like advice.
- Only reversible actions. The agent should not take an action unless it knows how to undo it. We treat the action, a check that it worked and an automatic rollback as one unit.
- Check the context before acting. Every action gets a live check against deploy freezes, active incidents, the state of the error budget and traffic peaks.
- An emergency stop. Even a mature agent needs a way to block its production access immediately. Engineers work with an agent more confidently when they know they can stop it quickly.
Separate fast mitigation from deeper investigation
We treat incident work as two jobs. Mitigation is choosing from a small, known set of actions (roll back, drain, add capacity) where speed matters more than full understanding, and the AI’s job is to present an option with a confidence figure for a person to judge. Investigating the likely cause is slower, hypothesis-driven work based on monitoring data, the map of how services depend on each other and recent changes. Keeping them apart lets a team stop the harm quickly while the investigation continues, with the AI’s actions limited to a list people have already reviewed.
The risks to plan for
These risks are why the controls above exist.
- Small error rates spread. A person who makes a mistake usually notices after one or two attempts, but an AI can repeat the same mistake across every system it touches. Even a 1% error rate can do serious damage at production scale.
- Unfamiliar failures. Language models can hallucinate (give confident but wrong answers), especially in complex situations, and do least well on failures unlike anything they have seen before. Those rare failures are where SRE work matters most.
- Fading skills. If a tool that is right most of the time handles the easy incidents, engineers lose the practice the easy ones gave them and meet the hard ones less prepared. Regular practice drills are how we recommend keeping those skills sharp.
- Someone has to answer for it. When a public outage happens, customers and regulators expect a person who can explain what happened and why.
Why “hours saved” is the wrong measure
Valuing AI by the toil (repetitive manual work) it removes undersells it. If toil is a quarter of an engineer’s time, handling that toil five times faster still gives only a modest overall gain (toil falls from 25% of their time to 5%). The bigger value is in things a team could not do before, such as reviewing designs for risk ahead of time, or scanning every service for a pattern found in one incident. A better question for any AI tool is what it lets your team see or do that it couldn’t before, and how often its suggestions turn out to be right.
How we apply this
Our AI investigates every alert through a read-only identity scoped to telemetry and configuration, and shows the evidence behind its likely cause, along with how confident we are when we hand over to your team. An engineer checks that likely cause before anything happens, and a runbook (a step-by-step fix) runs only for a known issue you’ve approved it for. One action in Slack or the portal pauses every runbook we can run. Details are on how it works.