The AI SRE Files is a series where we take one practitioner conversation about AI in SRE and work through the idea at the center of it.

This article draws from the session “We Automated the Runbook. The Hard Part Was Teaching the Agent When Not to Run It,” presented at AI SRE Next Bengaluru on July 25.

It’s 2:03 AM, and a service is running at 98% CPU. An AI agent picks up the alert and finds a runbook called Restart Service. It has everything it needs to execute it within seconds.

So should it restart the service?

Kaustubha Shravan, Solution Architect at Microsoft, opened her session with this scenario.  The obvious answer might be yes. The CPU is high, there’s a runbook for exactly this situation, and the agent knows how to run it.

But what if the CPU spike is happening because of a sudden increase in traffic? Restarting the service could make things worse. A valid runbook can still cause damage when the agent executes it without understanding what is happening around the alert.

Why does a valid runbook still cause outages when an AI agent runs it?

Traditional automation had a fairly straightforward job. An alert fired, and a predefined workflow followed. The system did not have to decide whether the action was right for the situation because that decision had already been made when the automation was designed.

AI agents have more decisions to make. They can look at an alert, find a relevant runbook, and take action, but first they need to understand what is happening around that alert. A runbook that worked for the same signal yesterday may be the wrong response today.

Kaustubha shared four examples to show how much the surrounding context can change the outcome.

In each case, the action could be appropriate under different circumstances. The agent therefore needs more than a matching alert and a runbook before it acts. It needs enough context to determine whether that action is appropriate for the incident in front of it.

How should an AI agent decide whether to execute a runbook?

Kaustubha's point was about the judgment required for AI-driven remediation. Whether an agent can execute a runbook is mostly a question of capability. Her framework puts a decision process between the alert and the action. Every automated action goes through four steps before the agent decides what to do next.

1. Observe: The agent picks up the alert and the signals around it.
2. Understand: It looks at the context and history behind those signals.
3. Evaluate risk: It assesses its confidence and the potential impact of taking action.
4. Decide: Based on what it finds, the agent can execute the runbook, escalate to an engineer, or wait.

That last step leaves room for more than one response to the same alert. Sometimes the evidence is strong enough for the agent to proceed. In other cases, there may be too much uncertainty or too much at stake for it to act on its own.

Confidence Thresholds for Automated Remediation

Confidence is the first principle in Kaustubha’s framework. An agent will not have the same level of certainty for every alert, so confidence is one factor that helps determine what it is allowed to do next.

She used illustrative confidence thresholds to explain how an agent's response might change depending on the evidence available. These percentages are examples, not recommended thresholds for production environments.

• 95% or above | Potentially eligible for automatic execution: A disk at 96% capacity with a known cause and clean history may qualify for automatic remediation, subject to the team's safety policies.
• Around 75% | Request human review: Multiple causes are still possible, so the agent flags the alert and waits for an engineer to review it before executing anything.
• Below 40% | Escalate without action: There are too many unknowns to attempt remediation. In the storage latency example, the agent escalates the incident without making changes.

These examples show how confidence levels can help your team decide when an agent should act, request human review, or escalate. However, high confidence alone is not enough to authorize automatic remediation. Your team must also consider the potential blast radius, operational context, permissions, and safety policies before allowing an agent to execute a change. The actual thresholds and approval requirements will depend on your environment.

Blast Radius Sets the Boundary for Automation

Blast radius is the second principle. The action an agent wants to take may be familiar, but the number of systems affected can change the risk involved.

Consider the same Restart Service runbook applied at two different scopes:

• Single VM | Limited impact, automatic execution: A failed restart affects one VM, so the potential disruption stays contained. You can allow the agent to execute automatically if the action meets your team's safety criteria.
• Entire cluster | Risk of cascading failures, human approval: A failed restart could disrupt multiple services and their dependencies. The agent must wait for an engineer to assess the impact and approve the action.

Your team can define these boundaries before an incident occurs. You decide which actions and scopes are safe for autonomous execution and which require an engineer's approval.

Human Approval Is the Safety Valve

There will be incidents where the agent has completed its analysis but still needs an engineer to approve the next action.

The decision depends on two factors:

• High confidence, limited blast radius: The agent can proceed automatically if the action meets your team's safety criteria.
• Moderate confidence or high blast radius: The agent must request human approval before it makes any changes to production.

The agent has already investigated the incident, identified a possible remediation, and assessed the risk. Your engineer can review that evidence and decide whether the proposed action is safe to execute.

Kaustubha describes human-in-the-loop as a “safety valve.” It gives your team control over higher-risk decisions while the agent handles the investigation and actions that fall within its approved limits.

Reversibility Sets Another Limit on Automation

The fourth principle is reversibility. Before you allow an agent to execute a remediation, you need to consider what happens if its decision turns out to be wrong.

Some actions are easier to recover from than others. A service restart may take seconds to recover from, while a cluster scale change can usually be reversed, although restoring the previous state may take time. Production configuration changes carry greater rollback risk, and deleted logs may be impossible to recover.

Kaustubha summarizes this principle with a clear rule: “Never automate an action that cannot be rolled back.”

Consider an agent that detects low disk space and proposes deleting logs to free up capacity. Those same logs may contain evidence your team needs to investigate the incident. If the agent deletes them without approval, your engineers could lose access to critical diagnostic data.

Your team can use reversibility as another criterion in its automation policy. Actions with predictable recovery paths may qualify for autonomous execution, subject to safety policies. Actions that are difficult or impossible to reverse require stronger safeguards, an assessment of the potential impact, and explicit human approval before execution.

Trustworthy Automation Is Automation Engineers Leave Enabled

The goal, as Kaustubha describes it, is automation that engineers are comfortable leaving enabled. That trust depends on how well the agent handles uncertainty, assesses risk, knows when to ask for approval, and avoids actions that cannot be reversed.

Kaustubha ended her session with a question that brought the discussion back to the 2:03 AM alert:

“The question was never ‘can the AI run the runbook?’ The question is: ‘Do you trust it to decide?’”

Before an agent takes action, your team needs evidence to understand what caused the incident and decide whether the proposed remediation is safe. Aiden for SRE investigates incidents using telemetry and operational context from your existing tools, tests possible root causes, and provides an RCA backed by the queries, log lines, and configuration diffs that support its findings. Your engineers can verify the evidence and approve any action that changes production.

Try this workflow with the free Aiden for SRE Community Edition. Connect Grafana or Datadog, trigger an alert, and review the RCA Aiden generates.

Disclaimer: The technical perspectives attributed to Kaustubha in this article reflect her personal views. References to StackGen and Aiden for SRE are included by StackGen for product context only.