What is autonomous IT operations?
Some operations now run in a closed loop with no person involved. The system notices a problem, works out the cause, and applies a fix, and none of these steps waits for approval. Automated diagnosis has existed for years, so the genuinely new part is that the system now acts on its own.
The word autonomous hides a spectrum, and most disagreements about feasibility are really disagreements about which point on it somebody has in mind.
| Level | What the agent does | What it commits you to |
|---|---|---|
| Detect | Correlates signals and raises one issue instead of forty alerts | Nothing. This is conventional operations tooling |
| Diagnose | Proposes a likely cause and a recommended action | A person still decides, so the risk is wasted time rather than damage |
| Act, gated | Executes, after a human approves the specific action | The approval must be fast enough to matter, or you have automated the diagnosis and kept the delay |
| Act, autonomous | Executes within a defined envelope and reports afterwards | An envelope somebody defined, a record of what happened, and a way to stop it |
Almost every real deployment runs the last two together, with different actions at different levels. A single agent can be fully autonomous for restarting a stateless service and gated for anything touching data, which is why describing an organisation as having or not having autonomous operations rarely means much.
Can autonomous IT operations meet compliance requirements?
Yes, but the range of actions that qualify is narrower than vendors claim and wider than most compliance teams expect. Almost no regulation prohibits a machine from taking action. What regulations require is three things. First, a reliable record of what happened. Second, a clear trail showing who authorised the system to act. Third, proof that a person could have stepped in to stop or reverse the action.
Those three are engineering problems rather than policy obstacles, which is the reframe worth taking into the conversation.
- Evidence, not permission. Most regimes require a reliable record of what was done and by what. An agent that logs every action with its trigger, its reasoning and its actor produces better evidence than a human following a runbook at three in the morning. See AI audit trail.
- Authority has to be traceable to a person. Not to a service account. The agent acts under a delegation somebody granted, and that delegation is the thing an auditor examines, which is the argument at agent identity.
- Intervention must be genuinely available. A stop that works, operable by somebody who is not an engineer, at a weekend. See kill switch.
- Change control still applies. An autonomous remediation inside an approved envelope is a pre-approved change, not an unapproved one. The envelope goes through change control once rather than every action going through it individually.
Which actions can an agent take on its own?
The ones you could undo. Reversibility beats risk tiering as a test on three counts: it is objective rather than a judgement call, any engineer can answer it in seconds without a workshop, and it maps straight onto the thing a change board already spends its time worrying about.
Sorting your runbook by that test usually produces a larger autonomous set than people expect.
- Reversible, so autonomous. Restart a stateless service, scale a replica set, clear a cache, rotate a log, fail over to a healthy node. If the action is wrong, the next action undoes it and the cost is a few seconds of degraded service.
- Partly reversible, so gated. Roll back a deployment, drain a node, change a rate limit. Undoable, with consequences while undone, so a person confirms but does not diagnose.
- Irreversible, so never autonomous. Delete data, run a schema migration, move data across a jurisdiction, modify permissions. No amount of model improvement changes this, because the problem is the action rather than the accuracy.
One refinement worth adding to the test. Ask not only whether it can be undone, but whether it can be undone without knowing what it was. An action reversible only if somebody recorded the previous state is reversible in theory and not in an incident at two in the morning, which makes recording the prior state part of the autonomy decision rather than a nicety.
What does an agent need to act safely?
Live operational context that no runbook contains. The failure mode is not a wrong diagnosis but a correct one acted on at the wrong moment, and almost everything an agent needs to avoid that sits outside the monitoring stack it was given.
Five things, and the first two cause most of the damage.
- 01
Whether a change freeze is onA correct remediation during a declared freeze is still a violation. Where it lives: the change system, which operational tooling is usually not connected to.
- 02
What else is already happeningAn agent restarting a service another team is mid-failover on turns one incident into two. Where it lives: the incident record and the deployment pipeline.
- 03
What this system actually does for the businessThe same technical symptom is urgent on a payments path and routine on a reporting job. Where it lives: the service catalogue, if anybody maintained it.
- 04
What was tried in the last hourWithout it an agent repeats a failed remediation, which is how a loop starts. Where it lives: its own trace, which means memory across runs. See agent memory.
- 05
Where the blast radius endsWhich downstream services depend on the thing being touched. Where it lives: the dependency map, which is the artefact most often out of date.
Taken together these explain a pattern worth naming. Production ops agents fail on coordination far more often than on diagnosis, and the remedy is integration into the systems that hold operational state rather than a better model. A vendor demonstrating accurate root cause analysis has shown you the part that was already working.
How does it relate to AIOps and alert noise?
AIOps and autonomous operations cover two different halves of the work. AIOps is the detection half, and autonomous operations is the acting half. AIOps tools reduce alert noise by correlating related alerts, which is valuable. It changes how many things a person has to look at, but it does not change whether a person has to act on them.
The distinction matters commercially because the two are frequently sold as one thing.
- Noise reduction is a grouping problem. Forty alerts from one root cause become one issue. Well-understood, measurable, and it leaves the remediation exactly where it was.
- Autonomy is a permission problem. Whether the thing that noticed is allowed to fix it, under what envelope and with what record. That question is organisational before it is technical.
- Suppression is not reduction. An alerting system that hides noise by raising thresholds has reduced what you see rather than what is wrong, and the incident it was hiding arrives later and larger.
The practical sequence follows from that: correlation first, because acting on noisy signals automates the noise. The alert fatigue side is covered in depth at our analysis of AIOps and alert fatigue; this page is about what happens once something has been correctly identified and somebody has to decide whether a machine may act on it.
How do you start?
One reversible action, on one non-critical service, logged completely, for ninety days. The instinct is always to aim at the incident type that hurts most, and that is precisely the one where a single early mistake will end the programme before it has proved anything.
Five steps, ordered so the organisational work happens before the technical work.
-
Sort your runbook by reversibility
Three columns: undoable, undoable with consequences, irreversible. This is a two-hour exercise and it produces the autonomy envelope directly, without a risk workshop.
-
Take the envelope through change control once
As a standing pre-approved change rather than a request per action. This is the step that turns compliance from a blocker into a one-time piece of paperwork.
-
Connect the agent to change and incident state before giving it any permission
Freeze status and what is already in flight. An agent without these will eventually take a correct action at a catastrophic moment, and that incident is the one people remember.
-
Run it in recommend-only mode first
Same detection, same proposed action, no execution. Compare its recommendation to what the on-call engineer actually did. Disagreements are the finding, and this is the cheapest evaluation available.
-
Enable execution for the single most common reversible action
One action, one service, full logging, and a stop that somebody non-technical can reach. Expand by action rather than by service, because the envelope is defined per action.
Before anyone writes a business case, it helps to set one expectation. The return comes from faster resolution, not from a smaller team. It also shows up on common, repetitive incidents rather than dramatic ones. Programmes justified by shrinking the on-call rota (the schedule of staff who take turns being available to fix urgent problems outside working hours) tend to disappoint. Programmes justified by removing the forty-minute wait before someone restarts a service tend to deliver.