How a Simple Undo Button Made AI Agents 1.5x Better at Fixing Cloud Outages

Have you ever wondered how increasing the diameter of a toothpaste tube’s nozzle drastically increased sales?
Turns out it just happens by making a small change, a small tweak to something that already exists.

Similarly, by adding an “UNDO” to an agentic system, STRATUS significantly outperforms state-of-the-art SRE agents.
At least 1.5x better in success rate on failure-mitigation problems, across both AIOpsLab and ITBench, and across various models.

As I mentioned in my previous ITBench post, AI agents aren’t ready for IT operations yet, and ITBench proved it with systematic benchmarking. Agents powered by the best available models were only able to fully resolve 13.8% of SRE scenarios — a number STRATUS simply blows past.

Let me explain how they pulled this off, as simply as possible.

So How Does “Undo” Even Work?

The UNDO in STRATUS works the same way a normal undo operation works in any system.

Yes, of course. But under the hood, it’s using a stack data structure.

Using the Last-In-First-Out (LIFO) property of a stack:

1. Every action the agent takes gets pushed onto an “undo stack”, one after another as action A1, then A2, then A3, and so on.
2. When something needs to be undone, the system pops the most recent action off the top of the stack first — that’s it.
3. Once an action is popped, it’s undone, and it’s removed from the stack.

STRATUS uses the same mechanism, calls it as Transactional Non-Regression (TNR), a stack-based rollback mechanism , that enables safe exploration and iteration with help of agents, assumptions, tools, and oracles.

To understand this properly, we just get to know a glimpse of STRATUS’s helpers and honestly, this is the fun part, and it’s easier than it sounds.

Meet the Agents

STRATUS has 4 kinds of agents:

• Detection Agent — Agent-D
• Diagnosis Agent — Agent-G
• Mitigation Agent — Agent-M
• Undo Agent — Agent-U

Not all agents get access to perform all actions — because they don’t need to. So actions are split into an Action Space:

• Read Action — for Detection, Diagnosis, and Mitigation agents
• Write Action — for the Mitigation agent
• Undo Action — for the Undo agent (which internally uses write actions)

With these, we construct a Transaction (T), a sequence of read or write actions (commands) of length k. How k is decided is where the assumptions come in.

The Assumptions

Assumptions are base conditions you accept as true before moving forward with something, like assuming Google Maps’ traffic data is live and reliable before you actually take the suggested route.

Same idea here. STRATUS assumes:

Writer Exclusivity :

• At most one writer agent (Agent-M or Agent-U) is scheduled to execute commands that alter the system state at a time, which means that particular agent gets exclusive access on the environment.
• This is enforced with a lock called the Agent-Lock (A-Lock), which simply locks the system to whichever writer agent is currently making changes.

Faithful Undo :

• To make undo possible, STRATUS ensures every agent action has a corresponding undo operator, otherwise, that action isn’t allowed at all.
• So actions that can’t be recovered are either turned into recoverable actions with the help of agent tools, or rejected entirely.

Bounded Risk Window:

• A transaction can have length k, meaning k actions in sequence.

• This is solved by the Bounded Risk Window, a key safety mechanism that caps the number of actions (K) a transaction can perform.
• The optimal value turned out to be K = 20, found by running the agents with different limits and seeing what actually worked best.

The Tools That Make It Move

We now know the base conditions but how do the agents actually execute actions? That’s where agent tools come in.

Agent tools are just tools that help the agent interact with the cloud environment, kind of like the Clap button that help me write more blogs, so please go click it bro.

A few of the main ones:

Observability Tools:

• For observing the cloud by collecting telemetry data and system states.
• They also help pre-process logs and other data instead of dumping raw numbers straight at the agent.

Command-Line Tools:

• For constructing the actual commands that make changes (and perform undo).
• Also helps notify humans once a task wraps up.

But How Does It Know When to Stop?

The agents, assumptions, and tools are all ready, and the system starts taking actions but wait,

That’s genuinely worth knowing before we go further.

For this, STRATUS integrates a structured Validation and Termination Approach (VTA). In simple words, it assesses system health using three oracles:

• Alerts — whether the alert that reported the target failure is cleared ?
• User Requests — whether user requests can be successfully returned ?
• System Health — whether system components running in healthy state ?

Combining these forms one strong oracle that STRATUS uses to determine successful mitigation and termination.

Now Comes the Hero: TNR aka UNDO

How does it actually work?

Quick note: let b denote the severity score of the system the moment the failure was first detected, in other words, a score of just how bad that first failure is.

According to TNR, every state (Sᵢ) in the state transition sequence will have severity less than or equal to b , meaning no state the agent ever leaves the system in, gets worse than where it started.

Here’s the loop:

1. From a state Sᵢ, when Agent-M runs a Transaction Tᵢ, it moves the system toward Sᵢ₊₁, and each action in the transaction gets pushed onto the stack one by one as it runs.
2. If the agent ends up in an error state (S-e), determined with the help of the oracles, the transaction gets flagged to abort.
3. On abort, Agent-U kicks in, popping actions off the stack one at a time and performing each one’s corresponding undo operation.
4. Once the stack is fully emptied, the transaction is completely reverted, back from Sᵢ₊₁ to Sᵢ.
5. TNR is then re-verified by checking the severity of the (now restored) state and it holds.

As I mentioned at the start, it’s really just UNDO, done efficiently, with the help of assumptions, tools, and oracles working together.

I just wanted to share how this one “simple” idea “UNDO”, pushed STRATUS to results 1.5x better than other agents.

If you want to dig deeper, the full results and evaluations, give the paper a read: STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds