AWS DevOps Agent went generally available this week. It's a frontier agent — autonomous, massively scalable, designed to work for hours or days without constant intervention. It analyzes data across monitoring tools, reviews recent deployments, and coordinates incident response. incident.io
I've been building the SRE governance framework for exactly this class of agent for five months. Eighteen posts, an open-source library, an arXiv paper, a DynamoDB-backed ARO registry, a Pre-Action SRE Gate, an EvalPipeline that runs nightly DQR checks.
All of that is the technical governance layer. This post is about the human governance layer — the one that fails quietly and shows up in your postmortem eighteen months after you deployed the agent.
The Pattern
The agent failed confidently, without signaling uncertainty, and the humans around it had gradually stopped watching. We have decades of research on automation complacency in aviation and industrial control systems. The failure mode is well understood: when automation performs reliably for an extended period, human operators reduce active monitoring. When the automation eventually fails — and it always does — the operators have lost the situational awareness to catch the failure quickly. Yahoo Finance
This is not a hypothetical for AI SRE agents. It's the natural trajectory of any reliable automation deployed into an on-call rotation.
Week one: engineers review every agent decision. They read the reasoning. They validate the RCA. They check whether the remediation matched what they would have done.
Week four: engineers review decisions that look unusual. The routine ones get a glance and a thumbs up.
Week twelve: engineers check whether the incident resolved. If it did, they move on. The agent's reasoning is no longer being read.
The agent's HER looks healthy. DQR is above threshold. Incidents are resolving faster. Every metric in the governance stack is green.
What isn't being measured: whether any human has verified that the agent's reasoning was correct, or whether the team has simply started accepting the outcome as a proxy for correctness.
Introducing ACR — Automation Complacency Rate
ACR is the fraction of agent decisions accepted by the team without active human verification of the reasoning, measured on a rolling window.
Formally:
ACR(A, t) = decisions_accepted_without_verification(A, t)
/ total_agent_decisions(A, t)
Where "accepted without verification" means the human noted the outcome (incident resolved, action taken) but did not read the decision trace, validate the RCA, or challenge the agent's reasoning.
This distinction matters because outcome acceptance and reasoning verification are two completely different signals. An agent can produce the right outcome for the wrong reason, and if your team only checks outcomes, you will not detect the reasoning drift until a novel incident exposes it.
Why ACR Rising Is Not Good News
The instinctive interpretation of rising ACR is that the agent has earned trust. The team reviewed everything early on, found the agent reliable, and appropriately reduced their verification overhead.
That interpretation is sometimes correct. It is also the interpretation that precedes most automation complacency incidents in aviation and industrial control systems.
The correct interpretation of rising ACR depends on what's happening to your other SLIs in the same window.
If ACR rises while DQR is stable and RTD is low — the agent may genuinely have earned reduced oversight for that task class. Narrow the blast radius, document the trust extension, and set a review date.
If ACR rises while DQR shows any downward trend — the team has reduced oversight while agent quality is slipping. This is the danger zone. The two signals moving in opposite directions is your automation complacency signature.
If ACR rises after HER drops — the agent is escalating less AND the team is reviewing less. This is the double-exposure pattern. Maximum undetected risk surface.
Three ACR Signals Worth Tracking
ACR trend — weekly rolling average, 30-day window. A rising trend over any 4-week period warrants a review meeting, not an alert. This is a cultural signal, not an infrastructure signal.
ACR by severity — P1 and P2 incidents should have near-zero ACR. If your team is accepting agent decisions on P1s without verification, that is your risk exposure quantified. Set a hard target: P1 ACR < 5%.
ACR after HER drop — when HER drops meaningfully (agent escalating less often), check ACR in the same window. If both move in the same direction — agent acts more, team reviews less — that combination needs governance intervention before the next novel failure mode.
What Verification Actually Means
Verification is not approval. It doesn't mean the engineer had to intervene or override the agent. It means a human read the agent's reasoning trace, validated that the RCA was correct, and confirmed that the remediation matched what an experienced engineer would have chosen.
This takes three to five minutes for a well-structured RTD trace. It's not a burden if the trace is readable. It is a burden if the trace requires excavating through unstructured logs — which is why Layer 3 observability (the RTD module from Post 11 of this series) exists. You cannot verify reasoning you cannot read.
pythonfrom agentsre.automation_complacency import ACRTracker, VerificationRecord

tracker = ACRTracker(agent_id="devops-agent-v1", task_class="incident-investigation")

After each agent decision, log whether a human verified the reasoning

tracker.record(VerificationRecord(
decision_id="inc-2026-0615-001",
outcome_accepted=True, # team noted incident resolved
reasoning_verified=False, # nobody read the RTD trace
severity="P2",
verifier=None
))

status = tracker.acr_status()
if status["p2_acr_pct"] > 20.0:
# P2 incidents being accepted without reasoning review
# This needs a team conversation, not an automated alert
notify_sre_lead(status)
The AWS DevOps Agent Specific Context
AWS DevOps Agent works for hours or days without constant intervention. When production incidents occur, it analyzes data across multiple monitoring tools, reviews recent deployments, and coordinates response teams. incident.io
An agent that works for hours without intervention is an agent where ACR will naturally rise. The longer the autonomous window, the more decisions accumulate before any human checkpoint.
This is not a criticism of the agent. It's a governance design requirement. Long-running autonomous agents need structured human verification checkpoints built into the workflow — not just at the end when the incident resolves, but at decision points during the investigation.
The Pre-Action Gate from Post 13 is one checkpoint. The ACR tracker is the measurement layer that tells you whether those checkpoints are actually being used as verification moments or just passed through as administrative steps.
The Postmortem Question
Add this field to every postmortem that involves an autonomous agent action:
"For each significant agent decision during this incident: was the reasoning verified by a human before the next action was taken, or was it accepted based on outcome?"
If the answer is consistently "accepted based on outcome" — your team's ACR is above zero and you don't have a measurement layer for it. That's the gap this post addresses.
The agentsre/automation_complacency.py module is now in the GitHub repo. MIT licensed, zero external dependencies for core logic.
Ajay Devineni | AWS Community Builder | Senior SRE/Platform Engineer

github.com/Ajay150313/agentsre | dev.to/ajaydevineni