SRE was never supposed to be a ticket queue with a pager. It was supposed to be an engineering function that used software to reduce toil, bound risk with error budgets, and make product teams capable of operating what they ship.
That charter does not change. The staffing model does. A large fraction of current SRE time is mechanical: acknowledging alerts, collecting diagnostics, writing the same status update, grepping logs for an error string that is already in the trace. That work has a structure. It can be turned into tools. The work that remains is judgment, and the design of the loop that feeds it.
What disappears, and what does not
Known failure classes should stop paging humans twice. Expired certificates, disk pressure on a stateless pool, a replica count that drifted, a canary that already failed its SLO check — these are control-plane problems. If they still require a person to run a runbook, the platform is unfinished.
What does not disappear is judgment under uncertainty. Error-budget policy when the product team wants to ship and the SLO is burning. Whether to fail open or fail closed. Whether the canary is lying because the traffic mix is wrong. Whether the agent that wants to bounce the StatefulSet has actually identified the cause, or has correlated two charts that share a time axis and nothing else.
IBM’s ITBench put a number on the gap: 13.8% autonomous resolution on SRE scenarios. The future team is not a person watching an agent that is already right. It is a person who can tell when the agent is wrong, and a platform that makes that determination cheap. If your on-call cannot read a NetworkPolicy, a histogram, or a traceparent, they cannot supervise the system that is guessing about all three.
The job becomes designing the control loop
The SRE of the next few years looks more like a reliability architect than a full-time incident commander. The artifacts they own are the ones an agent cannot invent.
SLIs that an agent can consume. If your availability SLI is a synthetic that does not share label space with the traces, the agent cannot join them. Golden signals need stable, low-cardinality dimensions: service, route, region, status_class. User IDs do not belong on metrics. They belong on traces, reached through exemplars. Burn-rate alerts still matter; they are the interrupt. The investigation graph has to be walkable from that interrupt without a tribal map of dashboard folders.
Topology and ownership as data. kubectl get svc is not a dependency graph. A service catalog that knows who owns checkout, what it talks to, which SLO it is on, and which deploy pipeline produced the current ReplicaSet is the difference between an agent that pages the right person and one that pages the platform team because that is who still answers. If ownership is a wiki table, it is already wrong.
Runbooks as APIs, not documents. A markdown file is not executable. A runbook that is a versioned workflow — inputs, diagnostic queries, mitigation actions, rollback conditions — can be retrieved, executed in a sandbox, and evaluated. Crossplane Operation types are one way to make day-two work a Kubernetes object. The important part is not the vendor. It is that operational knowledge stops living only in the people who have been here longest.
Evals, not vibes. We already do this for services: SLO, error budget, burn-rate alerts. Agent behavior needs the same treatment. Take the last N incidents, freeze the telemetry snapshot, and score: time to first correct hypothesis, citation precision, whether it proposed a mutation that would have made things worse. Promotion criteria should look like error-budget policy. Recommend-only until the eval is green. Approval-gated mutation next. Auto-remediate only for a named, reversible class with a tested rollback.
Permission design. Read versus mutate is not enough. Mutate has blast radius. Restarting a stateless Deployment is not failover of the primary database. The future on-call rotation reviews proposals above a blast-radius threshold and ignores the rest, the same way we already ignore alerts that are not tied to user-facing SLIs. RBAC for the agent should be narrower than RBAC for the human, not copied from the cluster-admin break-glass role.
Team shape
I do not think most companies need a separate “AI SRE” organization. That creates a seam between the people who understand the system and the people who understand the model. The competency belongs inside the existing reliability and platform function. A dedicated team is justified when you have thousands of AI-enabled workflows, a model platform of your own, or a regulator who will ask how the agent was evaluated. Everyone else should embed it.
The mix of skills on that team does change:
- Distributed systems, Linux, networking, and Kubernetes remain table stakes.
- OpenTelemetry fluency, including the unglamorous parts: resource attributes, context propagation, exemplar pipelines, Collector processors that silently drop attributes.
- Retrieval systems. Incident memory is a RAG problem over postmortems, runbooks, and config history. Embeddings over unstructured wikis will retrieve the wrong runbook. Structure the corpus first.
- Policy as code. OPA, Kyverno, admission control. The agent should be subject to the same gates as a human applying a manifest.
- Product sense for internal platforms. The SRE team that still takes every ticket will not have time to build any of the above.
Staffing-wise, expect fewer people on the pager for known failure classes, and more people building the context layer those agents depend on. On-call does not go away. The page that remains should be novel, or it should be a policy decision. Google’s guidance of no more than two events per shift is still the right load test for the human part of the loop. If you are above that, you do not have an AI problem. You have an SLO, alerting, or platform problem.
Burnout is a systems problem
DORA’s 2025 archetypes are worth taking seriously. AI that increases throughput without increasing stability lands on on-call. The teams that are fine have platforms, fast feedback, and psychological safety. The others get a faster way to produce pages.
The future SRE team looks different because the work that was toil gets automated, the work that was tribal knowledge gets encoded, and the work that was judgment gets concentrated. If you skip the encoding step and just buy a copilot for Grafana, the team will look the same, only more tired.