How AI Is Actually Changing SRE Tools, Part 2: ITOps, Chaos Engineering, and the Rest of the Job

In Part 1, I walked through how AI is changing incident response, from correlation engines like BigPanda and PagerDuty's AIOps features to a newer category of dedicated AI SRE agents like Traversal, Resolve.ai, and Cleric that investigate incidents autonomously instead of just clustering alerts you already collected.

Incident response gets the spotlight because it's the loudest, most visible part of the job. But if you actually track where an SRE's week goes, a good chunk of it isn't firefighting at all. It's ITOps tickets, chaos testing, SLO math, on-call scheduling, and the slow grind of writing and maintaining runbooks nobody reads until 3 a.m. This second part covers where AI is showing up in all of that, with the same rule I applied in Part 1: vendor-reported numbers get flagged as vendor-reported, and I say plainly where adoption is still low regardless of how good the tooling has gotten.

ITOps: A Slower But Real Shift

ITOps has been slower to change than incident management, partly because the data is messier. CMDB entries are stale, ticket categories are inconsistent, and a lot of ITOps work still runs through change advisory boards that move at the speed of a Tuesday meeting.

Even so, a few areas have real AI traction:

• Predictive capacity planning. Rather than static thresholds ("alert at 80% CPU"), some platforms now model usage trends and flag capacity issues days before they'd trip a traditional threshold.
• Automated ticket triage and routing. Classifying a ticket and routing it to the right queue used to be a rules engine with hundreds of brittle conditions. Language models handle the free-text classification part noticeably better.
• Change risk scoring. A few platforms now score proposed changes against historical incident data to flag "this type of change caused an outage 3 of the last 20 times." Useful as a second opinion, not a replacement for review.

I covered the automation side of this shift, provisioning and managing the infrastructure these ITOps tools sit on top of, in more depth in Infrastructure as Code: How Automation Evolved to Power AI Workloads and Cloud Automation Excellence: Terraform, Ansible, and Nomad for Enterprise Architecture. ITOps AI features are only as good as the infrastructure state they're reasoning about, and that state is usually managed by exactly these kinds of tools.

Beyond Incidents and Tickets: The Rest of the SRE Job

The point of this diagram is that the reactive stuff on the left only gets easier if the proactive and human-layer work on the right actually happens. A great incident agent bolted onto a team with no SLOs and a runbook wiki nobody's touched in two years will still struggle.

Chaos Engineering Gets a Reasoning Layer

Chaos tools like Gremlin, Steadybit, and Harness's chaos engineering module used to require someone to manually design experiments: pick a service, pick a failure mode, guess a reasonable blast radius. That design step is where AI is actually helping now. Harness added generative capabilities that analyze your architecture and operational data to suggest which experiments would teach you the most, instead of you guessing. Steadybit went further and shipped what it calls the first MCP server built for chaos engineering, letting LLM agents query past experiment results directly. That's the same protocol-level pattern I wrote about in MCP vs Skills vs Agents With Scripts: giving an agent a standardized way to query a tool's data instead of scraping a dashboard. In practice, it means an incident investigation agent could eventually ask "have we ever tested this failure mode before" and get a real, structured answer instead of nothing.

Worth saying plainly: adoption here is still low industry-wide. Independent research from LogicMonitor's 2026 SRE Report found that resilience engineering is widely valued on paper, but production chaos testing remains uncommon, and many organizations still have low tolerance for deliberate failure injection. AI lowers the design cost of running an experiment, but it doesn't fix the organizational nervousness about deliberately breaking things, and that's a culture problem no agent solves for you.

SLOs and Error Budgets Get Easier to Set Up, Not Easier to Enforce

Tools like Nobl9 have leaned into AI mostly at the setup stage: pointing at your existing observability data and proposing a reasonable SLO instead of making you guess a number out of thin air, and flagging when a service's error budget burn rate suggests you should stop shipping features and go fix things instead. That second part, "should we stop shipping," is still an organizational decision no tool makes for you. What AI changes here is the friction of getting from zero SLOs to a defensible first draft, which used to take a workshop and a spreadsheet and increasingly takes an afternoon.

On-Call Scheduling and Toil Reduction

This is the least flashy category and probably the most immediately felt by individual engineers. PagerDuty, Opsgenie, and similar tools have had smart scheduling for years, balancing load and skipping people near PTO. What's newer is toil-specific analysis: some platforms now scan a team's ticket and page history to flag which recurring alerts are pure noise versus which ones represent real, fixable problems, and rank them by engineer-hours wasted. It's a small feature compared to an AI SRE agent doing live root cause analysis, but for a burned-out on-call rotation, "here are your top five noisiest alerts by wasted hours" is sometimes the most useful report in the whole stack.

Runbook and Knowledge Management

The unglamorous truth about most incidents is that the fix was already documented somewhere, if anyone could find it. This is turning into one of the more genuinely useful applications of retrieval-augmented generation in the SRE space: instead of an engineer grepping a wiki during an active incident, a chat interface pulls the relevant runbook section, the last few times this alert fired, and who fixed it, in one query. Datadog's Bits AI, ServiceNow's Now Assist, and most of the dedicated AI SRE agents from Part 1 all lean on this pattern. The quality ceiling here is entirely set by how good your existing documentation is, which brings us back to a point worth repeating: these tools reward teams that already write things down. If your team is still deciding how to organize that knowledge layer for agents to query safely, that's exactly the ground covered in Trust No Agent: How to Secure Autonomous Tools on Your Machine.

Capacity and Cost Optimization

I touched on predictive capacity planning under ITOps, but it deserves a wider frame. A lot of what used to be manual FinOps work — right-sizing instances, catching orphaned resources, forecasting when a service will outgrow its current tier — is now a background AI process in platforms like Datadog, Dynatrace, and the major cloud providers' own cost tools. For SREs, the payoff isn't glamorous, but it's real: fewer capacity-related pages, because the system flagged the trend three weeks before it became an incident instead of after.

What All of This Adds Up To for the SRE Persona

Put the incident agents from Part 1 together with the chaos assistants, SLO copilots, and runbook retrieval from this part, and the actual shift in the job looks less like "AI does SRE work" and more like this:

The pattern repeating across every row: AI is good at surfacing options and drafts, and still bad at owning the judgment call that has actual consequences. That's not a limitation to apologize for. It's the correct division of labor for now, and probably for a while.

What I'd Actually Recommend

If you're evaluating tools for your team across either part of this series, a few things I've learned the hard way:

1. Fix your data before buying a tool. Correlation and retrieval are only as good as your alert taxonomy and postmortem history. A brilliant model over garbage data still gives you garbage.
2. Don't let AI auto-remediate anything you haven't tested extensively. Suggestion is fine. Auto-restart-the-production-database is not, unless you've earned that trust over months. This applies doubly to the AI SRE agents from Part 1, most of which default to read-only for exactly this reason.
3. Budget time for the writing habit, not just the tool. Auto-drafted postmortems only help if someone still reviews and improves them. Teams that treat the draft as final start losing institutional knowledge fast.
4. Pilot on one team first. ITOps and chaos engineering rollouts especially tend to get sold org-wide before anyone's tested them against your actual ticket mess or your actual appetite for deliberate failure.
5. Ask what the agent actually queries, not just what it outputs. For the AI SRE agent category specifically, the evidence trail is the product. If a tool can't show you exactly what it checked before proposing a root cause, treat the proposal as a guess with good formatting.

Where This Is Headed

I keep going back and forth on how much further this goes. The correlation and drafting gains from Part 1 are real, and I use them daily now, and the newer agent-based investigation tools are the first thing in a while that's actually changed how fast I can get from "page fires" to "I know what broke." The proactive side covered here — chaos experiment design, SLO drafting, toil analysis — is quieter progress, but it's the kind that compounds: every noisy alert an AI flags and a team actually fixes is one less 2 a.m. page for good, not just a faster resolution of the next one.

But there's a gap between "explains what probably happened" and "understands the system well enough to fix novel failures," and I don't think that gap closes with a bigger model. It closes with better telemetry, better documentation, and engineers who still know how to read a stack trace without an assistant summarizing it for them. If you want a broader look at the open-source side of that telemetry and tooling layer, I put together a rundown in Open-Source LLM Tools Worth Your Time and Developer Tools That Actually Matter in 2026.

If your team is evaluating AI features anywhere in your reliability stack this year — incident response, ITOps, chaos testing, or SLO management — start by asking what data problem it's solving, not what model it's built on. The model is rarely the bottleneck. Your alert hygiene, your documentation, and your SLO coverage almost always are.