Some ideas refuse every obituary. NoOps — the proposition that operations can be automated and purchased until no dedicated team is needed — has been pronounced dead at least twice and is now enjoying a fourth life, this time powered by AI agents that investigate incidents on their own. For operations leaders, the honest question is not whether the slogan will survive 2026. It is what the evidence actually supports, which parts of the claim have hardened into practice, and which parts remain theatre. The reference point throughout is the Ops Atlas NoOps entry, which keeps the definition straight while the marketing moves. This piece checks the record against it.
The Fourth Life of NoOps
The term entered the language in February 2011, when Forrester’s Mike Gualtieri argued that DevOps was a step backward and that developers should never again need to converse with an operations professional. The April report from the same firm walked the claim back to something more durable: a concept that would augment DevOps and its people rather than abolish them. A year later, Netflix’s Adrian Cockcroft applied the label to an engineering model where developers deployed their own code and answered their own alerts — a real and much-discussed shift, though seasoned observers noted at the time that the operational duties had been handed to developers rather than destroyed. When serverless computing revived the promise around 2016 to 2018, sceptics including Charity Majors and the CNCF rejected it again, on the grounds that the duties had moved rather than disappeared.
The pattern across all three earlier lives is consistent: a genuine jump in automation, wrapped in a claim about people that outran the tooling. Each wave left real improvements behind — pipelines, managed databases, functions that scale to zero — while the surrounding rhetoric quietly moved on. The fourth life begins with the same structure, which is why a sober reading of 2026 is worth the effort.
What the Agents Change in 2026
The newest variable is software that does not merely collect telemetry but reasons over it. AWS’s DevOps Agent became generally available in March 2026, and Microsoft fields a competing SRE Agent on Azure. Both take a production problem, gather signals across services, form hypotheses, and propose remediation — collapsing the investigation phase that once consumed the first hour of every incident. Anyone who has run a 3 a.m. bridge call remembers that hour: grepping logs, bouncing between dashboards, building the timeline by hand while the customer count climbs. Removing most of it is not a cosmetic improvement. For teams already working with modern AIOps platforms that speed up problem resolution, the step from correlation to proposed action is the logical next rung.
Measured against the marketing, the demonstrated results are narrower than the demos suggest. These agents shorten investigations; they do not own outcomes. Microsoft’s guidance for production environments is to run them in review mode, with a person approving each action, and deployments rest on someone owning the agent’s permissions and its mistakes. Grant an automated agent standing write access to production without a named owner and you have recreated the oldest anti-pattern in the field: unaccountable change, arriving at machine speed. The tooling moved; the accountability graph did not dissolve. Plan for the hour the agent is confidently wrong, because that hour always comes.
What Has Not Changed About NoOps
Three structural facts have survived every revival intact, and they bound whatever the agents achieve.
First, displacement. Work that leaves a dissolved ops team lands somewhere specific: the provider, an internal platform group, product engineers carrying alerts, the automation codebase, and vendor management. And the four items that never transfer are identical on every tier of every service menu: data, identity, configuration, and access policy. Microsoft’s responsibility matrix has said so for years. None of the 2026 agent announcements touch that boundary.
Second, coverage. The monthly volume of operational work is routinely a fraction of a full-time engineer, yet staffing it around the clock with sane on-call loads requires a full rotation. That gap between work and coverage is why operations costs scale the way they do, and why consolidating duties into shared platform groups — not eliminating them — is where real savings appear. It also explains a common post-migration surprise: the team that lost its ops specialists discovers the pager schedule costs more, not less, once the same duties sit with scarcer people. Readers comparing the economics will find the pattern familiar from how AIOps differs from traditional IT operations: the tooling changes the slope of the curve, not its shape.
Third, dependency arithmetic. Any service’s availability ceiling is the intersection of its critical dependencies; a provider’s service-level agreement is an input to that product, never a substitute for it. An estate that automates its own responses brilliantly still inherits every outage its identity provider, DNS vendor, and cloud region suffer. Automation can shorten the recovery, which matters, but no amount of cleverness moves the ceiling itself — that requires either fewer dependencies or better ones, both of which are architecture decisions rather than purchases.
Where the Evidence Says the Model Fits
Stripped of rhetoric, the strong version of the case is situational. The evidence favours buying operations wholesale in a specific band of conditions, and disfavours it elsewhere:
- Strong fit: spiky or modest load, standard architectures, and small teams whose rarest skill is product engineering rather than infrastructure tuning.
- Weak fit: steady high-volume traffic, where reserved self-run capacity frequently wins on cost alone.
- Poor fit: exotic hardware, unusual latency budgets, or regulatory constraints that demand hands-on control.
- Unpriced risk: provider product retirements — the exit nobody costed becomes the migration everybody performs under duress.
These are exactly the trade-offs an enterprise weighs when planning infrastructure management strategies built on AIOps: automate the repeatable, keep the judgement, and know which is which before the contract is signed.
Reading NoOps Evidence Without the Headline
The 2026 scorecard, then, reads like this. Automation keeps advancing, and the agents mark a genuine step: investigation time collapses, and small teams can operate estates that once demanded a department. The claim that a dedicated ops function becomes unnecessary holds for a real but narrow band of situations. The claim that operations itself disappears has now failed four times for the same reason: duties are displaced, never deleted, and accountability always lands on a person or a team, eventually. Notice also what did not change across the four revivals. Each wave arrived with a tooling leap, was marketed as the end of a profession, and settled into being an augmentation of the people it was supposed to replace. The fourth life is tracking the same arc on a faster clock.
For operations leaders the practical stance is neither zeal nor dismissal. Measure the residual work, and keep the measurement current, because displaced duties have a way of regrowing in the gaps between reorganisations. Watch what the agents shorten and what they merely move. Keep a human signature on production changes, and treat every agent’s permission scope the way you would treat a powerful service account — reviewed, minimised, and owned. And when the fifth revival arrives — it will — the organisation that kept those numbers will recognise the pattern from experience rather than from a keynote.