Graduated autonomy for AI SRE: from recommend-only to auto-remediate

AI SRE Is No Longer a Single Product Category

The 2024 generation of AI SRE tools — Komodor’s incident copilot, Traversal, NeuBird’s first-generation incident agent, SRE.ai, FireHydrant’s AI features, Datadog’s Bits — sold a single thing: a smart assistant that summarizes what is happening during an incident. The 2026 generation sells something different. The leading vendors now ship graduated autonomy as a first-class concept: a single agent that runs in three distinct modes, scoped per runbook, with explicit promotion paths between modes.

The three modes are now standard across the category:

• Recommend-only. The agent investigates, correlates signals, and proposes a remediation. The human executes.
• Human-in-the-loop. The agent investigates, correlates, and produces a one-click executable plan. The human approves; the agent executes against the approval.
• Auto-remediate. The agent investigates, correlates, and executes a pre-approved remediation. The human reviews after the fact via the audit trail.

NeuBird’s April 6, 2026 launch of an Autonomous Production Operations Agent was the most explicit articulation of the pattern: a single product that ships all three modes and lets customers promote runbooks across them as confidence accumulates. The AI SRE Summit 2026 takeaways converged on the same shape — graduated autonomy, scoped per runbook, governed by per-action approval policy. Gartner’s 2026 forecast that 70% of enterprises will deploy agentic AI agents to operate IT infrastructure by 2029 is the macro-curve graduated autonomy is sitting on.

The graduated-autonomy frame matters because the alternative — a binary “is your agent autonomous or not” choice — is the wrong frame for production deployment. No single threshold of confidence applies across every runbook in a real on-call rotation. A deploy rollback inside the rollout window is a different risk profile from a multi-region failover. The teams that deploy agentic SRE in production in 2026 are the teams that treat autonomy as a per-runbook gradient.

The Per-Runbook Promotion Test

Promoting a runbook from recommend-only to human-in-the-loop to auto-remediate is a structured test, not an intuition. Five questions decide whether a runbook qualifies for the next mode:

1. Is the action reversible inside the same incident window? A deploy rollback within the rollout window is reversible — the previous version is still running and a re-deploy returns the service to the original state. A database truncation is not. Reversibility is the strongest signal that an action belongs in auto-remediate.

2. Is the blast radius bounded and known in advance? A pod restart on a single node has a known blast radius. A region failover does not. Auto-remediate runbooks need an explicit blast-radius bound encoded in the policy.

3. Does the runbook have a high-recall signal trigger? The trigger that fires the runbook needs to fire for the right incidents and not fire for adjacent ones. A spike in 5xx errors with a deploy in the rollout window is a high-recall trigger for “roll back the deploy.” A spike in 5xx errors with no recent deploy is not.

4. Has the agent executed the runbook successfully in the previous mode for at least N incidents? N is typically 10 to 30 depending on the runbook. The audit trail from the previous mode is the evidence pack for the promotion decision.

5. Is there a fallback to a human approver if any of the above breaks? Auto-remediate runbooks need an explicit “demote to human-in-the-loop” path that fires on policy drift, signal-quality degradation, or anomalous environment state.

The five questions are mechanical, but they are not free. Most teams that try to promote a runbook to auto-remediate without running the test discover they don’t actually have the audit-trail evidence to defend the promotion to the security or compliance team. The test is the work.

The Four Classes of Remediation That Qualify

Not every incident action is a candidate for auto-remediate. The four classes that consistently qualify in 2026:

• Deploy rollback inside the rollout window. The most common qualifying runbook because the reversibility test, the blast-radius bound, and the trigger quality are all strongly favorable.
• Pod / instance restart on isolated failure. Single-node failures with the rest of the deployment healthy. Reversible (restart re-creates the pod), bounded blast radius, high-recall trigger.
• Feature-flag rollback inside the rollout window. Reversible, bounded, high-recall when the flag flip and the spike align in time.
• Scale-out (not scale-in) on capacity pressure. Adding capacity is reversible (you can scale back), bounded, and the trigger quality from autoscaling signals is high.

Outside those four, auto-remediate is rare in production through 2026. Failovers, schema changes, IAM modifications, customer-facing communications, and anything that touches data integrity stay in human-in-the-loop or recommend-only mode.

What Recommend-Only Already Wins

Recommend-only is not a consolation mode. It is where most of the time-to-mitigate compression actually lands in 2026. The reason is that the work the agent does in recommend-only — correlating across MCP servers, pulling deploy diffs, identifying the most likely cause, drafting the remediation plan — is the work the on-call human used to do alone, and that work used to take twenty to forty minutes per Sev-2.

A recommend-only agent compresses that work to thirty seconds. The human still drives the response, but starts the response with the context already assembled instead of starting with a blank console. Across a quarter of incident volume, the time-savings compound to a significant labor offset on the on-call rotation, and the audit trail from the recommend-only mode is the evidence pack for promoting runbooks into the next two modes.

The teams that report MTTR reductions of up to 70% in 2026 are typically not running auto-remediate everywhere; they are running recommend-only on every Sev-2, human-in-the-loop on the four qualifying classes, and auto-remediate on the subset of those four that have completed the per-runbook promotion test.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

The Audit-Trail Evidence Model

The single biggest unlock for graduated autonomy is the audit trail. Every action the agent takes — read or write, recommended or executed — needs to land in an immutable, queryable audit log with the trigger, the agent’s reasoning trace, the action taken, the result, and the rollback evidence.

The audit trail is what makes the per-runbook promotion test defensible. It is what makes the security review of an auto-remediate runbook tractable. It is what makes a customer-facing postmortem credible when the response was partially agentic. And it is what gives the team the data to tune policy over time — which runbooks fire too often, which fire on the wrong signal, which would have benefited from a different action.

Vendors that ship graduated-autonomy AI SRE in 2026 ship the audit trail as a product feature, not as an operational byproduct. The audit trail lives in a separate, append-only sink, integrates with the customer’s SIEM, and supports per-action queries that compliance teams can run without engineering help.

Capability Tiers Mapped to AI SRE Modes

The Observe / Operate / Administer capability-tier model maps cleanly onto the three autonomy modes:

• Observe. Recommend-only mode. Agents read, correlate, summarize, and propose. Auto-execute (the read and the proposal), fully audited.
• Operate. Human-in-the-loop and auto-remediate modes for reversible / scoped actions. Auto-execute when in policy and reversible; gated when out-of-policy or hard to reverse.
• Administer. Cross-tenant changes, customer-facing communications, IAM modifications, billing impact, data-mutating operations. Always requires explicit approval; separation-of-duties enforced. Stay in recommend-only mode.

The mapping is what makes graduated autonomy deployable inside an organization with real compliance constraints. The autonomy modes describe agent behavior; the capability tiers describe approval policy. Teams that confuse the two end up with autonomy modes that the security team cannot sign off on.

How IAN Helps: The Incident-Agent on the Active Operational Layer

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The incident agent is one of those agents, and graduated autonomy is encoded into how it runs.

Every connected runbook starts in recommend-only mode by default. The agent runs the cross-tool investigation pattern continuously: every page that crosses a tier-2 threshold is correlated across the connected MCP servers (PagerDuty, Datadog, Splunk, GitHub, AWS, internal services) and a remediation proposal lands in the incident channel within seconds. The recommend-only mode produces the audit-trail evidence that drives the per-runbook promotion test.

Customers can promote individual runbooks to human-in-the-loop or auto-remediate via the capability-tier policy. Reversible actions inside the four qualifying classes auto-execute when policy permits; everything else is gated. Every action lands in the immutable audit trail with the trigger, the agent’s reasoning trace, the action taken, the result, and the rollback evidence.

Pricing is BYOK and usage-based with a monthly minimum. Customers bring their own model keys (Claude, OpenAI, or another provider) and pay inference cost directly to their model vendor. IAN charges for the orchestration layer, per agent action, per cloud account, per operation class. Usage scales with incident volume, which is itself a strong signal of where the team should invest in reliability work.

The Three-Phase Rollout

Phase 1 — Recommend-only across every Sev-2 page. Wire the incident agent into the on-call workflow as a read-only assistant. Ship the cross-tool incident summaries in the incident channel for every Sev-2 page. Measure time-to-context (page-to-summary latency) and let the on-call team rate the summary quality. Two-to-three months.

Phase 2 — Human-in-the-loop on the four qualifying classes. Codify the four reversible runbook patterns (deploy rollback, pod restart, flag flip, scale-out). Set the capability-tier policy. Let the agent produce one-click executable plans and the on-call human approves. Measure time-to-mitigate. Two-to-three months.

Phase 3 — Auto-remediate the subset that passes the per-runbook promotion test. Run the five-question promotion test on each of the four qualifying classes. Promote only the runbooks that pass. Tune the demote-to-human-in-the-loop fallback. Continue running the other three modes in parallel.

The pattern compounds. By the time Phase 3 lands, the on-call team is running a different shape of work — fewer minutes locating signals and waiting for agents to finish proposals, more minutes deciding which runbooks should graduate to the next mode — and the incident-agent has accumulated enough audit data to make the next round of policy tuning a data exercise rather than a debate.

Get a free infrastructure audit → | See pricing →