Agentic AI for Autonomous IT Operations: What an Agent May Close on Its Own
Read Time 15 mins | Written by: Vinayak Bhagat
Once an agent is actually running in your environment, the interesting question changes. It stops being whether the thing works and becomes something much more specific, which somebody has to answer for every runbook you own: is this a task the agent may close by itself, or one it may only prepare for a human?
Most teams answer it tool by tool, which is how you end up with an agent that is trusted to restart a production service because that integration happened to be easy, and not trusted to enrich a log entry because nobody got round to it. The sort is arbitrary, so the boundary drifts, and the first time it goes wrong nobody can say who decided.
There is a better sort, and it has nothing to do with how hard the task is. Difficulty tells you whether an agent can do the work. Consequence tells you whether it may.
Which IT operations work can an AI agent run without a human?
Sort the work by reversibility and blast radius, not by difficulty. Work that is reversible, observable and contained can run unattended: log triage and enrichment, alert correlation, patch staging in non-production, ephemeral environment provisioning. Work that is reversible but wide, or narrow but awkward to undo, should act and then report: service restarts, routine scaling, closing duplicate tickets. Work that is irreversible, broad, or touches identity, money or customer-facing production should propose and wait for a human, permanently, no matter how well the agent has been performing.
The Three Autonomy Tiers
Three questions place a task in a tier. They are worth asking in this order, because the first one disqualifies more work than the other two combined.
1. Reversibility. If the agent is wrong, can a human put it back without a change window, a restore, or a conversation with a customer? Not "is there a rollback path in principle" but "would we actually take it at three in the morning".
2. Observability. If it acts wrongly at three in the morning, does anyone find out before a customer does? An action nobody can see after the fact is not autonomous, it is unsupervised.
3. Blast radius. How many systems, users or tenants are affected if the judgement is wrong? The same action can sit in different tiers on different estates, and that is correct rather than inconsistent.
Tier 1 — Run Unattended
Reversible, observable, contained. The agent does the work and nobody reviews it in advance. This is where most of the durable value sits, and it is consistently under-used because it looks unglamorous: log triage and enrichment, correlating related alerts into one incident, tagging and routing tickets, staging patches in non-production, standing up and tearing down ephemeral environments, gathering the diagnostic context a human would otherwise spend the first twenty minutes collecting. If the agent gets one of these wrong, the cost is a wasted minute and a corrected record.
Tier 2 — Act, Then Report
The agent acts without waiting, and a human is told afterwards in a place they actually read. This tier is for work that is reversible but wide, or narrow but awkward to undo: restarting a service, scaling a resource group inside pre-agreed bounds, closing tickets it has identified as duplicates, applying a known remediation to a known signature. The report is not a log line. It is a notification with what was done, what triggered it, and what the state was before, addressed to somebody whose job it is to look.
Tier 3 — Propose and Wait
The agent does the analysis, drafts the change and stops. A human approves. This is not a failure of the agent and it is not a stage the work graduates out of. Plenty of tasks belong here permanently, and the agent still earns its cost by removing the preparation rather than the decision: the change is written, the evidence is attached, the reviewer reads rather than researches. Access reviews live here. So does anything where being right ninety-nine times does not pay for being wrong once.
Where Common IT Operations Work Lands
Treat this as a starting position rather than an answer. The tier depends on your estate, and the point of writing it down is that the placement becomes a decision somebody owns instead of a default nobody chose.
| Work | Tier | Why it lands there |
|---|---|---|
| Log triage and enrichment | Run unattended | Reversible, fully observable, affects a record rather than a system |
| Alert correlation | Run unattended | Worst case is a mis-grouped incident a human regroups |
| Ephemeral environment provisioning | Run unattended | Contained by definition and torn down on a timer, though it has a cost tail |
| Patch staging, non-production | Run unattended | Staging is the rehearsal; promotion to production is a separate decision |
| Service restart on a known signature | Act, then report | Reversible, but it is a production action somebody must know happened |
| Scaling inside pre-agreed bounds | Act, then report | The bounds are the human decision; staying inside them is not |
| Closing duplicate tickets | Act, then report | Cheap to reverse, but a wrongly closed ticket is invisible unless reported |
| Production configuration change | Propose and wait | Broad blast radius and reversal usually needs its own change window |
| Granting or changing access | Propose and wait | The agent may review and recommend; it may not grant |
| Deleting data or destroying resources | Propose and wait | Irreversible, which ends the conversation on its own |
What Never Runs Unattended, However Well It Performs
Four categories stay in Tier 3 permanently, and it is worth writing them down before anyone is under pressure to move one: identity and access, because an agent that can widen its own permissions has no meaningful boundary; anything that moves money, including committing spend; destruction of data or infrastructure, because irreversibility is the whole test; and customer-facing production configuration, where the blast radius reaches people who never agreed to be part of your rollout.
These are not tiered by performance, so improving performance does not move them. If that sounds unambitious, it is the same principle that governs privileged human access, and nobody argues that a reliable administrator should stop needing approval for production deletions. The NIST AI Risk Management Framework is a reasonable external reference point if you need one to point at in a governance conversation.
Four Ways the Tiering Goes Wrong
Mistake 1: tiering by model confidence instead of consequence
A confidence score describes the agent's certainty, not the cost of being wrong. High confidence on an irreversible action is the most dangerous combination in the system, because it is the one most likely to be waved through. Tier on consequence and use confidence only to decide whether the agent should attempt the task at all.
Mistake 2: promoting a task because it has not failed yet
"It has run clean for six weeks" is only evidence if you would have seen a failure. Before promoting anything out of Tier 2, establish that the reporting was being read and that a wrong action would have surfaced. Otherwise six quiet weeks means nothing more than six weeks of not looking.
Mistake 3: treating "act, then report" as Tier 1 with extra logging
A report nobody is accountable for reading is not a control, and Tier 2 collapses into Tier 1 the moment that happens. The difference between the two tiers is a named human, not a log destination. If you cannot name who reads it, the task is running unattended whatever the design document says.
Mistake 4: letting the agent own the runbook that defines its own limits
If the tiering lives in a document the agent can edit, or in a prompt it can rewrite, the boundary is decorative. Keep the tier assignment in a system the agent reads and cannot write, and treat a change to it as a change to production, because it is one. This is the same shape of problem as the ungoverned tooling covered in our guide to shadow AI governance.
Where to Start
Start with Tier 1 work you already do badly, not with the task that would impress people most. Log triage and alert correlation are the usual honest answers: they are done inconsistently by whoever is on call, nobody enjoys them, and being wrong costs almost nothing. They also generate the evidence trail that every later promotion depends on.
Then add Tier 2 deliberately, one task at a time, each with a named reader for its reports. Resist the urge to move a batch. The value of this framework is almost entirely in the fact that each placement is a decision with a person and a date attached, and a batch promotion has neither.
If the agent is not in production yet, the sequencing question is a different one, and the seven checks in our guide to deploying production-grade agentic AI come first. If you are still choosing a vendor, the questions worth asking are in the agentic AI buyer's checklist. And because unattended work has a cost shape rather than a cost line, the discipline in FinOps for AI workloads applies from the first Tier 1 task, not from the first invoice that surprises someone.
The Autonomy Tiering Worksheet
This article gives you the sort. The worksheet is where your own estate gets sorted: every runbook you own listed, each one placed against the three questions, with space to record who signed off and on what date. It is the part an article cannot do for you, and it is what turns a boundary you agree with into one you can point at six months from now.
We draw the tier boundary before we automate anything across it.
The engineering is rarely the hard part. The hard part is agreeing, in writing and in advance, which work an agent may close and who is accountable when it does. We run that conversation, then build the Tier 1 and Tier 2 automation and the reporting that makes Tier 2 mean something. Our agentic AI and autonomous systems practice does the build, and the cloud team owns the estate it runs on.
Talk to us about the boundaryFrequently Asked Questions
What is agentic AI for IT operations?
It is the use of AI agents that can take actions in your environment rather than only producing recommendations: reading telemetry, deciding what a signal means, and then doing something about it, such as enriching an incident, correlating alerts or applying a known remediation. The distinguishing feature is not intelligence, it is the ability to act, which is precisely why the question of what it may act on needs its own answer.
Should an agent be allowed to make production changes on its own?
Some, with a report afterwards, and only inside limits a human set in advance. A service restart on a known failure signature is reasonable to run in Tier 2. A production configuration change is not, because reversing it usually needs its own change window and its blast radius reaches beyond your team. The useful test is not whether the agent can make the change correctly, but whether a human could undo it quickly if it was wrong.
How do we decide when to promote a task to full autonomy?
Treat promotion as a change to production, with a named owner and a date. Before promoting, confirm two things: that the task's reports were genuinely being read, so a clean record is evidence rather than silence, and that the three questions still place it in the lower tier on today's estate rather than the one it was assessed on. Tasks in the four permanent Tier 3 categories are never promoted regardless of record.
Does this replace the on-call rota?
No, and a plan that assumes it will is usually a plan that skipped the tiering. What changes is what on-call spends its attention on: the preparation work that used to consume the first part of every incident moves to Tier 1, and the person who gets paged arrives with the context already assembled rather than having to gather it. The judgement calls stay where they were.
Keep Reading
→ How to Deploy Production-Grade Agentic AI — the seven checks that come before any of this.
→ The Agentic AI Buyer's Checklist — what to ask a vendor before you deploy.
→ FinOps for AI Workloads — why unattended work has a cost shape rather than a cost line.
This article is general guidance on operational practice and is not legal, regulatory or security advice. Autonomy boundaries interact with your own control environment and obligations. Evaluate your own circumstances with appropriate advisors.
