# What AI SRE observes, infers, and is allowed to do

URL: https://rootly.com/ai-sre-guide/concepts
Pillar: AI SRE
Bundle: https://rootly.com/llms/ai-sre.txt

> When an incident gets messy, AI SRE has to do more than sound convincing. I examine the principles that keep its evidence inspectable, its hypotheses testable, and its production actions constrained.

An alert fires, three services look guilty, and the on-call engineer starts opening tabs. The evidence is spread across telemetry, deploys, service ownership records, runbooks, tickets, and the incident channel. As a solutions engineer, I see teams lose critical minutes simply assembling that picture.

[AI SRE](https://rootly.com/ai-sre-guide) applies machine learning and large language models to reliability workflows so teams can gather evidence, test likely explanations, and take safer action while engineers remain accountable. That is a narrower and more useful promise than the autonomous-operations claims I often hear.

The question I care about is, “Can this system help an SRE understand what is happening without hiding uncertainty or weakening control?”

Consider a composite incident. Checkout latency rises a few minutes after an ordinary-looking deploy. The checkout service alerts, but so do payments, inventory, and a shared database. Three dashboards show different symptoms. Nobody yet knows whether the deploy is causal, whether a dependency is degraded, or whether the timing is coincidence.

A summary is useful, but it is only one part of the job. A capable AI SRE should retrieve evidence, expose relevant dependencies and changes, develop testable hypotheses, recommend next steps, and operate within production controls. Together, those capabilities should help the responder answer six operational questions:

| Incident question | The concept behind it |
| --- | --- |
| What changed, and what is affected? | Time-to-context |
| What do we actually know? | Evidence |
| What might explain it? | Hypotheses |
| How can we disprove each explanation? | Verification |
| Who decides what happens next? | Human control |
| What can run safely? | Guardrails and bounded automation |

I use these concepts to judge whether an AI system is helping during an incident or merely sounding convincing.

## What AI SRE changes in the first ten minutes

In our checkout incident, the initial job is orientation. An AI SRE can gather the alert timeline, affected services, recent code and configuration changes, service owners, relevant runbooks, and similar incidents. It can show that checkout and payments share a database connection pool, while inventory is downstream of checkout and may only be reporting a symptom.

That is already valuable. The responder has a smaller search space and a clearer picture of who should be involved. What the AI should not do is turn temporal correlation into a confident root cause.

Gandhi Mathi Nathan Kumar, Principal Incident Commander at Twilio, [puts mitigation before diagnosis](https://rootly.com/humans-of-reliability/gandhi-kumar-twilio). During an active incident, restoring service is usually more urgent than proving exactly why it failed. AI can investigate possible causes in parallel, but it should not pull the team into an elaborate root cause exercise while customers are still affected.

The first ten minutes should produce a usable incident picture:

- The customer and service impact
- The most relevant changes in the affected area
- The people and teams who own those systems
- A small set of plausible explanations
- The safest available mitigation
- The evidence that still needs to be collected

That is a more realistic standard than asking whether an AI agent can “resolve incidents autonomously.”

## Time-to-context is the core win

Time-to-context is the time it takes a responder to answer four questions with enough confidence to act:

1. What is failing?
2. What changed?
3. What is affected?
4. What should we verify next?

Teams feel this delay even when they do not formally measure it. It appears as ten browser tabs, repeated questions in the incident channel, duplicate investigations, and responders arriving without knowing what has already been ruled out.

I would measure time-to-context from the first alert or incident declaration to the point when the team has documented those four answers. It is not a replacement for MTTA or MTTR. It explains an important part of what happens between them. The [AI SRE metrics and ROI guide](https://rootly.com/ai-sre-guide/metrics-and-roi) goes deeper into measuring that change without pretending every saved minute came from AI.

Operational context determines whether this works. Telemetry can show that latency increased. The deploy timeline, dependency map, ownership catalog, feature flags, and incident history help explain where the team should look. The model is only one part of the system; the [architecture](https://rootly.com/ai-sre-guide/architecture) and [integration model](https://rootly.com/ai-sre-guide/integrations) determine what evidence it can reach.

## Evidence is the unit of trust

An AI system earns trust when a responder can inspect the path from source material to conclusion. Certainty without that path is just presentation.

For the checkout incident, a useful output would separate:

- **Observed facts:** checkout latency began at 14:03; version 2.18.4 reached 100% at 13:58; database connection saturation increased at 14:02.
- **Inferences:** the deploy may have increased connection usage; payments may share the same constrained dependency.
- **Unknowns:** whether the connection increase came from checkout, payments, or another workload; whether reverting the deploy will reduce saturation.
- **Next checks:** compare connection usage by service, inspect the relevant code change, and confirm whether the previous version used the same pool settings.
- **Proposed actions:** prepare a rollback, reduce traffic, or apply a known runbook only after the required checks and approvals.

Every important claim should point to a specific source and time window. If the system cannot find the evidence, “unknown” is the correct answer. A polished explanation should never be allowed to conceal missing context.

This matters because generative systems are probabilistic. [Google’s guidance on explainability and trust](https://pair.withgoogle.com/chapter/explainability-trust/) recommends showing what data an AI uses and giving people an appropriate understanding of its uncertainty. In an incident, that explanation has to be operational: not a generic confidence score, but the logs, traces, metrics, and changes that support the claim.

## Make every hypothesis verifiable

The first useful result of an AI investigation is usually a ranked set of explanations and a plan to reduce uncertainty.

For example:

| Hypothesis | Evidence for it | What would weaken it? | Safe next check |
| --- | --- | --- | --- |
| The checkout deploy exhausted the shared connection pool | Saturation rose four minutes after rollout | Other services created the new connections | Compare connections by service and version |
| The database degraded independently | Payments also slowed without a new deploy | Database health was normal before checkout traffic rose | Inspect database health and resource events |
| A traffic increase exposed an existing capacity limit | Request volume rose near the start of impact | Latency remains high after traffic normalizes | Compare current load with previous peaks |

The strongest hypothesis is the one that best fits the evidence now, not a verdict the team has to defend. A useful system should also state what would make its preferred explanation less likely.

Dan Slimmon, an incident response trainer and infrastructure engineer at Clerk, [applies the scientific method](https://rootly.com/humans-of-reliability/dan-slimmon) to incident troubleshooting: if an explanation cannot be tested or falsified, it is not yet a useful hypothesis. AI can help generate and rank possibilities, but responders still decide which tests are safe and whether the evidence is sufficient.

This also protects the team from confidence drift. Once a plausible story appears in an incident channel, people tend to organize around it. Showing competing hypotheses and disconfirming evidence makes it easier to change direction without treating that change as failure.

## Toil is the target, not engineers

The [Google SRE definition of toil](https://sre.google/sre-book/eliminating-toil/) is more precise than “work engineers dislike.” Toil is operational work that is manual, repetitive, automatable, tactical, and lacking enduring value.

That is where AI SRE can help today:

- Collecting and organizing incident evidence
- Finding ownership and routing the right responders
- Summarizing what changed and what has already been tried
- Maintaining a live timeline from source events
- Drafting audience-specific [incident communications](https://rootly.com/incident-response/communication)
- Preparing first-pass [postmortem](https://rootly.com/incident-postmortems) material with evidence links
- Retrieving relevant runbooks and previous incidents

None of this requires pretending that a model “thinks like a senior SRE.” It removes context gathering and coordination work so experienced people can spend more attention on mitigation, tradeoffs, and prevention.

Eran Kampf, VP of Engineering at Twingate and co-founder of Monday.com, [uses AI for initial triage](https://rootly.com/humans-of-reliability/eran-kampf) across runbooks, logs, and Kubernetes context. His standard is refreshingly practical: it is not always right, but when it is right it saves the on-call engineer meaningful investigation time, and when it is wrong the team knows to bring in a person.

A better measure is how much repetitive work AI can remove without making the remaining decisions harder to inspect.

## Human-in-the-loop is a control system

“Human in the loop” is meaningless if it only appears in a product description or system prompt. It has to exist in the workflow, permissions, and execution path.

A practical autonomy ladder looks like this:

1. **Observe:** retrieve evidence and summarize the incident.
2. **Recommend:** propose checks or mitigations with supporting evidence.
3. **Prepare:** construct an action for a responder to review.
4. **Execute with approval:** run a trusted automation after an authorized person confirms it.
5. **Execute within policy:** perform a narrowly predefined action when explicit conditions are met.

Teams should move up that ladder according to judgment and risk, not model capability alone. A read-only query across telemetry is not equivalent to changing production traffic. Drafting a rollback command is not equivalent to running it.

Controls should include scoped and time-bounded credentials, role-based approvals, tool allowlists, rate limits, complete audit trails, and stop conditions. The [AI SRE maturity model](https://rootly.com/ai-sre-guide/maturity-model) maps these controls to increasingly capable workflows.

This is also consistent with the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), which treats governance and accountability as part of the system lifecycle. In practical SRE terms: a system prompt is not an access boundary, and a confirmation message is not a substitute for authorization.

## Self-healing must be narrow, reversible, and governed

I am cautious with the term “self-healing” because it can make a high-risk production change sound natural and inevitable. The safe pattern is usually simpler:

> Probabilistic AI investigates and recommends. Deterministic automation executes a pre-approved action.

Restarting one unhealthy stateless instance may be a reasonable candidate when the team already has a tested [runbook](https://rootly.com/incident-response/runbooks), rate limits, health checks, and a stop condition. An AI system might gather the evidence and recommend that runbook. The execution path should still enforce the same policy every time.

By contrast, shifting traffic away from a region or rolling back a global feature flag can create a larger incident. Those actions may be appropriate, but they are not generically “safe” merely because they are reversible in theory. The team needs to know the current capacity, dependency behavior, data implications, rollback path, and authority required.

Before allowing any AI-initiated action, ask:

- Is the blast radius explicitly bounded?
- Is success measurable within a known window?
- Will the action stop or roll back if the expected signal does not appear?
- Has this exact automation been tested under realistic conditions?
- Can the AI alter the policy or guardrail controlling its own action?
- Can a responder reconstruct what was proposed, approved, and executed?

An LLM with broad cloud credentials is not a self-healing system. It is production access governed by an ambiguous policy.

## How to tell whether an AI SRE feature is real

Do AI SRE agents actually work, or are they hype? They work well at bounded investigation, retrieval, coordination, and recommendation when they have relevant operational context. The hype begins when those capabilities are presented as autonomous engineering judgment.

A five-minute evaluation should expose the difference:

| Ask the system or vendor | A credible answer should show |
| --- | --- |
| Where did this conclusion come from? | Source artifacts, timestamps, and the reasoning connecting them |
| What else could explain these symptoms? | Competing hypotheses rather than one polished story |
| What would disprove the leading hypothesis? | A concrete check and the expected observation |
| What happens when context is missing? | An explicit gap, not invented certainty |
| Can it change production? | Exact permissions, approvals, policies, and execution boundaries |
| What happens when its recommendation is wrong? | Stop conditions, rollback behavior, and escalation |
| Can we review the decision later? | A complete evidence, recommendation, approval, and action trail |

I would also ask for an imperfect demo. Remove a data source. Deny an approval. Give the system two correlated changes. Show it an incident that resembles a previous one but has a different cause. The failure path tells you more about operational readiness than the best successful investigation.

## What good AI SRE looks like in practice

![Illustration for “What good AI SRE looks like in practice”](https://rootly.com/assets/ai-sre-guide-concepts-what-good-ai-sre-looks-like-in-practice.avif)

Return to the checkout incident. A good AI SRE does not announce that the deploy caused the outage. It assembles the timeline, shows the shared dependency, links the relevant changes, separates facts from inference, and proposes the quickest checks. The incident commander chooses whether to roll back, reduce traffic, or continue investigating. Any action runs through an existing, controlled automation path.

Meanwhile, the system records what the team tried and what happened next. That evidence supports the [rest of the incident lifecycle](https://rootly.com/ai-sre-guide/lifecycle) and makes the eventual postmortem easier to reconstruct. It should not automatically treat every decision as a lesson worth repeating; reviewed outcomes are more trustworthy than raw operational memory.

That is the standard I use for AI SRE: faster orientation, sharper hypotheses, less repetitive work, and no ambiguity about who is responsible. It does not replace the reliability practice. It gives experienced responders more of their incident window back.

At Rootly, this is also the standard a useful demonstration should meet. If you are evaluating AI SRE, ask us to show the evidence chain, the permissions, and what happens when the system is uncertain or wrong. [That is a more revealing demo than watching an agent succeed on a perfect incident.](https://rootly.com/demo)