What Will AI SRE Look Like in the Next 5 Years?

The forecast at a glance

First: the category settles

These are the changes we expect to see in the next one to two years, as buyers and vendors start to agree on what an AI SRE actually is.

AI SRE tools get sorted into four levels of autonomy

Today, most vendors describe their tool in one of two ways: "read-only" (it only looks) or "autonomous" (it acts on its own). We think buyers will soon ask about four clear levels, by name:

• Read-only. The AI looks at your systems and tells you what it found. You do everything else.
• Suggest. The AI proposes a fix. A person applies it.
• Approve-to-apply. The AI applies the fix, but only after someone clicks approve.
• Autonomous. The AI applies fixes on its own, inside limits your team agreed on in advance.

The AI thinks in the vendor's cloud but acts inside yours

Large companies are settling on a setup with two parts. The "brain" is the AI model, its reasoning and its memory. It runs in the vendor's cloud. The "harness" is everything that touches your systems: permissions, running commands and reading data. It runs inside your own network (your VPC, or virtual private cloud).

With this setup, your logs stay inside your infrastructure, and the vendor never holds permanent login access to your production systems.

Every AI SRE will write your postmortem for you

A postmortem is the report a team writes after an incident. It explains what broke, when, why, who was affected, and what the team will do so it does not happen again. Writing one usually takes a senior engineer two to four hours. It is also the step teams skip most often, because once the problem is fixed, nobody wants to spend an afternoon writing about it.

Within a couple of years, every AI SRE product will write the first draft for you. The AI reads the incident's Slack thread, builds the timeline from your logs and alerts, adds the key screenshots, and hands you an almost finished report to edit.

Once every tool can do this, buyers will compare the quality of the drafts. Three things decide quality:

• Is the timeline right? AI often gets the order of events wrong, or blames the wrong deploy.
• Are the action items useful? A good draft says "add a canary deploy for the payments service." A weak one says "improve monitoring."
• How much does a person have to rewrite? If the engineer rewrites 80% of it, the feature saved no time at all.

AI agents make observability bills go up

An AI agent runs far more searches than a person does. When an engineer investigates an incident, they might run a handful of queries. One automated investigation (often called an RCA, or root cause analysis) can run dozens of log searches, metric queries and trace lookups.

So bills from tools like Datadog, New Relic, Honeycomb and Grafana Cloud start going up, even though no person changed how they work. Finance teams will start asking vendors to prove they are not inflating the bill, and someone will publish the first serious study of this "AI SRE observability tax".

Then: the tools reorganize

Once the basics are settled, the tools around AI SRE start to change shape. We expect these shifts in the middle of the five-year window.

Many specialist AI agents replace one general agent

Teams will run several specialist agents: one for databases, one for Kubernetes, one for the network, one for unusual cloud costs. Each one knows its area deeply. The vendor's job becomes coordinating that team of specialists.

"Agent Ops" becomes a real job title

Someone has to look after the AI. That means watching the decisions it makes, reviewing its postmortem drafts, changing what it is allowed to do, and noticing when its reasoning starts to slip. Today, senior SREs do this on top of their normal job. We think it becomes a proper role within three years, usually sitting next to the platform engineering team. By the end of the five years, a senior Agent Ops engineer will earn as much as an SRE, or more.

AI SRE joins the deploy pipeline

When something breaks, the first question is usually "which deploy caused this?" Today, getting from the alert to the deploy takes a few steps. Soon it will take none. Deploy tools like Argo, Spinnaker and CircleCI will either buy AI SRE products or build the same ability themselves. The AI will see the code change that caused the incident before a person does.

Observability tools start charging differently for AI traffic

We expect Datadog, New Relic and Grafana Cloud to add separate pricing for queries made by AI agents, either as a new tier or as pay-per-use. The push for this will come from customers. The first vendor to publish clear, AI-aware pricing will win a large share of AI SRE customers.

Finally: the job changes

The biggest changes take the longest. By the end of the five years, we expect the people and the rules around reliability work to look different too.

The SRE job title splits into three

"Site Reliability Engineer" is heading the same way "Webmaster" went by 2008. The work splits into three clearer jobs:

• Platform Engineer: owns infrastructure as code, networking and provisioning.
• Reliability Engineer: owns SLOs (the reliability targets a service has to meet), on-call and how the team handles incidents.
• Agent Ops Engineer: owns the AI SRE agents.

Teams that still use the "SRE" title will mostly be small teams where one person does all three jobs, or teams that keep the title because of how pay is set.

The AI joins the on-call rotation

In the long run, every page goes to a mixed team. The AI SRE looks first. It adds context to the alert and checks recent deploys. For small incidents, it fixes the problem itself. For everything else, it hands over to the human on-call, with a draft root cause analysis already waiting in the Slack thread.

The AI is treated as a member of the rotation. It has a clear set of things it is allowed to do. It can be taken off the rotation if it behaves badly. Its decisions are reviewed in retrospectives.

Compliance rules start treating AI agents as their own kind of identity

Security and compliance standards like SOC 2, ISO 27001, HIPAA and PCI DSS will treat AI agents as their own category of identity. That means separate rules from both human users and service accounts. Audit logs will need to record the agent's reasoning as well as its actions. Tools that manage these identities, like Oasis Security, will become standard. Rotating an agent's credentials will become as routine as rotating a person's password is today.

A new layer appears above AI SRE

Every few years, a new kind of reliability tool appears that looks at a bigger part of the problem than the last one:

• Monitoring tells you what broke. "The payments service is down."
• Observability tells you why it broke. "The payments service is down because the database connection pool is full."
• AI SRE investigates the whole thing for you. "Payments is down because the connection pool is full. Last Tuesday's deploy caused it. Here is the fix."

The next layer stops focusing on single incidents. It looks for patterns across many incidents and tells you when the design of your system is causing the same incidents to repeat.

For example, imagine a tool that says: "Your region failover has triggered 14 times in six months. Your setup is the cause, and this is what to change." The tool is less concerned with tonight's incident and more with why the same incident keeps coming back.

What stays the same

We expect three things to stay the same over the next five years.

Production stays messy. Automation reduces the mess in production, and some of it will always remain. The incident of the future will still have one engineer who did not read the Slack thread, one dashboard showing the wrong thing, and one deploy that went out before anyone noticed.

People still make the final call. Even when an AI can fix things on its own, a person decides whether it is allowed to. That decision stays with people. In five years, a senior reliability engineer will spend less time fixing incidents and more time deciding how much to trust the AI agents they manage.

Security review still decides every deal. The specific checks will change over time. Any AI SRE vendor that cannot clearly answer "what can this agent access, who approved that, and what gets logged?" will struggle to win enterprise customers, today and in five years. Our Azure integration page shows how we answer this for our own agent.

How to use this forecast

If you are buying an AI SRE tool, use this as a checklist. The questions that will matter in five years start to matter in two. Ask vendors now which autonomy level they sit at, how they keep AI query costs down, and whether they are moving toward specialist agents or sticking with one big agent.

If you are building one, use it as a map. What you build this quarter will ship into the market described in the later sections.

If you are an engineer, use it to plan your career. "Agent Ops" roles are rare on job boards today. We expect them to be common within two years, and people who build these skills early will be well placed.

Frequently asked questions

The one line to end on

Five years from now, AI SRE will look less like a product you buy and more like a layer of how you run production. Buyers will care less about whether a product uses AI, and more about what the agent can do, what it can access, how much damage it could cause, and what it owns.

We plan to revisit these predictions and check how they held up.