Dora NodaOn March 31, 2026, AWS made its DevOps Agent generally available — an autonomous AI teammate that detects production incidents, correlates telemetry across your observability stack, pinpoints the root cause, and posts a mitigation plan to Slack. Western Governors University reports it cut mean time to resolution by 77%, from two hours to 28 minutes. And then, at the moment of truth, the agent stops. It recommends the rollback. It will not execute it. By explicit design, AWS DevOps Agent has no write access to your infrastructure.
That boundary is the most interesting thing about the product. The diagnose-not-act line is not a technical limitation — the same agent architecture that reads your deployment history could call your deployment API. It is a trust boundary, drawn deliberately by the one company with the most infrastructure automation experience on Earth. Crossing it safely requires machinery most platforms have never shipped: per-agent identity, action-scoped credentials, approval gates per action class, an append-only audit trail, and reversible primitives the agent can verify. This post looks at what AWS actually shipped, why it refuses to cross the line, what the refusal costs, and what a platform has to build before "the agent deploys the fix" is a safe default instead of a liability.
What GA Actually Shipped
AWS DevOps Agent's incident response and SRE capabilities reached general availability on March 31, 2026, with billing starting April 10; release management (code review for release readiness, autonomous release testing) remains in preview. The product is built on Amazon Bedrock AgentCore and runs 24/7: it triages alerts, investigates across AWS, multicloud, and on-premises environments, and correlates observability data with code diffs, deployment history, and runbooks to answer the question every on-call engineer asks first — what changed?
The integration surface is broad. On the telemetry side: Amazon CloudWatch, Datadog, Dynatrace, Grafana, New Relic, and Splunk. On the code side: GitHub, GitLab, and Azure DevOps. Findings land in Slack, ServiceNow, or PagerDuty, and custom integrations arrive via MCP servers — the same protocol the rest of the agent ecosystem has standardized on.
Access is governed by Agent Spaces: logical containers that define which AWS accounts, external tools, and users the agent can see, constrained by the IAM role you attach. The discovery layer is genuinely impressive — in one independent evaluation by AWS Fundamentals, the agent mapped 1,239 resource relationships automatically from basic read permissions.
The customer numbers are real and worth taking seriously:
- Western Governors University: 77% MTTR improvement — incidents that took 2 hours now resolve in 28 minutes.
- Zenchef: investigations that took engineers 1–2 hours manually now complete in 20–30 minutes, a roughly 75% reduction.
Pricing is $0.0083 per agent-second — about $30 per hour of active investigation — with monthly credits tied to your AWS Support plan and a two-month free trial.
But read the fine print of what the agent does with all that access: it investigates and recommends. The IAM role scopes what it can read. There is no write path. When the agent concludes "roll back deployment api-7f3c" or "raise the connection pool limit," a human engineer executes that conclusion. Every time.
Why AWS Won't Cross the Line
It would be easy to read diagnose-only as timidity. It is closer to honesty — about three specific problems.
The blast radius of arbitrary write access
AWS DevOps Agent operates over general infrastructure: any service, any resource, anything an IAM role can touch. Granting an autonomous agent write access in that world means the action surface is effectively all of IAM — thousands of API actions, many irreversible, many with cascading effects the agent cannot model. A wrong recommendation costs an engineer five minutes of skepticism. A wrong executed action at 3 a.m., with iam:* or rds:DeleteDBInstance in scope, is a second incident layered on the first.
The agent is sometimes confidently wrong
The same AWS Fundamentals evaluation that praised the agent's evidence-gathering found a sharper failure mode: given a component mismatch between two services, the agent correctly identified the mismatch but sometimes "picked the wrong side to blame" — recommending a fix to the component that wasn't broken. The evaluators' summary is the key sentence in this whole debate: evidence surfacing outperforms root-cause reasoning. An agent that surfaces the right logs but occasionally indicts the wrong service is enormously useful as an investigator and genuinely dangerous as an unsupervised operator of arbitrary infrastructure.
Nobody else is crossing it either
This is not just AWS's line. Datadog's Bits AI SRE "investigates alerts and surfaces actionable root cause in minutes" — so engineers can "confidently resolve incidents faster." Investigation-first, human-executes is the enterprise norm in 2026; where vendors do offer remediation, it ships behind human approval gates. When every vendor with production access to thousands of enterprises independently draws the same boundary, the boundary is information.
The Last Mile Diagnose-Only Leaves on the Table
Now look at what the refusal costs, because it is not zero.
Walk through the 3 a.m. incident with the GA product in place. The alert fires. The agent investigates autonomously and, within minutes, posts to Slack: root cause identified, deployment api-7f3c introduced a connection leak, recommendation: roll back to api-7f2b. So far, this is the 77% improvement — investigation time has collapsed.
Then the recommendation sits there. PagerDuty pages a human. The human wakes up, reads the Slack thread, context-switches into the console or CLI, finds the right service in the right environment, and types the rollback command the agent already wrote. The engineer has become a typist for the agent's decision — and every minute between the recommendation and the keystroke is pure MTTR that no amount of better diagnosis can remove.
This is why WGU's 28 minutes is the right number to stare at. The agent's investigation takes minutes; the residual 20-odd minutes are substantially the human execution loop — page, wake, orient, verify, act. Diagnose-only compresses the first half of MTTR toward zero and leaves a human-shaped floor under the second half. The counter-argument writes itself: "28 minutes is fine; the last mile isn't worth the blast radius." For arbitrary infrastructure with an IAM-wide action surface, that's probably correct — which is exactly AWS's position. The question is whether the trade-off changes when the action surface isn't arbitrary. It does.
There is also a subtler cost: the handoff itself is an error source. The agent recommends against one service; a groggy human executes against a similarly named one, or against staging config in a production terminal. Splitting decision from execution doesn't just add latency — it adds a transcription step, and transcription steps fail.
What a Platform Must Ship Before the Agent Can Act
The gap between "the agent recommends the fix" and "the agent deploys the fix" is not a model-capability gap. It is five pieces of platform machinery. This is the checklist — and it doubles as an evaluation rubric for any agent-operations product that claims to close the loop:
-
Per-agent identity with scoped credentials. The agent is a principal, not a script running under a shared admin token. Each agent gets its own API token bound to specific projects and specific verbs, revocable independently of any human's access. If your agent authenticates as "the admin kubeconfig," you have not crossed the line — you've erased it.
-
Approval scoping per action class. Not one big autonomy switch. Reads are free; restarts and rollbacks can be auto-approved; scale-ups above a threshold require a human thumbs-up in the same channel where the recommendation landed; destructive actions (delete app, drop domain) are denied to agent principals entirely. The policy is per-verb and per-environment, so "act autonomously in staging, propose in production" is a configuration, not a feature request.
-
An append-only audit trail attributing every action to the agent. Every state change records which agent, what action, what the system state was before and after, and what evidence the agent cited. When the 9 a.m. review asks "why did production roll back at 3:12?", the answer is a queryable log, not a Slack archaeology dig.
-
Narrow, reversible primitives — not shell access. The agent's verbs are the platform's verbs:
deploy,rollback,restart,scale,set-env. Each is idempotent, each is itself reversible by another verb in the same set. This is also the containment answer to the wrong-blame failure mode: if the agent misdiagnoses and rolls back the healthy service, the damage is bounded (one known-good previous version, briefly restored) and the undo is the same one-verb operation. A misdiagnosis executed throughrollbackis an inconvenience; the same misdiagnosis executed through arbitrary IAM is an outage. -
Machine-readable state for closed-loop verification. After acting, the agent must be able to check its work: query deployment status, health checks, and error rates through the same structured API, and escalate to a human if the fix didn't fix. An agent that can act but not verify is a fire-and-forget missile; verification is what turns action into operation.
Notice what makes this checklist tractable: the narrowness of the action surface is the enabler. AWS can't safely give its agent write access because its agent's world is all of AWS. A platform-as-a-service has a different geometry — the entire operational surface of an app is a handful of verbs over well-defined resources. Approval policies over five verbs are enumerable. Audit logs over five verbs are readable. Reversibility over five verbs is provable. The diagnose-not-act line isn't a fixed frontier of AI trustworthiness; it's a function of how much damage the action vocabulary allows.
This is the design bet behind Bex.co's agent story: because the platform's API surface is already narrow, versioned, and reversible, its MCP server can expose those same verbs to an AI agent as first-class, authenticated operations — so the agent that concludes "roll back api-7f3c" issues the rollback as the same audited action, under its own identity, and then reads the deployment status back to confirm the service recovered. The recommendation and the execution stop being two systems with a human transcription step between them.
The Line Will Move — Surface by Surface
AWS DevOps Agent's GA is a milestone worth respecting: a hyperscaler now ships an agent trusted to investigate every production incident autonomously, and enterprises are seeing real numbers — 77% MTTR reduction, 75% less investigation toil — from diagnosis alone. The refusal to act is equally instructive. It tells you that in 2026, the binding constraint on agentic operations is not model intelligence; it is the absence of infrastructure built to be operated by agents — identity, scoping, audit, reversibility, verification.
Expect the line to move the way trust always moves: surface by surface, not all at once. Narrow, reversible action surfaces — restart this service, roll back this deploy, scale this worker — will get agent execution first, behind per-verb approval policies, while arbitrary-infrastructure agents stay advisory for years. The platforms that benefit won't be the ones with the smartest models. They'll be the ones whose action surfaces were designed so that letting an agent act is a bounded risk instead of an open-ended one. AWS built an agent that manages the risk by refusing to cross the line. The next generation of platforms gets to build the line right.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP server that lets AI agents deploy and operate apps as first-class, audited operators. Star the repo on GitHub or deploy your first app today.
Sources
