Your AI agents are an estate, not a toolbox

There is a lot of enthusiasm about letting AI agents run IT operations. Agents that watch the estate, spot the anomaly, and fix it before anyone is paged. The capability is real, and it is improving quickly. But the hard part of agentic AIOps is keeping a population of agents under control. Teaching individual agents to act is less complex.

That distinction is not pedantic. It is the difference between an approach that scales and one that quietly becomes something nobody fully understands.

The reframe

We tend to think of an AI agent as a tool, something you point at a problem. This framing can introduce complexities that go unaddressed the moment you have more than one agent. The right framing is to treat the population of agents as an estate: a population of semi-autonomous actors operating on shared infrastructure, each with a scope, a version, and a set of things it is allowed to touch. In many cases these autonomous actors will have to interact to complete tasks.

With this new framing you stop asking "can this agent do the task" and start asking "what else does this agent affect, and what happens when several of them act on the same system in the same hour."

That second question is where the real risk lives. A single agent misbehaving is a contained problem. The harder failure is emergent when one agent changes the state that another agent then reads, and the second acts on a world the first agent had quietly rearranged. No one designed that interaction. No one is watching for it. And when it surfaces as an incident, the post-mortem may be close to impossible, because the causal chain runs through decisions that were never written down.

The reassuring part, and the point of this piece, is that we are not short of a discipline for this. We have managed populations of interacting components under change for decades. It is the practice of documented design with boundaries clearly defined, understanding network effect impact of a new agent or change in an existing agent; thorough testing including boundary cases, configuration management and robust change approval process that accounts for the agent interactions before any change touches production. The central operations management artefact in this approach is the CMDB. The argument I want to make is simple: extend that discipline to the agents themselves.

Runbooks first, as guardrails

You should not automate a fix before ensuring the fix is written down – which we will call the runbooks. Codified runbooks are the precondition for any closed-loop automation.

There is a fashionable counter-argument that the newest agents reason well enough to operate without runbooks. Perhaps. But a runbook does more than instruct, it bounds. It narrows the space of what the agent will do, which is exactly what you want when the agent can act on production. The right mental model is grounding the agent: giving the agent your runbooks and reference material is the operational equivalent of handing a capable new engineer your manuals and your procedures on the first day. They could muddle through without them. They will be faster, safer, and more predictable with them.

If you have ever given a general-purpose AI tool a document to work from and watched the output improve, you already understand the principle. This is the same idea, with far higher stakes.

Improvement must be a supervised, tested loop

An agent that records its reasoning, its inputs, and its actions gives you two things: the ability to do root-cause analysis after the fact, and a stream of candidate improvements to the runbooks.

The temptation is to close that loop automatically and let the agent learn from its own logs and rewrite its own guardrails. It will be prudent to resist it. A system that rewrites its own rules from its own behaviour can entrench its own errors without anyone noticing it.

The safe pattern is the one we already use for any production change. The agent proposes; a human reviews; the change is tested in a maintained test harness; it is documented; it is version-controlled, with the agent and its documentation versioned together, so you can always answer what an agent was designed to do, and why, at the moment it acted; and it is approved through a change process whose rigour scales with blast radius. Low-impact changes flow through lightly. High-impact changes earn a higher bar. This is not new governance. It is release management and change advisory, applied to a new kind of actor.

The estate needs a register, with an interaction graph

Here is the part most current thinking misses. Governing each agent in isolation is not enough. You need a register of the whole estate: every agent, its version, its scope, and, above all, the map of which other agents and systems it touches.

That interaction graph is what lets you reason about blast radius before an action and reconstruct causality after one. It is a CMDB, extended to capture agent-to-agent and agent-to-system dependencies. Without it, you have automated your operations and blinded yourself to them in the same move.

The register earns its keep most at the moment of change. No new agent should enter production without evidencing, through design and test, its impact on the existing estate: proof that it does not shift the behaviour of the agents already running. That is regression testing for the agent population, and the register is what tells you what to test against.

Sequence by risk, and go slower than you can

Automate the unambiguous, low-cost-of-error fixes first. Keep a human in the loop wherever the diagnosis is uncertain or the consequences are large. And build the control before you grant the autonomy, even though the tooling will happily let you do it the other way around. Unmanaged agent behaviour is hardest to unpick precisely when it has been rolled out fast and wide without the scaffolding above in place.

Justify it honestly

A word on the business case, because it decides whether any of this survives. It is tempting to sell AIOps on cost, on fewer people and lower spend. In my experience that justification does not last. I spent years around outsourcing, and the pattern was consistent: deals justified purely on cost tended to sour and get unwound, while the ones that endured were justified on capability, focus, or resilience, on a business reason beyond the saving.

Agentic operations will follow the same rule. Sold as a headcount play, it does not survive the first budget cycle. Justified on resilience, faster response, less downtime, and the room to grow without growing the team in step, it earns the patience that safe implementation needs. So let saving be the externality, and do not discount cost avoided even where it is hard to quantify.

The unglamorous conclusion

None of this is an argument for holding back. The capability is worth having. But the organisations that get value from agentic AIOps will be the ones that treat their agents as an estate to be governed rather than a toolbox to be filled, and that build the boring scaffolding, the runbooks, the test harness, the register, the change gate, before they hand over the keys.

The plain truth is that the discipline agentic AI needs most is one we already have. We simply have to decide to apply it to the agents themselves.

If you are planning to let AI act in your operations: do you know what each of your agents can touch, and could you reconstruct why one of them did what it did? If not, that is where to start.