Every team that adopts AIOps eventually reaches the same uncomfortable question: how much should the platform be allowed to do on its own? The honest answer depends less on how clever the models are and more on one property of each action, which is whether you can take it back. This comparison sorts the common automated responses into three groups and shows why the undoable ones deserve your trust first.

The argument is simple. Most operational decisions can be reversed: you make the move, observe the result, and return to where you started if the outcome disappoints. A smaller set lock behind you once made. Treat every choice as permanent and nothing ever ships. Treat every choice as casual and sooner or later someone deletes a volume that held the only copy of something important. The skill is in telling the two kinds apart before the action runs, not after.

The three options on the table

When a monitoring platform spots a problem, there are broadly three ways it can respond. We will compare them on the same four questions: what it costs to be wrong, how fast you notice, how fast you recover, and how much evidence you need before enabling it.

Option A: Advisory mode

The platform detects, correlates and suggests. A human reads the suggestion and decides. Being wrong costs a few minutes of an engineer’s attention. You notice immediately because nothing happens until someone acts. Recovery is trivial, since nothing changed. The evidence required to switch it on is almost none, which is exactly why it is the right place to begin.

The weakness is speed. If the suggestion sits in a queue overnight, the benefit of automation evaporates. Advisory mode also tends to produce a quiet habit: people stop reading the suggestions. If your team already struggles with a flood of notifications, the piece on cutting through event clutter with smarter tooling is a good companion read before you add yet another feed.

Option B: Automated action with a built-in way back

Here the platform acts without waiting, but only with moves that carry an inverse. Restarting a stateless service, shifting a slice of traffic to a healthy instance, toggling a feature off, scaling out, or rolling a deployment back to the previous version all qualify. Being wrong costs a short blip. You notice quickly because the action is logged and the symptom either clears or does not. Recovery is the inverse action, which you have already written and rehearsed.

This is the sweet spot for most teams, and it is where a lot of the real value of AIOps lives. The condition is discipline: each automated action must ship together with its undo, and the undo must be exercised in a calm moment rather than discovered in a crisis.

Option C: Fully autonomous action on one-way operations

This is the group where the platform decides and the effect cannot be reversed: dropping a database, purging a queue, terminating the only node holding unreplicated state, rotating a key that other systems still depend on, or sending a customer-facing message. Being wrong can be severe, and no rollback exists. The evidence you need before enabling this is a long track record of correct decisions in the lower tiers, plus a human approval step that is not a rubber stamp.

How the three compare side by side

• Cost of a wrong call. A is negligible, B is a brief and bounded disturbance, C can be permanent.
• Time to notice. A is instant by design, B depends on how good your logging is, C may only surface when a downstream system complains.
• Time to recover. A needs none, B takes as long as the inverse action, C may be measured in restores from backup, if backups exist and were tested.
• Evidence needed first. A needs a hunch, B needs a rehearsed undo, C needs a track record and an explicit sign-off.
• Typical benefit. A saves thinking time, B saves response time, C saves the last bit of human effort, usually the least valuable slice.

That final line is worth pausing on. The marginal value of automating the one-way operations is small compared with the value of automating the reversible ones, while the marginal risk is large. A rational ordering therefore falls out of the comparison without any strong opinions: start at A, graduate the proven patterns to B, and keep C behind a person for as long as you reasonably can.

Sorting your own actions into the right tier

The practical exercise is to list every action your platform could take and ask three questions of each one. Can we state the inverse in a single sentence? Have we ever run that inverse on purpose? Does the inverse restore everything, including data written in the meantime? A yes to all three puts the action in tier B. Any hesitation sends it back to tier A until the answers improve.

Watch for actions that look reversible but are not. Scaling a database replica down is easy; scaling it back up does not bring back the cache that was warm. Restarting a service is harmless until it drops in-flight work that was never persisted. Rolling back a release is fine until the release included a schema change that the old code cannot read. These hidden one-way edges are where most unpleasant surprises come from, and a short written note per action about its edges costs very little.

Where a human still earns their place

None of this argues for keeping people out of the loop forever. It argues for putting them where their judgment is scarce and valuable. In tier A they read and decide. In tier B they review the automation after the fact and refine the rules. In tier C they approve each action with the evidence in front of them. Over time, as an action proves itself repeatedly, you can promote it a tier. That promotion should be an explicit decision recorded somewhere, not something that happens because nobody objected.

If you are building these tiers for the first time and want an outside view of how other organisations structure them, DevOpsSchool Netherlands, which offers consulting and instructor-led courses out of Amsterdam, is one of the places teams turn to when they want rollout patterns and release practices talked through. Whoever you ask, bring your list of actions and your honest answers to the three questions above, because that list does most of the work.

A short worked comparison

Consider a platform that notices a service degrading under load. In advisory mode it posts a message saying latency is climbing and suggests adding capacity. An engineer sees it ten minutes later and adds capacity by hand. Slow, but safe.

In the reversible-automation mode it adds capacity immediately and records the change. If the load pattern turns out to be a one-off spike, a later rule removes the extra capacity. Both directions are cheap, and the whole sequence can be replayed from the log.

In the autonomous one-way mode it decides the degradation is caused by a corrupted data partition and drops the partition to rebuild it. If the diagnosis was right, the problem disappears. If it was wrong, you have lost data and the original symptom still stands. The upside over the second mode was a few minutes; the downside was unrecoverable. That asymmetry is the entire case for sorting before you automate.

Common objections, answered briefly

Will this slow us down? Only at the start. Reversible automation is quick by definition, and the time spent writing and testing the inverse is repaid the first time something goes wrong at an awkward hour.

What if the inverse is itself risky? Then the action is not really in tier B. Move it back, or redesign it so the undo is a simple, well-understood step such as flipping a flag or redeploying a known good version.

Does every team need all three tiers? Not at once. A small team may live happily in A and B for a long time. If you are still shaping your first rollout, the guide to getting AIOps adopted by an IT department covers the people side, and the beginner-friendly DevOps learning path helps anyone on the team who needs the underlying release concepts first.

The takeaway

Automation is not one decision; it is dozens of small ones, and they are not equally weighty. Sort them by whether you can retrace your steps. Give the platform freedom where the way back is cheap, keep a person in the room where it is not, and promote actions between tiers only on evidence. Done this way, you get most of the speed of full autonomy while keeping the ability to say, calmly and quickly, that a change was a mistake and can be undone.