The DevOps function is not going away, but who performs it is changing.
What is also changing is where DevOps engineers spend their time, and the underlying skillset needed to be a DevOps engineer in the agentic era. Within a few years, roughly 80% of the daily operations work DevOps engineers do by hand today will be done by two layers of agents: an enterprise agentic layer that sits on top of your existing tools, and a personal agent that works for each employee.
A DevOps engineer's work will also move from running daily operations to building and governing agents that will interface directly with end users.
This piece walks through how we get there, one stage at a time.
Leaner teams, a bigger job
When 80% of the daily work in a function moves to agents, that function needs fewer people doing the work by hand. There is no honest way to write about the future of DevOps without saying so.
This is not unique to DevOps. Software development, QA, security, support and data engineering face the same arithmetic. Every engineering discipline will have to come to terms with it, and pretending otherwise does not help the people living through it.
But DevOps is in a different position from most. The work it does is the work an enterprise can least afford to get wrong. And the people who know how to do it are the only ones who can teach the agents to do it safely. The rest of this piece is the case for that claim.
The work does not disappear. It shifts. Before AI, a DevOps engineer spent 30 to 40% of the day building automation and the rest operating it. In the AI-native enterprise that split reverses: about 80% of the day goes into building and governing agents, and about 20% into operations.
Where this ends up
The AI-native enterprise runs on a four-layer stack. Reading from the top:
- Layer 4, the human layer. Developers, operators, business users and DevOps engineers. They state intent and keep the judgment calls. About 20% of daily operations work stays here.
- Layer 3, the personalized agentic layer. One personal agent per person, such as Muse, Dots or OpenClaw. It takes the request and works on it asynchronously, absorbing about 20% of daily operations work, half of what is user-driven today.
- Layer 2, the enterprise agentic layer. The company's own agents, running inside its enterprise controls. A lot of it does not use LLMs. It does about 60% of daily operations work, and it is the only layer that touches infrastructure. Determinism and safety are built here.
- Layer 1, the SaaS tooling layer. Kubernetes, cloud providers, security tools, ISV products and in-house CI/CD and IaC. It is unchanged from the IaC Era.
Each layer talks only to the one below it. People ask their personal agent, the personal agent calls the enterprise agentic layer, and the enterprise layer calls the tools.
The DevOps engineer is the one person who appears twice. Like everyone else, they use the stack through a personal agent. They also build it: through the Agent Builder Agent, they add the agents and controls that the enterprise layer runs.
These percentages describe daily operations work. They do not describe how the DevOps team spends its time. For the team, the change is a reversal. Before AI, a DevOps engineer spent 30 to 40% of the day authoring IaC and building automation, and the rest operating it. In this stack, about 80% of the day goes into building and governing agents in the enterprise agentic layer, and about 20% into operations.
The sections below explain how each layer arrived.
How we are getting there: five stages
The first three stages change how fast the work gets done. The last two change who does it.
Stage 1: The IaC Era
DevOps as the translator
Before AI, the DevOps team was a translator. Developers built applications and handed over requirements: a service, a database, a queue, an environment for staging. DevOps engineers turned those requirements into infrastructure, using subject matter expertise that only they possessed.
Expertise, written down as code
To save themselves from repeating that work, they wrote it down as code. Infrastructure as Code, CI/CD pipelines and a growing library of scripts became the team's product. This was a real advance, and most of it is still running today.
It also had a built-in limit. The automation was static, so every time the application's needs changed, the IaC had to change with it. Someone on the DevOps team had to make that change.
The operating model it produced
The result was an operating model with three features:
- A queue. Requests went in as tickets and came out as infrastructure, at the speed of the team.
- Little self-service. Developers rarely touched infrastructure directly, because doing it safely required knowledge they did not have.
- One interface. The DevOps team was the only group that talked to the infrastructure.
Stage 2: Coding assistants make the same model faster
What got faster
Then came Claude Code and tools like it. A DevOps engineer could describe a Terraform module or a pipeline in plain English and have a working PR in minutes. The pace at which automation got built went up sharply.
What stayed the same
What did not change was the operating model. AI lived on the DevOps engineer's laptop and produced the same artifacts as before: IaC, pipelines, scripts. Those artifacts were used the traditional way. Developers still filed tickets, and the rest of the organization never touched an agent.
The IaC Era got faster, but it was still the IaC Era. The translator had a better pen.
Stage 3: Agents start doing the work
From writing automation to performing the task
The real break came when AI stopped writing the automation and started performing the task. Give an agent a goal, connect it to the tools, and it works out with an LLM's help which tool to use and in what order. No one has to write the script in advance. This changes the economics of the IaC Era. Static automation had to anticipate every case. An agent handles the case in front of it.
Stage 3 adoption is still scarce in enterprise DevOps workflows. Unlike coding, where most of a software developer's effort is now AI driven, most operations are human driven except for maybe troubleshooting.
Barriers to Stage 3 AI adoption
Agentic adoption has been slow in DevOps for four reasons:
- It is mission critical. The cost of AI hallucinations in production infrastructure can be catastrophic, and AI governance has not yet matured enough to prevent this.
- It is single-user. A coding assistant is one engineer in one session. DevOps work is shared: releases, incidents and environments involve many people, and each of them would need sensitive credentials on a laptop.
- It sends everything to an LLM. Most DevOps tasks are simple API calls, such as restarting a pod, rebooting a VM or fetching logs. Paying for model reasoning on each one, at DevOps frequency, is cost-prohibitive.
- It is chat-only. DevOps use cases repeat. Work that repeats needs forms, status views and dashboards, and something other systems can call.
Behind those barriers sits a longer list: who is allowed to do what, where secrets live, what gets approved by a human, what is logged, and what it all costs. An agent connected to tools is a good demo. An enterprise needs a platform.
Stage 4: The enterprise agentic layer
Built on the tools you already have
The answer is a layer that sits between the agents and the infrastructure. Nothing underneath it is replaced. Kubernetes, the cloud providers, the security tools, the ISV products and the CI/CD the team built in the IaC Era all stay where they are. The agentic layer connects to them.
This layer has two jobs. The first is the obvious one: take a task and get it done, choosing the right tool for each step. The second matters more to an enterprise: enforce the controls and policies, and make AI deterministic and safe.
The enterprise agentic layer is where the DevOps team will focus, as opposed to daily operations. It is the layer that lets humans keep control, instead of AI taking over.
30+ functions, six disciplines
The work needed to build and operate an agentic layer is much harder than it looks. Running agents for many users on shared production systems takes more than 30 functions across six disciplines:
| Discipline | What it covers |
|---|---|
| Multi-tenancy and access control | SSO, workspaces and projects, user RBAC and policies, audit trail, cloud and user credential mapping, secrets management |
| Multi-player AI | Shared multi-user sessions, skill distribution, context and agent memory, knowledge base, token management policies, model router |
| Security and observability | Prompt-injection protection, human-in-the-loop, agent audit trails, command approval policies, LLM observability |
| Cloud capabilities | Kubernetes and Terraform management, deployment orchestration, pipeline management, compliance controls, hundreds of multi-cloud services |
| Hosting | Deployment and updates, fault handling, notifications, scale and performance |
| UX | Standardized forms and dashboards, reusable modules, Slack and Teams, API, CLI, MCP |
These are not optional extras, and they are not chosen one at a time. Every multi-user workflow needs all six, whichever use case it serves. A team that builds each agent separately rebuilds this plumbing each time.
The upskilling this demands
One major change has to happen for this layer to work: the DevOps team has to upskill. Running operations and building the system that runs operations are different jobs.
A DevOps engineer at this layer needs the skills of a software architect and the instincts of a seasoned operator.
Working at the agentic layer is design work. An engineer has to decide which steps are deterministic and which need a model, how permissions and approvals fit together, where a person stays in the loop and how an agent fails safely. Those are a software architect's questions.
The operational nuance matters as much. Only someone who has run production knows which change is risky, which alert is noise and what a rollback really costs. An architect without that experience builds agents that look right and behave wrongly.
The combination is rare today, and it will not appear on its own. Teams have to invest in it deliberately, with time to learn agent design and a path from working tickets to owning workflows.
Most of the work never reaches an LLM
The counterintuitive part of this layer is that AI usage has to be limited to make it deterministic and cost effective. Once a workflow is understood, its routine steps run as pre-coded, tested paths with no model in the loop. Restarting a pod does not need reasoning. It needs a permission check, an API call and an audit record.
The remaining 40%
In this stage of evolution, while agents do 60% of the work, what is left is the part a person drives. Someone has to decide a new environment is needed, open the right workflow, fill in the form, wait for the result, read it and decide what comes next. Someone has to notice the deployment is stuck and ask why.
None of this is hard, but it needs a human's attention at each step. The agentic layer removed the DevOps team as the bottleneck. The person making the request is the bottleneck now.
Stage 5: Personal agents become the front door
A new product category
That last bottleneck is about to move too. Open-source projects like OpenClaw showed the pattern first: an assistant that belongs to one person, remembers their context and works on their behalf. In the past month the largest AI companies have made it a product category.
Muse
It takes a goal, builds a plan and advances the work on its own, including opening a browser and filling out forms. It is available inside WhatsApp as well as on the web and mobile.
Dots
Each dot is an always-on agent with its own cloud computer, browser and identity, and it can connect to more than 4,000 workplace applications.
Mark Zuckerberg's framing at the Muse launch was that "everyone will have an exceptionally capable personal agent." Whichever product wins, that direction looks settled. Soon every developer, operator and business user in the enterprise will have one.
How work will be requested
This changes how work gets requested. A developer will not open a portal and fill in a form. They will tell their agent, over text, chat, the web or WhatsApp, that the payments service needs a staging environment by Thursday. The agent will do the work asynchronously and come back when it is done or when it needs a decision.
The enterprise agentic layer: an industry standard, not a DIY project
Personalized agents never touch infrastructure. They call this layer, and it does the work.
A personalized agent may ask. Only a human-governed layer may act.
The layer is itself agentic, but it is built carefully. People write the policies and approvals, routine actions run as AI-less workflows, and a model is called only where judgment is needed. Every action is traceable to a person. For the enterprise, the same rule brings safety, reliability and standardization: guardrails are enforced once, and no company is tied to one vendor's assistant.
We believe this is a matter of life and death for human civilization. The design of this layer is our last practical opportunity to keep AI from taking over the systems people depend on. Once autonomous agents are wired directly into infrastructure at scale, there is no orderly way to take that access back.
This cannot be solved one company at a time. Every major discipline, not only DevOps, needs such a layer, and each should converge on an industry standard. The protocol a personal agent uses to call it should be close to regulated, backed by a government standard as safety-critical industries are. It follows that enterprises should rarely build this layer themselves.
ISVs will provide the framework; enterprises build the agents and policies
If this layer is to be a standard that is close to regulated, it will not be implemented thousands of times over. As with other regulated infrastructure, a small number of ISVs will provide the implementation, and getting it right will be their whole business. We sell such a framework, so weigh this view accordingly, but the reasoning holds whichever vendor an enterprise chooses.
- The framework is the same everywhere. Access control, secrets, audit, approvals and token management barely differ between companies. Rebuilding them in-house produces nothing that sets a company apart.
- Compliance is proven once. Certifying an implementation against a regulated standard is expensive. An ISV does it once for every customer. An enterprise that builds its own carries that cost alone, and carries it again with each revision of the standard.
- Safety rewards focus and scale. An ISV that does only this sees failures across many customers and spreads the cost of every fix. A bespoke build will be less secure and less reliable.
That leaves the enterprise free to work on the part that is specific to it:
- Agents that encode how the company deploys, secures, audits and recovers.
- Governance policies that say who may ask for what, which actions need a person's approval and where the limits are.
The framework is the part that is common to everyone. The agents and the policies are the part that is yours.
Why the DevOps team matters more
With both agent layers in place, about 80% of today's daily operations work is done by agents. That means leaner teams. It also means the people who remain hold one of the most important jobs in the company.
- They own the human-governed layer. The policies, approvals and deterministic workflows are their judgment, written down once and applied to every request.
- The blast radius is theirs to contain. An infrastructure agent that gets it wrong causes an outage, a breach or a runaway cloud bill.
- Every other team's agents depend on them. Each personal agent and each functional agent calls into the layer they build.
- Accountability stays human. Someone decides what an agent may do without asking, and answers for the outcome.
Their day changes to match: about 80% building and governing agents, and about 20% operations.
Where to start
Start with the enterprise layer. Personal agents are arriving whether or not the enterprise is ready, and employees will point them at work systems. Without a governed layer to call, those agents have two options: do nothing useful, or reach the infrastructure directly.
Three steps for the first year
Three steps make the first year concrete:
-
Put the common 70% on a platform.
Stop rebuilding access control, secrets, audit and approvals for each agent.
-
Move the highest-frequency actions to tokenless workflows.
This is where determinism and cost savings show up first.
-
Expose every workflow through an API and MCP.
A workflow that only a person can click through is one a personal agent cannot use.
The IaC Era asked DevOps teams to write down what they knew as code. The stages ahead ask them to write it down as the rules that agents work within. The teams that do it first will define how their companies run on AI.