Every tool tells you what’s broken. Nobody fixes it.

It’s 3:14 AM. PagerDuty fires. Your AIOps platform has detected an anomaly: memory pressure on prod-api-07 is rising toward OOM levels. The dashboard lights up like a Christmas tree. Slack channels flood. A runbook link appears in the alert, helpfully pointing to a doc last updated in 2021.

You know what happens next. A bleary-eyed engineer rolls out of bed, opens a laptop, SSHs in, checks the usual suspects, restarts a service, maybe scales a node pool, writes “resolved” in the incident channel, and goes back to sleep — knowing it’ll probably happen again Thursday.

This is the state of the art. This is what billions of dollars in AIOps funding bought us: faster notification that things are broken.

The AIOps Promise vs. The AIOps Reality

AIOps was supposed to be the revolution. Apply machine learning to operations. Correlate signals across systems. Predict failures before they happen. The pitch decks were gorgeous.

Here’s what we actually got:

• Smarter alerting — dynamic anomaly detection replaces static thresholds. Useful but not revolutionary.

• Event correlation — grouping related alerts so you get one page instead of forty. A genuine quality-of-life improvement. Still just a notification.

• Root cause “analysis” — a ranked list of probable causes that an engineer still has to verify and act on. A suggestion box with better formatting.

• Dashboards — my god, the dashboards. We have achieved peak dashboard. Every metric, every trace, every log, visualized in real-time with beautiful gradients. And then a human still has to do something about it.

The entire AIOps category is optimized for one thing: reducing the time between “something broke” and “a human finds out.” That’s Mean Time to Detect (MTTD). And sure, we crushed it. MTTD went from hours to minutes to seconds.

But MTTD was never the bottleneck. Mean Time to Remediate (MTTR) was. The gap between knowing and fixing — that’s where incidents live and die. AIOps barely touched it.

The Missing Layer: Execution

Think about what happens in a typical incident:

1. Detection — monitoring picks it up (automated, fast)

2. Notification — alert fires, routes to the right team (automated, fast)

3. Diagnosis — engineer investigates, correlates data, identifies root cause (manual, slow)

4. Decision — the engineer decides on a fix (manual, slow)

5. Execution — engineer implements the fix (manual, slow, error-prone at 3 AM)

6. Verification — engineer confirms the fix worked (manual, slow)

AIOps addressed steps 1 and 2. Some platforms nibble at step 3. Steps 4, 5, and 6? That’s still a human, every single time, no matter how much you’re paying for your observability stack.

This isn’t a tooling gap. It’s a category gap. We built an entire industry around the top of the funnel, leaving the bottom untouched.

Why AIOps Stopped Short

It’s not that nobody tried. Execution is where the problem gets genuinely hard.

Diagnosis is open-ended. Monitoring data tells you what changed. Understanding why requires context that lives in code, config, deployment history, architecture decisions, tribal knowledge, and that one Confluence page from 2019 that nobody can find. Legacy ML models couldn’t navigate this.

Decisions carry risk. Telling an engineer “memory is high” is low-stakes. Autonomously restarting a production service is not. The blast radius of a bad automated action dwarfs the cost of a slow human one. So vendors played it safe — suggest, don’t act.

Environments are snowflakes. Every company’s infrastructure is a unique mess of legacy systems, custom tooling, and “temporary” workarounds that became permanent. Building execution that generalizes across this chaos wasn’t feasible with rule-based automation or narrow ML.

These were real constraints. But they were constraints of the old tooling, not laws of physics.

Enter the Execution OS

Something changed. Not incrementally — categorically.

Large language models aren’t just better pattern matchers. They’re reasoners that can hold the full context of a system in working memory: the architecture, the code, the runbooks, the deployment history, the last three times this exact thing happened, and what fixed it. They can read a stack trace, cross-reference it with a recent deploy, review the config diff, and formulate a remediation plan — the same cognitive work an engineer at 3 AM does, except without the sleep deprivation.

But reasoning alone isn’t enough. The breakthrough is reasoning connected to execution. An AI that can:

• Investigate an alert by querying the systems themselves — not just reading dashboards, but running commands, checking logs, and inspecting state.

• Formulate a fix based on an actual understanding of the codebase, service maps, and infrastructure.

• Execute the fix through the same interfaces engineers use — kubectl, SSH, API calls, and IaC pipelines.

• Verify the result by checking the same signals that triggered the alert.

• Learn from the outcome and update its approach for next time.

This isn’t AIOps with a chatbot bolted on. It’s a fundamentally different architecture. Call it the Execution OS — a system where AI doesn’t just observe your infrastructure, it operates it.

What Changes

When you move from “AI tells humans what’s broken” to “AI fixes what’s broken,” the implications cascade:

Incidents become self-healing. Not the toy version of self-healing (auto-restart on crash, auto-scale on CPU threshold) — actual diagnosis and remediation for novel problems. The kind that currently requires a senior engineer’s judgment.

On-call becomes oversight, not labor. Engineers shift from “wake up and fix it” to “review what the system already fixed.” The 3 AM page becomes a morning summary. The human stays in the loop — but as an auditor, not a laborer.

Operational knowledge stops being tribal. When remediation lives in an executable AI context rather than in people’s heads, it doesn’t walk out the door when someone quits. It doesn’t degrade when the team is understaffed. It doesn’t vary in quality between your best SRE and your newest hire.

Toil actually dies. We’ve been talking about eliminating toil for a decade. But toil-elimination through automation requires someone to write the automation first — and that itself is toil. An Execution OS handles novel situations, not just pre-scripted ones.

The Trust Problem (And How It Gets Solved)

The obvious objection: “I’m not letting an AI run commands in production unsupervised.”

Good. You shouldn’t — not on day one.

The adoption curve for execution AI mirrors how we already adopt automation:

1. Shadow mode — AI diagnoses and proposes fixes. Humans review and approve every action. You’re building a track record.

2. Supervised execution — AI executes pre-approved action classes autonomously (restart service, scale up, roll back deploy). Novel actions still require approval.

3. Autonomous operation — AI handles the full loop for known problem classes. Humans get summoned only for genuinely unprecedented situations.

This is the same progression we followed with CI/CD. Remember when “automated deployment to production” was terrifying? Now it’s table stakes. The trust didn’t come from the technology being perfect. It came from building confidence through graduated autonomy.

The systems that win here will be the ones that make this trust curve as smooth as possible — transparent reasoning, clear audit trails, easy rollback, and the ability to tighten or loosen the leash at any time.

The New Stack

If the Execution OS is the category, the stack looks something like:

The observe layer doesn’t go away. Datadog, Grafana, Prometheus — they’re still essential signal sources. But they become inputs to the Execution OS rather than the final destination. The value shifts from “look at this dashboard” to “the system already handled it — here’s what it did and why.”

Who Builds This

The honest answer: it’s early. The pieces exist — LLMs that can reason about systems, tool-use frameworks that enable action, and infrastructure APIs that allow programmatic control. But the integrated Execution OS that stitches it all together is still being assembled.

Some will try to bolt execution onto existing AIOps platforms. This is the “add a copilot” approach, and it’ll produce mediocre results — because the architectures were designed around human-in-the-loop as a requirement, not a fallback.

The winners will be purpose-built for autonomous operation, with human monitoring as an option. The difference is subtle in a pitch deck and massive in practice.

The Uncomfortable Truth

Here’s the part the industry doesn’t want to say out loud:

Most of what we call “operations” is a human doing what a machine should. Not because the human isn’t skilled, but because the human is too skilled for the work. Senior engineers spending their nights restarting services and their days writing automation to avoid restarting services is an absurd allocation of talent.

AIOps didn’t fix this. It just gave those engineers better binoculars.

The Execution OS doesn’t replace engineers. It replaces the part of engineering that engineers hate — the repetitive, reactive, sleep-destroying, soul-crushing operational toil that drives burnout and attrition.

What’s left is the work that actually matters: designing systems, making architectural decisions, solving novel problems, building the next thing. The creative work. The human work.

The Punchline

AIOps spent a decade getting really, really good at one thing: telling you what’s broken, faster, louder, and with better graphs than ever before.

It was never enough.

The next era of infrastructure AI isn’t about better observability. It’s about closing the loop — from detection to diagnosis to decision to execution to verification, end to end, with humans in control but not in the critical path.

AIOps is dead. Not because monitoring doesn’t matter — it does, enormously. But because “AI for operations” that doesn’t actually operate was always an incomplete vision.

Long live the Execution OS.

The best incident is the one your team never has to wake up for.

This is what we're building at Aokumo. If you want to see it — request a demo