DEV Community

Cover image for The Vendors Shipped Autonomous SRE Agents. Here's the Governance Layer They Didn't Ship
Ajay Devineni
Ajay Devineni

Posted on

The Vendors Shipped Autonomous SRE Agents. Here's the Governance Layer They Didn't Ship

#sre #agentaichallenge #devops #security

Microsoft published a real production number this week: Azure SRE Agent has mitigated more than 35,000 incidents and saves over 20,000 engineering hours per month across Microsoft's own services. Dynatrace launched their Autonomous SRE Agent in August 2026 — their Chief Product Officer framing it directly: "Most observability platforms stop at data, leaving humans to find answers, determine what to do, and execute."

Both statements are true. The technology is working at scale. And the governance layer that determines whether you can trust those autonomous decisions is almost never part of the product announcement.

This article covers what the SRE community needs to build for itself five metrics that measure autonomous SRE agent behavior at the semantic layer, where vendor observability stops.

What the Press Releases Don't Cover

Microsoft's 20,000 engineering hours saved per month means tens of thousands of autonomous decisions made. Some percentage of those decisions are wrong. Not because the technology is bad — because all production systems fail at the tail, and autonomous systems that act on imperfect information will sometimes act incorrectly.

The responsible question is not whether to use autonomous SRE agents. The responsible question is: how do you know when the agent's decision was wrong, and what do you do about it?

Azure SRE Agent, Dynatrace Autonomous SRE Agent, AWS DevOps Agent, PagerDuty SRE Agent — all of them are shipping this year. None of them ship with the five measurement patterns below. That's not a criticism. It's a gap the SRE community is positioned to close.

The Five Governance Metrics

1. Root Cause Accuracy Rate (RCAR)

RCAR measures the percentage of agent root cause attributions confirmed correct in your postmortem record, tracked per incident category.

Why per category matters: an agent with 94% overall accuracy may have 70% accuracy for the specific incident class that represents your highest-stakes failures. Overall accuracy hides this. Per-category RCAR surfaces it.

from agentsre.ai_sre_governance import AISREAgentGovernor

governor = AISREAgentGovernor(
    agent_space_id="your-autonomous-sre-agent",
    rcar_threshold=85.0,
    arer_threshold=5.0,
    hor_warning_threshold=30.0,
)

# After each postmortem — wire to your incident management webhook
governor.record_investigation(
    incident_id="INC-2026-0805-001",
    category="database-failure",
    root_cause_confirmed=True,       # postmortem verdict
    remediation_executed=True,
    remediation_rolled_back=False,
    human_overrode=False,
)
Enter fullscreen mode Exit fullscreen mode

Alert threshold: RCAR < 85% for any category over 7 days → suspend autonomous remediation for that category. Not all categories — just the one that's degrading.

2. Autonomous Remediation Error Rate (ARER)

ARER measures the percentage of autonomous remediations that required rollback or correction. This is your blast radius signal — the metric that tells you whether wrong investigations are being acted upon.

The risk profile is asymmetric: a wrong investigation that was caught before action is recoverable. A wrong investigation followed by an autonomous remediation applied to the wrong component is a different category of failure entirely.

Alert threshold: ARER > 5% → suspend all autonomous remediations immediately, page the named SRO.

results = governor.collect("database-failure")
for r in results:
    print(r)
    if r.breached:
        # Suspend autonomy for this category
        disable_autonomous_remediation(r.metric, r.alert_message)
Enter fullscreen mode Exit fullscreen mode

3. Human Override Rate (HOR)

HOR measures the percentage of agent recommendations that on-call engineers override before execution. This is the leading indicator engineers begin overriding before RCAR measurably falls.

When an engineer overrides the agent's recommendation, they're telling you the agent's model of the system no longer matches their understanding of reality. That's the earliest possible signal of drift — earlier than any metric that requires waiting for a postmortem.

Alert threshold: HOR > 30% for any incident category → review the agent's topology model and context freshness before RCAR falls.

4. Decision Quality Rate (DQR)

DQR measures the percentage of agent decisions falling within expected behavioral bounds against a rolling baseline. It is not an accuracy metric — it doesn't require ground truth labels. It's a drift detection signal that fires before user-visible failures.

from agentsre import AgentSLICollector, TaskRecord

collector = AgentSLICollector()

collector.record(TaskRecord(
    task_id="t-001",
    task_class="incident-triage",
    tool_calls=4,
    decision_confidence=0.71,    # drifting from 0.91 baseline
    required_escalation=False,
    completed=True,
))

for r in collector.collect("incident-triage"):
    if r.breached:
        alert_oncall(r.name, r.alert_message)
Enter fullscreen mode Exit fullscreen mode

Alert threshold: DQR < 85% for 15 minutes → reduce autonomy level before the incident escalates.

5. Approval Queue Depth Drift (AQDD)

AQDD is the metric that standard SLO burn-rate alerts structurally cannot detect. When tasks are submitted for human approval and humans fall behind, the queue grows silently — no completion event, no failure event, no burn. Standard SLO dashboards show healthy. Operations are degrading.

Alert threshold: AQDD > 2x baseline for 30 minutes → human review layer is saturated, page SRO immediately.

The Progressive Autonomy Model

These five metrics gate a progressive autonomy model for autonomous SRE agents:

Level 1 — Triage only: DQR and TIE instrumented. Agent surfaces signals. Humans decide everything. No RCAR or ARER needed yet.

Level 2 — Advised actions: HER tracked. Agent recommends remediation. Human approves every action. RCAR begins as measurement.

Level 3 — Bounded autonomy: RCAR > 85% sustained 30 days for a specific incident category → agent executes autonomously for that category. ARER tracked. Any breach suspends autonomy.

Level 4 — Governed autonomy: All five metrics active and within bounds. Named SRO. Quarterly review of all categories.

Microsoft's Azure SRE Agent is operating at Level 3-4 for specific incident classes across Microsoft's internal services. That's what 35,000 incidents and 20,000 hours saved means. The governance model that makes it possible is the same model described above — it's just not in the press release.

What To Do This Week

If your team is evaluating Dynatrace Autonomous SRE Agent, AWS DevOps Agent, or any autonomous SRE tooling launching this month:

  1. Instrument DQR and TIE first — observation mode, no alerts yet
  2. Run 30 days of behavioral baseline before setting any threshold
  3. Register a named SRO before enabling any autonomous remediation
  4. Start at Level 1 (triage only). Earn Level 2 with 30 days of data.
  5. Write the postmortem process for the agent before the first wrong decision — not after

The vendors shipped the capability this week. The governance is yours to build.

Open-source implementation: https://github.com/Ajay150313/agentsre
LinkedIn discussion: https://www.linkedin.com/feed/update/urn:li:groupPost:6585254-7490483687269064704/?utm_source=share&utm_medium=member_desktop&rcm=ACoAACIp55QBRGVmAcEbf0D-1PaR5vEbm2yMcJU

Which of the five metrics does your team currently track for your autonomous SRE tooling?

Top comments (0)