Between December 2025 and August 2026, every major cloud, every observability incumbent and every incident-management platform shipped an AI SRE agent, and a startup selling one raised at a billion-dollar valuation. That is not a trend piece. It is a procurement problem landing on your desk this quarter, and the vendor pages are written to make twelve different products sound identical. This is the comparison we wanted when clients started asking which one to turn on: what each agent actually does as of 1 September 2026, how far up the autonomy ladder it goes, where it needs your data to live, and what the bill looks like, sourced to each vendor's own documentation.
Key takeaways
- Twelve products, one shape. As of 1 September 2026 every agent here investigates first; whether it executes is decided by the policy you write, not by the vendor.
- Only AWS prints a dollar price ($0.0083 per agent-second). Azure meters in Agent Units without a public rate, Datadog bills in AI Credits, PagerDuty bundles "AI Actions" into its plans, and everyone else is bundled or undisclosed.
- Buy where your telemetry already lives. An agent can only reason over what it can query; MCP connectors keep the choice reversible.
- The vendor ships the engine. The runbook allowlist, the approval workflow and the spend cap are still your design problem, and that is SRE work.
What is an AI SRE agent?
An AI SRE agent is software that, when an alert fires, investigates on its own: it pulls telemetry, deployment history and code, proposes a root cause and a fix, and, depending on the product and your policy, carries the fix out. In 2026 every major cloud, observability and incident-management vendor ships one. They differ in where they can act, how much you must approve, and how they are billed.
The category went from demo to product in nine months. Datadog made Bits AI SRE generally available in December 2025. New Relic announced its SRE Agent on 24 February 2026, Resolve AI closed a $125 million round at a $1 billion valuation on 4 February, Microsoft took Azure SRE Agent to GA on 10 March, AWS DevOps Agent went GA on 31 March, PagerDuty's virtual responder entered early access in the second quarter and its connectors and tools went GA on 5 August, Grafana's Assistant Investigations reached GA on 29 July, and Dynatrace announced its Autonomous SRE Agent on 27 July for August availability. Gartner's projection that agentic IT operations will reach 70% of enterprises by 2029, from under 5% in 2025, which we quoted in April, no longer looks aggressive.
What has not changed is the underlying mechanics. An agent is an LLM in a loop with tools: it reads an alert, queries the systems it has been connected to, forms a hypothesis, queries again, and either writes up what it found or proposes an action. Every product on this page is a variation on that loop. The variations that matter to a buyer are the four columns in the table below.
The autonomy ladder: where each agent stops today
We use the same four rungs we set out in the Azure SRE Agent playbook, because the vendors do not share a vocabulary and "autonomous" on a landing page can mean anything from "writes a summary" to "restarts your database".
- Rung 0, investigate. The agent reads and reports. It touches nothing.
- Rung 1, advised. The agent proposes a specific change; a human approves each one.
- Rung 2, approved. The agent executes from a library of playbooks that humans wrote, reviewed and signed off in advance.
- Rung 3, guardrailed-autonomous. The agent decides and executes within hard limits: an allowlist of action verbs, a blast-radius cap, a budget.
As of 1 September 2026, most products ship at rung 0 or rung 1 by default. The ones that go further do it through policy objects you configure: Azure's permission gate and agent hooks, Dynatrace's policy-driven approvals, PagerDuty's incident workflows. Nobody sells rung 3 as a checkbox, and you should be suspicious of anyone who does.
The comparison
The hyperscalers: Azure, AWS and Google
Azure SRE Agent
The most complete product on the list, and the only one whose documentation describes a full extension model. An alert from Azure Monitor, PagerDuty or ServiceNow starts an investigation; the agent correlates the symptom with a deployment from GitHub or Azure DevOps, proposes mitigations and files the ticket with the write-up prefilled. Everything it might do passes through a permission gate that evaluates each proposed tool call, so rung 1 is the default and rungs 2 and 3 are choices you make per action with hooks. It reaches beyond Azure through more than forty managed MCP connectors, Datadog, New Relic, Splunk and Dynatrace among them. The same page carries the honest caveat that it "might occasionally produce incorrect conclusions", which is the right thing for a vendor to print. Our production playbook covers the 90-day rollout.
AWS DevOps Agent
Previewed at re:Invent on 2 December 2025 and generally available since 31 March 2026, built on Amazon Bedrock AgentCore. It learns application relationships, correlates telemetry with code and deployment data, and at GA gained the ability to investigate applications running in Azure and on-premises, custom skills, and reporting. It is the only agent on this page with a published dollar price: $0.0083 per agent-second, billed per second of active work, with a two-month trial and monthly credits for Business+, Enterprise and Unified Operations support plans worth 30%, 75% and 100% of the prior month's support charge. AWS's preview customers reported up to 75% lower MTTR and 94% root-cause accuracy; those are AWS's numbers, not ours.
Gemini Cloud Assist investigations
Google's entry is a root-cause tool rather than an agent that acts: investigations produce observations about your environment, a probable cause and recommended next steps, and can hand the whole thread into a Google Cloud support case. The gating is the story. Since 10 April 2026, creating, running and editing investigations requires a Premium Support contract or access requested through your account team. If you run on Google Cloud without Premium Support, the practical options are a third-party agent reading your telemetry, or waiting.
The observability incumbents: Datadog, New Relic, Dynatrace, Grafana
Datadog Bits AI SRE
First of the incumbents to reach general availability, in December 2025. Bits investigates end to end: it forms hypotheses, gathers the telemetry that would confirm or kill each one, and reasons toward a probable root cause so the on-call engineer opens a conclusion rather than a dashboard. It is billed in Datadog's AI Credits on top of the platform subscription. Its advantage is the obvious one: if Datadog already holds your metrics, logs, traces and deploy markers, the agent starts with everything it needs.
New Relic SRE Agent
Announced at New Relic Advance on 24 February 2026 as an "always on" teammate that diagnoses incidents and recommends next steps, often before an engineer has acknowledged the page. Responders query it from Slack and Zoom triage rooms; it captures the human context, runs fact-finding, impact assessment and root-cause analysis, and writes the post-incident report. The March update added Intelligent RCA, which searches the entity topology graph and applies probabilistic causal models, plus workflow automation (generally available), and a Performance Risks Inbox and Smart Alerts in preview. Pricing is the platform's, not itemised. New Relic's own report claims 25% faster resolution for users of its AI capabilities; treat that as a vendor figure.
Dynatrace Autonomous SRE Agent
Dynatrace introduced domain-specific agents for SRE, development and security teams, with policy-driven controls and approvals, on 28 January 2026, then on 27 July announced the Autonomous SRE Agent and an Agent Builder for August availability, alongside a Cloud SRE Agent and an enhanced Dynatrace Assist available immediately. The Autonomous SRE Agent triggers itself on newly detected problems, works out whether they belong to an investigation already under way, and enriches it. The pitch is determinism: Dynatrace's causal engine supplies the facts and the agentic layer acts on them, "not guesses". Pricing is not disclosed. If Dynatrace is your observability platform this is the one to trial; if it is not, the agent's value is bounded by what Dynatrace sees.
Grafana Assistant Investigations
In preview since October 2025 and generally available in Grafana Cloud since 29 July 2026. Point it at an alert or an incident and it explores metrics, logs, traces and profiles, builds hypotheses as it learns more, and produces a structured report with findings, evidence and recommended next steps; investigations can launch automatically from alert enrichment or a webhook. It stays at rung 0: the GA note describes a report with findings, supporting evidence and recommended next steps and lists no remediation capability; humans turn the findings into incident updates or follow-up tasks. For teams on the Prometheus and Loki stack that is precisely the shape they want, and it pairs naturally with an incident platform's agent for the execution half.
The incident platforms: PagerDuty, incident.io, Rootly
PagerDuty SRE Agent
PagerDuty's Spring 2026 release put the SRE Agent on the on-call schedule itself: the virtual responder can be added to schedules and escalation policies and begins investigating the moment an incident triggers, in parallel with the humans. The May enhancements added automated triage through Incident Workflows and connectors to Grafana, New Relic, Honeycomb, Splunk, Dynatrace, Confluence and GitHub. On 5 August PagerDuty took Connectors and Tools to general availability, wiring the agent to Grafana, New Relic and Datadog through MCP or API, made Incident Workflows for the agent GA, put escalation-policy membership and Skills into early access, and added team-level permissions so administrators can scope the AI to specific teams. The documentation is clear that remediation stays with the human, and it lists the limits you will hit: only the first 2,000 characters of custom details and notes are analysed, and conversations take up to 25 files of 100 KB. A fully autonomous responder was announced for early access in the second half of 2026. Packaging: PagerDuty Advance is required, plus AIOps to use it in the Operations Console.
incident.io Investigations
incident.io's Investigations run on a production-intelligence model it calls Nexus, reasoning across telemetry, deployments, code and incident history to produce root-cause hypotheses with confidence levels and cited evidence, a blast-radius map of affected services, and, where a code fix is the answer, a pull request. It states plainly that it never takes action without you: the change happens when a human reviews and merges. A detail we like: an adversarial agent challenges the conclusions before they are shown. The customer quotes on the page are the vendor's; the one from turbopuffer's CTO, that it found in minutes what took a human 30 to 60 minutes, is the shape of benefit we see in practice.
Rootly AI SRE
Rootly's agent is built into its incident platform rather than layered on top, so it starts with service ownership, on-call schedules and incident history already loaded. It begins investigating when the alert fires, correlates live telemetry with recent deploys, commits and config changes and with similar past incidents, and proposes probable root causes with confidence scores, suggested fixes and drafted updates. Every change requires explicit human sign-off before execution. It also reaches into engineers' editors through an MCP server, which is a sensible place for a fix to land. Pricing for the AI SRE is not published separately.
The specialists: Resolve AI and Traversal
Resolve AI
The category's unicorn: a $125 million Series A at a $1 billion valuation, led by Lightspeed, announced on 4 February 2026 with Coinbase, DoorDash, MongoDB, MSCI, Salesforce and Zscaler named as customers. Its agents join the on-call rotation, triage and investigate alerts, co-work incidents to root cause and run scheduled operational work, with engineers stepping in to direct and take action. The company claims up to 5x faster MTTR and 75% higher productivity; those are its numbers. What the round tells you is that large engineering organisations are paying for a standalone agent that reads across whatever stack they have, rather than waiting for their observability vendor's.
Traversal
Traversal came out of stealth in June 2025 with $48 million and positions itself as the AI SRE for complex systems: it builds a dependency map of the production estate, which it calls a Production World Model, and runs a causal search across services to isolate root cause, at what it describes as petabyte scale. Its published customer figures include a 38% MTTR reduction at DigitalOcean and root-cause accuracy of 75% to 82% at unnamed large enterprises; again, vendor-published. It is the most explicitly "acts unprompted" product on this list, so if you trial it, the evaluation questions in the next section matter more, not less.
What does an AI SRE agent cost?
Three pricing models exist as of 1 September 2026, and most vendors publish none of them. AWS meters agent time at a published $0.0083 per agent-second. Azure meters in Agent Units, a fixed always-on charge plus token-based active flow, without a public currency rate. Datadog and PagerDuty sell credits and actions bundled onto their platforms. Everyone else prices the agent inside the platform deal, which means the answer is whatever your renewal negotiation says it is.
The FinOps point is that the agent's own bill is a new line item that grows with your incident count, which is exactly the month you least want a surprise. Azure's monthly AAU cap and AWS's support credits are the two mechanisms that bound it today; for everyone else, ask for the metering model in writing before the pilot. We cover the broader pattern of agents as a runtime cost in FinOps for AI.
Should you buy the agent from your cloud, your observability vendor or your incident platform?
Buy the one that already has read access to the signals your incidents are made of. An agent is only as good as what it can query, so the vendor holding your metrics, logs, traces, deploy markers and incident history starts with a structural advantage no model can overcome. Everything else, autonomy, pricing, polish, is secondary to that, and MCP connectors now make the choice reversible.
In practice that produces three honest answers. Single-cloud, native-observability shops should start with the cloud's agent: Azure SRE Agent and AWS DevOps Agent both read across clouds now, Azure through MCP and AWS by investigating Azure and on-prem applications directly, so the choice does not trap you. Teams whose telemetry lives in Datadog, New Relic, Dynatrace or Grafana Cloud should trial that vendor's agent first, because a second copy of the data is the expensive part. And teams whose incident process is the strongest asset, with real ownership data, schedules and retrospectives in PagerDuty, incident.io or Rootly, often end up with two agents and a division of labour: the incident platform's agent triages and coordinates, the observability agent investigates, and MCP is the seam between them.
The wrong answer is to buy the one with the best demo. Demos run on the vendor's data, and the vendor's data is complete.
How do you evaluate an AI SRE agent before letting it near production?
Run it at rung 0 against your own last twenty incidents and measure how often its root cause matched the one your engineers found, then check six things before you let it propose a single action: the audit trail, the permission model, the blast-radius cap, the spend cap, the data-residency exclusions, and what leaves with you if you switch it off.
- Audit trail per action. Every proposed and executed action logged with the agent's reasoning, routed to your own log store. Azure routes audit telemetry to your Application Insights; ask each vendor where theirs goes.
- Permission model. Can you require approval per action class, allowlist verbs, and block the rest? A product without this cannot be run above rung 1 safely, whatever its marketing says.
- Blast-radius cap. A limit expressed in your terms: n pods or n%, one region, one service, and never the database.
- Spend cap. A hard monthly limit on the agent's own consumption. Azure has one; AWS bounds it with credits and trial hours; for credit-based products, ask what happens at zero.
- Residency and exclusions. Google's investigations require Premium Support; several agents are not offered in every region or government cloud. Regulated teams should get the exclusions list in writing before the pilot.
- Exit. Most agents accumulate "institutional knowledge" from each investigation. Ask whether that knowledge is exportable, or whether it is the lock-in.
The rung-0 trial is the part teams skip, and it is the part that matters. Twenty past incidents, replayed, give you a precision number for the agent on your system rather than the vendor's. If it finds the real cause in fewer than half, it is a summariser, and you should pay for it as one. If it clears that bar, the 90-day rollout from our Azure playbook works for any of the twelve: advised mode on the top twenty runbooks, then three pre-approved playbooks, then a data-driven decision about rung 3 on a single allowlisted runbook.
What none of them do yet
None of the twelve sets your SLOs, writes your error-budget policy or decides what reliability your users actually need; they optimise inside a definition of "good" that a human still has to supply. All of them are bounded by alert quality: an agent that starts from a noisy page starts from noise, and 44% of 2025's outages began with an alert someone had learned to ignore. Microsoft's documentation says the agent "might occasionally produce incorrect conclusions or propose mitigations that don't apply to your environment"; assume the same of the other eleven, because the mechanism is the same. The knowledge every vendor promises to accumulate is also the stickiest form of lock-in yet invented for operations tooling. And none of them carries the pager's accountability. When the agent is wrong at 3 a.m., the name on the incident is still a person's.
Our take
In 2026 the model stopped being the differentiator. Every vendor on this page can investigate an alert competently when it holds the data, and by next year the ones that cannot will have bought a startup that can. The differentiator is now the policy your team writes around the agent: which runbooks it may touch, at what blast radius, under what budget, with what evidence required before it acts. That is SRE work, not procurement, and it is the same work whether the logo on the agent is Microsoft's or a startup's.
Our recommendation to clients this quarter is unglamorous. Pick the agent that already reads your telemetry. Run it at rung 0 for thirty days and measure it. Promote it to advised mode on the runbooks you already trust. Write the allowlist and the spend cap before anyone asks for rung 2. If your team does not have the time to do that policy work, that is the engagement to buy, before the agent, not after; it is what SRE consulting looks like in 2026, and it is why the honest answer to "is AI replacing SRE?" is still no.
Related: Azure SRE Agent: the production playbook · The alert fatigue trap · SRE consulting services · How to choose an SRE consultancy · Uptime & SLA calculator