Summary
AI in software has moved from writing code to operating the systems it runs on. For DevOps, two decisions now matter most: what an agent can see and what it can change while production is live. If you engineer observability and bound privilege, your agents can run a live system you trust.
The DevOps role is quickly evolving from manual environment provisioning to AI-enabled automation. We’re seeing many CTOs move their focus to how an agent behaves inside a live system. On the DevOps side, that shift runs from generating code toward integrating agents with observability tooling. A runtime agent that carries out DevOps tasks can alter running systems in real time when the stakes are much higher than with code errors. If your developers make a mistake in a code block, it usually causes a bug or a build failure. But DevOps mistakes in a live infrastructure environment can bring down entire systems.
This raises two decisions you need to make explicitly: what an agent may change and when it may act. Continuous deployment makes this harder. An agent’s action and its effect on the system are now nearly simultaneous.
AI can’t tell you what it can’t see. To become a first-class citizen in your infrastructure, it should be able to integrate with observability tools that collect a running system’s metrics, logs, and traces and collate them in one place. These are as useful to engineers as they are to agents.
Any agents you deploy should continuously draw on that telemetry, monitoring both current issues and those starting to form. They add an additional layer of complexity because of their tendency to guess probabilistically when they can’t find a definite answer about what’s happening in production and why.
Some of your telemetry is already wired in, while some still runs in isolation, and the agent can only reason about what it can query. If it can’t see a certain data store, cloud provider, or network segment, it runs into a coverage gap that caps what it can do. These gaps run widest in large, enterprise-grade codebases, where there’s simply more system to instrument, and more of it ends up beyond the agent’s reach. Legacy platforms make it worse, since the instrumentation there grew up piecemeal across separate platforms.
To anticipate this, take stock of how much of your monitoring stack the agent reaches today before extending it any further. As long as the coverage stays incomplete, the agent works from a partial picture, and that, more than any single tool, holds agentic operations back from scaling.
The near-term work is to consolidate those scattered sources onto a single surface that agents can read. However, that’s rarely a one-time project, because every new service or platform reopens a gap. Instead, it should be built into DevOps projects as a regular element.
When telemetry integrates directly into agentic workflows, the nature of the on-call experience also changes. The traditional incident response model was often a case of cognitive overload. An engineer would wake up to an alert, then ping internal channels to assemble a team, and have to hunt through logs or runbooks manually. This scramble happens whether it’s part of the regular business day or at three o’clock in the morning.
The AI-enabled incident experience is different. Developers who get hit with a priority-one issue are not alone and are much better equipped to handle an incident or crisis call. An on-call engineer can simply open an active workspace where the agent has already aggregated the relevant metrics, logs, and traces. Starting from an assembled picture, rather than a blank page, already brings a new level of focus to the process and can help speed up resolution.
Today, your incident-response agents present a synthesized view of the system state and quickly isolate the anomaly. Even with all the automated inputs, the human engineer should retain final authorization to make the definitive operational call on both problems and solutions.
There’s still work to be done in centralizing response workflows and executing them transparently so that DevOps teams can reduce the friction of analyzing incidents.
The agent needs separate answers for two questions: what it can see and what it can change. Once the agent can see production, the question becomes what it has permission to change, and at which point in the deployment cycle it can act. We treat the privileges an agent runs with as a deliberate design choice and make least privilege the default.
An over-privileged agent turns a single misread of your context or intent into lost data or a downed service. Worse, it can do so at machine speed before anyone can step in. In one now notorious 2025 incident, an AI coding tool deleted a company’s production database during a code freeze.i
“When questioned, the AI agent admitted to running unauthorized commands, panicking in response to empty queries, and violating explicit instructions not to proceed without human approval. ‘This was a catastrophic failure on my part,’ the AI agent said. ‘I destroyed months of work in seconds,’” as reported in Fortune.
The apology didn’t restore the database. An agent should never hold privileges wider than the task at hand.
However, there’s no one-guideline-fits-all rule for guardrails. High-consequence environments, regulated assets, or core transactional systems leave almost no room for experimentation, so privileges there should remain as narrow as possible. Programmatic boundaries can enforce limits by preventing an agent from pushing an unverified change into the infrastructure before a human ever sees it. Bounded privilege ensures that an agentic error remains an isolated log entry rather than a business-disrupting outage.
An agent that changes infrastructure needs an immediate signal to verify whether the action improved system stability and to correct course if needed, before a human has to step in. Establishing a feedback loop helps an agent read the result immediately, measure it against historical baselines, flag anomalies, and hold or back out a change.
This is the second job your observability tooling does. The same signal that tells your engineers the system is healthy tells the agent whether its own last move improved things or made them worse. The loop closes when the agent steers on the outcome it just produced, rather than on a prediction of what should happen.
In practice, agents run post-deployment checks and release gates themselves, with a human in the loop for calls that carry consequences. Releasing a gate after a clean post-deployment check is a bounded, verifiable action, the kind least-privilege is designed to permit. Engineers watch how the agents are performing, and the agents watch whether they are still moving in the right direction. Runtime work on these tools will intensify through the rest of 2026 and into the first half of 2027.
For years, running production meant carrying a pager and knowing your systems by hand. But now, you decide what the agents operating your infrastructure are allowed to see, what they are allowed to touch, and where a human keeps the final call.
We see this as emerging work, still being built. Leaders are moving forward over the next six to eight months to define an agent’s view of production and set limits on its reach. The intended result is to build agents that they can trust to operate a live system. Laggards may find themselves in a different position. Teams that postpone those decisions could find themselves adding guardrails after an agent has already changed something they should not have.
We’re in that camp — agents with a defined view and bounded reach. Over time, agents will become a central part of your DevOps footprint. Decide now how much of the system they see and how much you let them touch.
Discover how your operating model compares to the next generation of institutional digital asset investing.
Udit Ujagar
Udit Ujagar is a Vice President and Senior Principal Engineer at Arcesium, where he leads AI initiatives across the software development lifecycle for the Developer Experience team. He partners across engineering, platform, and product teams to take agentic AI from promising demonstrations to tooling that developers depend on every day. With 18 years of experience building large-scale platforms, including over a decade in the investment management industry, Udit has led the design of internal AI Gateway infrastructure, AI code review agents, and developer assistants used across the firm. He brings deep expertise in agentic system design and context engineering, enjoys exploring open-source tooling, and is focused on making AI agents reliable on enterprise-scale codebases.
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
