At a meetup last month, someone leaned across the table and asked the question our team has been dodging all year: if we sell automation for a living, why do four of us still carry a pager? It was a fair hit. We build AIOps tooling, we run it on our own stack, and the rota survives anyway. The honest answer takes a detour through NoOps, the idea that operational work can be bought and automated so thoroughly that the ops department itself becomes optional. The word has been floating around since a Forrester analyst coined it in 2011, and every few years a new technology drags it back into the room. Here are the five questions we now answer most often, with the responses we give after the slogans run out.

What Does NoOps Actually Promise?

Strip the marketing and two different promises hide inside one word. The first, which is the more useful of the pair, is organizational: you standardize on managed services, you automate deployment and recovery, and eventually nobody in the building carries “operations” as a job title, because the work has been absorbed somewhere else. The second promise is more radical — sometimes labelled true NoOps — where automation runs the entire environment with no human involvement at all. That version gets airtime in encyclopedic explainers and usually sits next to AIOps, because a claim that large needs machine intelligence to sound even remotely plausible.

The gap between those two promises is where most of the confusion lives. The first is a restructuring of who does the work. The second is a bet that the work can be made to disappear entirely. Our meetup questioner was really asking about the second while living with the first, which is the most common position in the industry and the least discussed.

Worth holding on to as well: the serious writers in this debate describe the destination as an aspiration, never as a discipline you can install from a box. You can buy a managed database, but you cannot purchase judgment about which region to fail over to, or an opinion about whether this quarter’s bill makes sense. Aspiration is a direction of travel. Disciplines — capacity planning, incident review, access hygiene — are what carry you along it, whichever brand of automation you happen to run.

Is This Just AIOps Wearing a Costume?

The two ideas get tangled constantly, so it helps to pull them apart. AIOps is a set of capabilities: event correlation, anomaly detection, incident summarization, and increasingly some automated remediation. NoOps is a destination claim about headcount. You can make a serious AIOps investment and still employ an operations department — most companies that run AIOps do exactly that. You can also move toward the destination with very little machine learning, provided your stack is small enough and boring enough that scripts cover it.

Skeptics have been pushing back on the destination claim for a decade, and the pushback has names attached. When the serverless wave revived the term between 2016 and 2018, Charity Majors and the CNCF rejected the claim outright, on the reasonable grounds that somebody still has to design, watch, and pay for all those functions. The rule we set out in our walkthrough on adopting AIOps without the slogans holds just as firmly here: capabilities are measurable, destination claims need an audit before anyone updates the org chart.

What Do This Year’s AI Agents Actually Change?

2026 is the first year the question has a genuinely interesting answer. AWS made its DevOps Agent generally available in March, and Microsoft shipped an SRE Agent for Azure. Both aim at the most expensive segment of an incident: the investigation. Instead of a bleary engineer opening twelve dashboards at 2 a.m., an agent pulls the signals together, forms a hypothesis, and drafts the summary. Teams adopting them report that time-to-understand shrinks, and that is a real win — a large share of every bad night goes into working out what changed, not into fixing it.

But pay attention to what the vendors themselves prescribe as the default. Microsoft recommends review mode for production incidents: the agent investigates and proposes, a person approves. That recommendation is not a footnote to be engineered away later; it is the design center. The companies that build these agents do not run their own production changes without a human in the loop, and that single fact tells you exactly where the destination claim stands today. Someone also has to own each agent’s permissions, and someone has to own its mistakes — the agents come with both.

Picture the difference on a concrete night. A latency alarm fires in the checkout path. The old flow: an engineer pulls the tracing view, notices the new certificate rotation job, walks back through the deploy log, and posts a diagnosis nineteen minutes later. The agent flow: the same signals get correlated in under two minutes and a draft summary lands in the incident channel before anyone has found a laptop. The fix itself still gets typed and approved by a person. What shrank was the wandering, not the deciding — and the wandering was always the part we hated most.

Can an AI Agent Be Our Ops Team?

This is the anti-pattern worth naming out loud, because it keeps coming up in procurement meetings: treating the agent as the ops team. The failure mode is not the model being occasionally wrong — models are sometimes wrong and that is survivable. The failure mode is unowned write access. An agent that can restart services, edit configuration, or scale fleets is a privileged insider. If nobody owns its credential scope, its audit trail, and its errors, you have quietly re-created an operations team with weaker accountability and no on-call rota at all.

Somewhere in the organisation a name has to be attached to every change — including the changes made by software.

Our posture after the review-mode guidance is simple. Agents get scoped credentials the way any contractor would, every action lands in the same change log a human change would, and a named engineer answers for whatever the agent does. It is the same discipline we described in a beginner’s guide to real-time IT problem solving: speed is welcome, anonymous speed is not. Teams that skip this step tend to rediscover why the rota existed in the first place, usually during the first incident where the agent’s confident summary turned out to be confidently wrong.

If NoOps Is an Aspiration, What Do We Do on Monday?

Treat it as a direction rather than a switch. Operations does not vanish when you automate it; it moves — to the provider, to a platform team, to the product engineers who now hold the pager, into the automation code itself, and into vendor management. All five destinations need a name against them, and “nobody” is never an acceptable entry. Four actions start the movement without betting the product:

• Write down every recurring operational duty and the person who owns it today.
• For duties you have bought or automated, record who absorbs them — then confirm the absorber actually knows.
• Give every automation agent a permission scope, a log destination, and a human sponsor.
• Keep review mode switched on for anything production-facing until you hold quarters of evidence, not weeks.

Do those four things and you get the honest version of the dream: fewer pages, faster investigations, engineers who sleep more nights than they work. Chase the slogan instead and you end up skipping a discipline you were going to need regardless — and the operations arrives anyway, at the worst possible hour, with more people awake than the old model ever required.

For a fuller map of the term — its history, its critics, and the metric set that separates aspiration from practice — the Ops Atlas NoOps entry is the reference we hand every new teammate. And if your team is weighing what AI should and should not decide on its own, our piece on AI-assisted IT decision-making pairs with it well.