AWS DevOps Agent is GA. What a single-cloud SRE agent can't do.

A Strong Validation, And a Structural Limit

AWS DevOps Agent reached general availability in March 2026, built on Amazon Bedrock AgentCore and priced per second of cumulative agent operating time. The April 6 AWS Weekly Roundup, the InfoQ writeup, and the official AWS Cloud Operations Blog laid out the picture: pre-GA customers including United Airlines, Western Governors University, and T-Mobile reported up to 75% lower mean-time-to-resolution, 80% faster incident investigations, and 94% root-cause accuracy against their production incident corpus. The agent ships across six AWS regions at GA (Northern Virginia, Ohio, Ireland, Frankfurt, Tokyo, Sydney), with AWS Support customers receiving monthly DevOps Agent credits scaled by support tier.

Two things are true at once. First, the GA is a strong industry validation of the AI-SRE category. The same MTTR / investigation-time / root-cause-accuracy improvements have been claimed in the broader market for two years; AWS putting them on the GA announcement page is a signal that the category has crossed from research to production for at least the AWS-native customer base. Second, the structural limit is the one every hyperscaler copilot shares: the agent is locked to AWS, and the parent-cloud incentive is to deepen the customer’s AWS footprint rather than to credibly cover the customer’s full incident surface.

That structural limit is the through-line that motivates the cross-cloud, vendor-neutral SRE-agent pattern.

What AWS DevOps Agent Does — And Where It Stops

AWS DevOps Agent’s product picture, as documented across the GA announcement and the preview-period blog series:

• Incident investigation. The agent learns application relationships across CloudWatch, X-Ray, AWS Resource Explorer, and the customer’s runbooks. When an alert fires, the agent walks the dependency graph, correlates signals, and proposes a root-cause hypothesis with supporting evidence. The 94% root-cause-accuracy claim is anchored against this workflow.
• Code repository correlation. The agent ties signals back to recent CI/CD changes — Bedrock-AgentCore integrations into CodeCommit, CodePipeline, CodeDeploy, and third-party CI surfaces like GitHub Actions. The MTTR improvement is anchored against the “find the deploy that broke it” step.
• On-demand SRE tasks. Beyond incident response, the agent can take an SRE-style task (“audit the autoscaling configuration on this service against the runbook”) and execute against it. The per-second pricing aligns to this surface.
• Multicloud and on-premises framing. AWS markets the agent as multicloud-aware, but the actual signal ingestion remains AWS-CloudWatch-centric. Non-AWS signals (Datadog, New Relic, Prometheus, Splunk) enter through the customer’s existing integration paths into AWS.

Where the product structurally stops:

• Non-AWS cloud accounts. The agent ingests AWS-native signals first-class. GCP and Azure equivalents (Cloud Monitoring, Azure Monitor) enter as second-class data sources, often through customer-built integrations. The agent’s reasoning chain is trained against the AWS service taxonomy.
• Kubernetes outside EKS. The agent has rich EKS coverage. GKE, AKS, OpenShift, Rancher, and self-managed Kubernetes are reachable but uneven.
• On-prem and edge fleets. Datacenter VMware, bare-metal Kubernetes, edge compute, and SaaS-vendor surfaces (Snowflake, Databricks, Salesforce) sit outside the agent’s first-class topology.
• The cross-cloud incident path. A real-world production incident in 2026 routinely crosses AWS, a SaaS vendor, an on-prem dependency, and a CI/CD surface that lives on GitHub. The agent that can investigate inside the AWS slice cannot reason across the full topology.

Both halves are accurate. AWS DevOps Agent is a strong incident-response agent for the AWS slice of the customer’s environment. It is, by parent-cloud design, not a cross-cloud SRE agent.

The Cross-Cloud Incident Pattern That Hyperscaler-Locked Agents Cannot Serve

Three workload patterns in 2026 expose the cross-cloud limit directly:

• The SaaS-vendor latency incident. A customer’s checkout latency p99 doubles. The investigation crosses the customer’s AWS Lambda layer, their Snowflake-backed feature store, a Stripe API call, and a third-party fraud-scoring vendor. AWS DevOps Agent can investigate the AWS slice; the cross-cloud root cause requires walking signals across Snowflake’s status feed, Stripe’s API health, and the fraud-scoring vendor’s incident page. The agent cannot stitch that walk without external-signal-ingestion plumbing the customer builds themselves.
• The multi-cloud DR failover. An incident triggers automated failover from an AWS region to a GCP region (some customer architectures actively maintain cross-cloud DR for sovereignty or regulatory reasons). The agent that can run the AWS-side runbook cannot run the GCP-side runbook, and the failover blast radius lives in the boundary.
• The hybrid on-prem incident. A workload running on bare-metal Kubernetes in the customer’s datacenter loses its connection to an S3 bucket. The investigation crosses the customer’s on-prem Kubernetes (Prometheus signals), the customer’s network (an Aviatrix or Megaport link), and the AWS endpoint (CloudWatch / VPC Flow Logs). AWS DevOps Agent can investigate the AWS endpoint; the on-prem half stays outside its frame.

A cross-cloud SRE agent has to walk all three. The walk requires a topology model that spans cloud accounts, a signal-ingestion model that does not privilege any one provider, and a runbook orchestration model that crosses on-prem, multi-cloud, and SaaS-vendor surfaces.

That is the work of an active operational layer that is not anchored to any one parent cloud.

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 MTTR Claims Have to Be Normalized to the Customer’s Baseline

The 75% / 80% / 94% pre-GA numbers — published by AWS for United Airlines, Western Governors University, and T-Mobile — are real, and they are also customer-specific. A platform team evaluating AWS DevOps Agent in 2026 needs to put four normalization filters on those headline numbers before they enter the buying decision:

• Baseline MTTR. A 75% improvement against a 90-minute baseline is operationally different from a 75% improvement against an eight-hour baseline. Ask the vendor — or the reference customer — what the absolute pre-agent MTTR was. Three of the four reference accounts in 2026 hyperscaler-copilot case studies have baselines above the customer’s, which inflates the relative-improvement number.
• Investigation-time vs MTTR. “80% faster investigations” is a useful subset claim — it covers the time-to-hypothesis, not the time-to-resolution. Time-to-resolution is gated on remediation, which is gated on approval, which is gated on tier policy. The remediation path is where most cross-cloud incidents stall.
• Root-cause-accuracy denominator. “94% root-cause accuracy” measures the rate at which the agent’s top-ranked hypothesis matched the eventually-determined root cause on the case-study corpus. The corpus matters. Single-cloud incident corpora skew toward single-cloud root causes — the cases the agent is structurally best at. A vendor-neutral comparison requires the corpus to reflect the actual distribution of the customer’s incidents, including the cross-cloud and on-prem cases.
• MTTR variance, not just the mean. The expensive incidents are the long-tail ones — the 1% of incidents that take 12+ hours. A 75% mean-MTTR improvement that leaves the long tail untouched is materially less valuable than a 30% mean-MTTR improvement that compresses the long tail. Ask for the p99 in addition to the mean.

None of this means the AWS DevOps Agent numbers are wrong. The point is that the bake-off has to apply the same four filters to every AI-SRE product the platform team is comparing — including IAN’s SRE agent. Numbers that survive the filters are decision-grade; headline numbers that do not are marketing.

Capability Tiers Mapped to AI-SRE Incident Response

The Observe / Operate / Administer capability-tier model maps cleanly to cross-cloud AI-SRE incident response:

• Observe. Continuous signal ingestion across every connected cloud account (CloudWatch, Cloud Monitoring, Azure Monitor), every observability vendor (Datadog, New Relic, Prometheus, Honeycomb), every on-prem feed, and every SaaS-vendor status surface. Dependency-graph construction across the union of signals. Root-cause hypothesis generation with supporting evidence. Auto-execute, fully audited.
• Operate. Auto-rollback to the last known-good deploy against pre-approved release-policy scopes, scaling-policy adjustments against pre-approved capacity envelopes, runbook execution against pre-authorized targets, and on-call paging-policy adjustments. Auto-execute for reversible / scoped actions; gated when the action crosses an organization-wide boundary.
• Administer. Cross-cloud DR failover decisions, customer-facing communications, separation-of-duties exceptions for emergency response, and any change to the on-call escalation policy itself. Always requires explicit approval with separation of duties enforced.

The mapping is what turns AI-SRE from a single-cloud productivity tool into a cross-cloud operational fabric.

How IAN Helps: The SRE 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 SRE agent is one of those agents, and it runs continuous cross-cloud signal ingestion and dependency-graph construction across every connected cloud account, every observability surface, every on-prem feed, and every SaaS-vendor status target.

Root-cause hypotheses surface with supporting evidence from the union of signals, not from any one cloud provider’s slice. Reversible Operate-tier actions — auto-rollback against pre-approved release policy, scaling-policy adjustments against pre-approved capacity, runbook execution against pre-authorized targets — execute automatically when policy permits. Irreversible or organization-wide actions (cross-cloud DR failover, customer-facing communications, on-call-policy changes) escalate to the Administer tier with separation-of-duties enforced. Every action lands in the immutable audit trail, which doubles as the post-incident review artifact for internal audit, customer-trust review, and incident-retro publication.

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 the volume of incidents investigated and the volume of cross-cloud signals stitched, which is itself a strong signal of where the team is recovering reliability headroom.

The pricing contrast with AWS DevOps Agent is structural, not just numerical. AWS DevOps Agent’s per-second pricing aligns to AWS’s incentive to deepen AWS-account spend. IAN’s per-action BYOK pricing aligns to the customer’s incentive to investigate cross-cloud incidents accurately, regardless of which provider’s signals are richer.

The Three-Phase Rollout

Phase 1 — Stand up the cross-cloud Observe layer. Wire continuous signal ingestion across every connected cloud account, every observability surface, every on-prem feed, and every SaaS-vendor status target into the SRE agent’s read path. Two-to-four weeks for a team with reasonable platform-engineering capacity.

Phase 2 — Codify the cross-cloud runbook library. Express every production runbook in the agent’s runbook DSL with pre-authorized Operate-tier scopes. Run a tabletop exercise against the team’s three highest-frequency incident classes (deploy-induced regression, dependency outage, capacity-driven brownout) and measure cross-cloud MTTR. Two-to-three months of pattern tuning.

Phase 3 — Cross the SRE / cost / security agent loop. Cross-cloud incident signals are also cost-agent inputs (a capacity-driven brownout is a rightsizing event) and security-agent inputs (an anomalous traffic shift is a possible exposure event). Once the SRE-agent’s Observe layer is live, its signals feed the cost-agent’s optimization loop and the security-agent’s exposure-analysis loop. Each agent’s outputs make the others more accurate.

The combined effect is the same the platform team would get from hiring a senior cross-cloud SRE plus an incident-management specialist, except the agents run continuously, never miss a signal across the cross-cloud surface, and produce an immutable audit trail that satisfies internal audit, customer-trust review, and cyber insurance. For most mid-market platform teams, that is materially better than the current state.

AWS DevOps Agent is a strong product inside the AWS slice. The cross-cloud surface is still open, and the structural incentive to keep it open is not going away. The active operational layer is built for that surface, not for any one cloud.

Get a free infrastructure audit → | See pricing →