How complex is it to build your own AI SRE agent?

This post is written for the platform lead or architect who has already pointed Claude at a cluster and thought "we could build this." You could. This is an honest accounting of what "this" actually is, so the build vs buy AI SRE decision is made with the real number, not the demo.

How hard is it really?

The demo is genuinely a weekend of vibe coding. Wire an LLM to kubectl, point it at a failing pod, and it will read the logs, spot the CrashLoopBackOff, and suggest a fix. That part is real and it already feels impressive.

The distance from that to a DIY AI SRE agent running unattended against production is roughly 5 to 7 senior engineers for a year, and then a dedicated team after that. We already published the breakdown behind that estimate in From dev agent to SRE agent: eight problems that a better prompt does not touch and that a better model mostly does not either.

The number that surprises people is not the build. It is the "and then a dedicated team after that." An AI agent in production is not a project you finish. It is a program you staff, for the same reason a monitoring stack is not a project you finish.

Why doesn't the weekend demo survive production?

The demo answers "what just broke?" for one engineer at one keyboard, in office hours, on one cluster, with your own credentials, watched the whole time. Production removes every one of those conditions at once. There are eight obstacles: solving one badly weakens the others.

The line that separates the two worlds is autonomy. As we put it in that post: a dev agent always has a human at the root of the trigger tree. An SRE agent doesn't. A coding assistant acts because a person asked it to, right now, and reviews the diff. An SRE agent has to act on an alert at 3 a.m. with nobody watching, which turns every one of the other seven obstacles from a convenience into a safety requirement.

What does maintenance actually cost after launch?

More than the build, over time, because the ground keeps moving. We call it the AI treadmill, and it is the strongest argument against a one-time DIY build.

Two concrete examples from the last eighteen months.:

• The state-of-the-art model in one quarter is beaten the next, so frontier evaluation is a continuous benchmarking job, not an annual review.
• The integration layer itself churned: MCP (the Model Context Protocol) server downloads grew from roughly 100,000 to over 8 million inside a year, and then, within months, the fast-moving teams started shifting from MCP back toward CLI-native tooling because models handle interfaces they already saw in training more cheaply than bespoke protocol schemas that cost tens of thousands of tokens before the model does any work.

A team that shipped a DIY AI SRE agent on MCP in 2025 owns that decision as a maintenance liability in 2026. That is the shape of the cost: not the first version, but keeping the first version from becoming a security and performance drag. A built agent is a staffed program, not a delivered project.

What are the security risks of a self-built agent?

An SRE agent is close to the worst case in the OWASP threat models for LLM and agentic applications, because it does three dangerous things at once: it reads attacker-influenced data (a log line an attacker can write into), it holds production credentials and it runs unattended. Most AI security guidance assumes at most one of those. An SRE agent has all three.

We walked through the specifics against the two OWASP lists in What the OWASP LLM Top 10 means for AI SRE agents and What the OWASP Top 10 for Agentic Applications means for AI SRE agents. The short version: MCP server security is not a solved problem you inherit for free. Public CVE trackers logged seven MCP-server vulnerabilities in a single month last year, with path-traversal flaws in most analysed implementations, as we detail on the Hyground vs DIY comparison. Prompt injection through tool poisoning is a documented attack, not a hypothetical.

This is where the build case most often dies, and not on technical grounds. An ungoverned agent holding production credentials is a clean CISO veto. It does not matter how good the root-cause analysis is if the security review cannot answer "what can this thing do, who approved it, and where is the audit trail." If you build, you are also building the answer to that question, which is arguably harder than the agent.

Has anyone serious actually built one?

Yes, and the public record is the best evidence for the true cost. Ant Group open-sourced OpenDerisk, an AI SRE system reported to serve more than 3,000 daily internal users (arXiv:2510.13561). It is not a weekend hack. It is a multi-year engineering effort from a large platform organisation, documented as a research contribution. That is what "serious build" looks like: the resourcing of a product team, not a side quest.

The research also shows the problem is deeper than plumbing. A recent study using the STRIDE framework (arXiv:2512.02228) finds that even choosing the right AI modality for a given operations task is itself an open research question, not a settled engineering pattern you can look up. So a DIY build is not just integrating known parts. In places it is doing original research to decide which parts to use, and that research expires as the field moves.

When is building the right call?

Build when at least one of these is true, and you are honest that all of them carry the treadmill cost:

• You are a very large platform organisation that already staffs a standing team for internal tooling and can absorb continuous model, integration, and security upkeep as a line item.
• Agentic AI for incident response is your actual product, so the build is your value, not your overhead.
• Your environment is genuinely unusual enough that no vendor covers it, and a thin buy-plus-glue approach will not reach.

If you are OpenDerisk's Ant Group, building is defensible. For most enterprises, the honest read is that you are choosing to run a permanent AI platform team to avoid a licence, and the treadmill makes that a worse trade every quarter.

What should you demand if you buy instead?

If you buy, do not buy a chatbot with production credentials. Buying does not remove the eight obstacles or the OWASP risks; it moves the burden of solving and maintaining them to a vendor. So make the vendor prove it. A neutral checklist, which any serious platform should pass regardless of who made it:

• In-cluster deployment. The agent runs inside your perimeter, not as a SaaS that ingests your telemetry and holds your credentials off-site.
• Model-agnostic. You choose the model and can swap it, including self-hosted, so you are not locked to one vendor's treadmill position.
• Read-only by default. Investigation never requires write access. Actions are opt-in.
• Gated, audited writes. Any action taken on your behalf is behind explicit human approval and lands in an audit trail.
• A central audit trail and access control. One shared instance with SSO and role-based access, not credentials scattered across laptops.
• Maintained integrations. The vendor tracks CVEs and the model and protocol churn for you, and ships the updates. That is the treadmill you are paying them to run.

We built Hyground against exactly that list, and you can hold it to the list yourself. If Claude Code specifically is your reference point for building, Hyground vs Claude Code covers where a coding agent stops and an SRE agent has to begin.

What this does not solve

Buying does not make the hard parts of incident response disappear, and any vendor claiming it does should lose your trust. An AI SRE agent, built or bought, does not decide on its own that an incident is over, does not take irreversible production actions without a human, and does not replace the judgment of the engineer who owns the service. It compresses the investigation, links its findings to evidence you can check, and hands you a decision faster. That is the honest ceiling. The value is in getting a well-evidenced answer at 3 a.m. without first spending a year building the platform that produces it.

If you want to judge build vs buy for yourself, the fastest way is to watch one run against a real cluster. Book a demo.