Why AI SRE Agents Need A Platform
Most AI SRE agents work in silos. None give teams the shared access, memory, and approval rules to work production incidents safely together.
Every major observability and cloud vendor now ships an AI SRE agent, and each one works in a silo, built around its own vendor's data, its own cloud, and its own pricing meter. An enterprise ends up with several agents, each with its own access, its own memory, its own approval rules, and its own bill, and none of them sees the whole incident, which runs through clouds, databases, deploy pipelines, and ticketing systems as well as observability tools. AI SRE agents need a platform that gives every agent and every engineer one set of access, memory, and governance across the entire estate.
I've watched plenty of AI SRE agents impress in a demo. The demo runs on the vendor's own data, in the vendor's own cloud, and a real incident rarely stays in one system. When Cloudflare went down on November 18, 2025, its postmortem traced the HTTP 5xx errors its customers saw to a permissions change in a ClickHouse database. The change doubled the size of a configuration file that Cloudflare's proxy loads, the proxy failed on the oversized file, and because good and bad versions of the file alternated every few minutes, engineers first suspected an attack. The errors showed up in the proxy, and the cause sat in a database and the pipeline that generated the file. An AI SRE agent that sees only the proxy's telemetry would chase the same attack theory, because the evidence for the real cause lives in systems that agent cannot see.
How far do today's AI SRE agents go?
An AI SRE agent investigates production incidents, finds the root cause, and proposes a fix. Observability vendors (Datadog, Dynatrace), cloud providers (AWS, Microsoft), incident platforms (PagerDuty), and independent startups all offer one, and our guide to AI SRE tools covers the wider market. Many teams also build their own on coding agents such as Claude Code.
Several vendor agents already have pieces of what a platform needs: Azure SRE Agent keeps context from prior investigations and has a Review mode that holds write actions for approval, and AWS DevOps Agent builds learned skills from a team's investigation patterns. Each of those mechanisms works inside one vendor's product, for that vendor's agent.
Vendor AI SRE agents work in silos. Each one keeps its memory and approval controls inside its own product, built around its own vendor's data and cloud.
How do the Datadog, Dynatrace, AWS, and Azure AI SRE agents work?
Each vendor agent starts from its vendor's own data and reaches the rest of the stack through integrations, and each one is billed on a different meter:
| Agent | Built around | Reaches other tools through | How it is billed (published list price) |
|---|---|---|---|
| Datadog Bits AI SRE | Datadog metrics, logs, traces, and service maps | Integrations with GitHub, Grafana, Splunk, Dynatrace, Sentry, and ServiceNow, listed by Datadog as Preview | AI credits: $500 per 500 credits a month on a plan, or $1.30 per credit on demand, with an autonomous investigation estimated at about 4 credits |
| Dynatrace Intelligence | Data stored in Dynatrace Grail, mapped by Smartscape topology | Ecosystem agents and the Dynatrace MCP server | Agentic Operations at $0.10 per AI unit, about 30 units for an autonomous multi-step investigation, on top of host monitoring and log ingest |
| AWS DevOps Agent | Amazon CloudWatch and AWS resources | Datadog, Dynatrace, New Relic, Splunk, Grafana, GitHub, GitLab, ServiceNow, PagerDuty, and Slack; Azure and on-premises through MCP | $0.0083 per agent-second, with queries to services such as CloudWatch Logs Insights billed separately |
| Azure SRE Agent | Azure resources, Azure Monitor, and Application Insights | MCP connectors for Datadog, Splunk, New Relic, Dynatrace, and Elasticsearch | Azure Agent Units: 4 units per agent-hour from creation until the agent is deleted, plus token-based charges while tasks run |
Each agent reaches its own vendor's data directly and everything else through a connector. Datadog still lists Bits AI SRE's connectors to rival products such as Splunk and Dynatrace as Preview. Each meter also sits on top of another charge: Bits AI SRE's credits on top of the Datadog products it investigates, Dynatrace's AI units on top of host monitoring and log ingest, AWS DevOps Agent's agent-seconds on top of the CloudWatch queries it runs, and Azure SRE Agent's agent units on top of token charges while tasks run.
Each vendor AI SRE agent works best on its own vendor's data and bills on its own meter, on top of the bill for the data it investigates.
What do vendor AI SRE agents lack for the enterprise?
Vendor AI SRE agents lack a shared layer across vendors. Enterprise incidents look like Cloudflare's: the observability tool shows the errors, while the cause sits in a database, a feature flag, a cloud provider's service, or a pipeline change in GitHub Actions, and the response is tracked in ServiceNow or Jira. That holds even for an enterprise with a single observability tool. An enterprise on AWS and Azure with Datadog as its observability tool could end up running three of these agents: Bits AI SRE, AWS DevOps Agent, and Azure SRE Agent.
- Access. Each agent holds its own credentials and its own connectors to the other vendors' tools. Security teams review, scope, and revoke access agent by agent.
- Memory. The context Azure SRE Agent retains stays in Azure SRE Agent, and the skills AWS DevOps Agent learns stay in AWS DevOps Agent. A fix one agent verified is invisible to the others and to the engineers using them.
- Governance. Each agent has its own approval model, configured in its own console. Nobody can answer from one place what any agent may change in production, who approved it, and what it did.
- Cost. Each agent bills on a different unit (credits, AI units, agent-seconds, or agent-hours), on top of separate charges for the data it queries. Forecasting the total means modeling every meter against incident volume.
- Other agents. The coding agents developers already use, such as Claude Code and Cursor, get none of this context or governance unless someone wires each one up separately.
Each agent on its own
Every agent on one platform
An enterprise running several vendor AI SRE agents gets several partial views of production, several separate memories, several approval models, and several meters, with nothing tying them together.
What does an AI SRE agent need from a platform?
An AI SRE agent needs a platform where access, memory, governance, and collaboration work as one system across every vendor's tools, for every engineer and every agent:
| Mechanism | Vendor AI SRE agent | AI SRE agent on a platform |
|---|---|---|
| Access | Direct to its own vendor's data, connectors to the rest | One governed connection to every tool, queried in place |
| Memory | Kept inside that vendor's agent | Verified fixes and engineer corrections shared by every engineer and agent, with zero telemetry storage |
| Governance | That agent's own approval model and audit log | One Suggest, Recommend, Act policy set per environment, with configurable human approval gates and one audit trail |
| Collaboration | That vendor's console plus the chat and ticketing tools it integrates with | Engineers review the evidence, correct the agent, and approve the fix in Slack, Teams, PagerDuty, Jira, or ServiceNow |
| Other agents | Serves its own users | Serves the same context to Claude Code, Cursor, and in-house agents over MCP |
| Cost | A separate meter per vendor, on top of that vendor's data charges | One platform that queries data in place and uses tokens efficiently |
An alert handled this way ends with something the whole on-call rotation can check and act on in under 5 minutes: the change that caused it, evidence from every tool involved, a staged fix waiting on a named approver, and a record the next engineer and the next agent will both find. We wrote about how that approval loop earns an agent more autonomy over time in Earned Autonomy.
An AI SRE agent needs a platform: one system that gives every engineer and every agent the same access, memory, and approval rules across every vendor's tools.
Should you build your own AI SRE agent or buy one?
You should do both. Your in-house agents and coding agents such as Claude Code and Cursor are built around your own systems and workflows, so they can aid in your incident response process. A platform team can build a working in-house AI SRE agent in weeks, but keeping that agent accurate, secure, and current takes engineering time for as long as the agent runs: evaluation and regression testing every time the model changes, permission and audit controls, and rebuilding knowledge when the engineers who built it move on. Our CEO, Goutham Rao, showed in The Real Cost of Building Your Own AI Agents that this upkeep, not inference, makes up nearly all of what an in-house agent costs. Every team that builds its own access, memory, governance, and collaboration pays that cost again, so build the agents that set your business apart and run them on a platform that already provides the rest.
NeuBird engineers build and support the Production Ops Agent for context engineering, investigation accuracy, and cost-efficient infrastructure. The tools and agents you already run are integral to your own initiatives, so NeuBird is built to make them plug-and-play: they connect to the same platform over MCP and get the same access, memory, and guardrails.
An in-house agent on its own often queries one source at a time and copies raw logs, metrics, and traces into its context window. On NeuBird's Agentic Reliability Center (ARC), the same agent gets tailored context from every source, queried in parallel and in place, with roughly 90% less token waste. The trade-offs of building on your own versus building on a platform are laid out in NeuBird vs. in-house agents.
Your in-house agent · on its own
One source, then the next
MetricsLogs
Traces
DeploysYour in-house agent · on ARC
Every source, at once
MetricsLogsTracesDeploysBuild your AI SRE agents and keep your vendor tools, then run them all on one platform that gives every engineer and agent the same access, memory, and rules.
How does NeuBird give AI SRE agents a platform?
NeuBird pioneered the AI SRE, then grew it into the Production Ops Agent, powered by the Agentic Reliability Center (ARC). Better agents require better context. To make our own agent accurate and safe, we built ARC beneath it, and we now open that same platform over MCP to every agent and IDE tool our customers use.
The Production Ops Agent works across vendors by design. It queries 15+ sources in parallel across 50+ integrations, including Datadog, Splunk, Dynatrace, PagerDuty, AWS, Azure, GCP, Kubernetes, and GitHub, in place. It isolates the causal chain and the offending commit in under 5 minutes at 94% accuracy and shows the evidence for each link, so the engineer can verify the conclusion before anyone acts on it.
ARC provides the mechanisms around that investigation as one system. It queries your tools in place and uses tokens efficiently, at roughly 10% of the cost of alternatives. It records verified root causes, fixes, and engineer corrections, with their authors, as institutional memory with zero telemetry storage: the memory holds conclusions, while logs, metrics, and traces stay in the tools that produced them. It serves tailored context to your engineers in Slack, Teams, PagerDuty, Jira, and ServiceNow, and to Claude Code, Cursor, and your own agents over MCP. Every action, from any agent, goes through the same Suggest, Recommend, Act policy set per environment, with earned write access and one audit trail.
Keep the AI SRE agents and the vendor tools you run today, and put them on one platform where your engineers and agents work production together. Book a demo and bring the agents you already run.
