The Simulator, Not the Archive: Your AI SRE Learns Somewhere Else

Originally published on data-agent.co.

Machine learning changes incident remediation only when the agent learns from verified outcomes, not from history. An incident archive records one unrepeatable response per failure, so training on it clones what tired humans did. An autonomous SRE should learn the other way: by replaying engineered faults in a sandbox and grading every fix against a known answer.

The simulator, not the archive: the follow-up to the harness argument. An agent that acts on production learns the way pilots learn: by replaying failure in a controlled environment, against an answer key. History only tells you what to rehearse.

In June, a post-KubeCon autopsy on r/sre cut through the noise with a single, organizing insight: features are noise; trust is the signal. The consensus from the engineers on that thread was blunt and uniform. Investigation is fine. A drafted remediation is acceptable. A pull request is perhaps tolerable. But write access to production remains a hard border.

They are right. And the vendors' standard answer to them is wrong. The standard answer is: the agent will earn your trust by learning from your history. Feed it your incidents, your postmortems, your telemetry archive, and it will get better over time. It sounds reasonable, because that is roughly how we imagine human seniority works. But history is not a curriculum. It is a pile of outcomes. In an earlier post I argued that an autonomous SRE needs an agent-native harness, where observability is one sense among several. This post goes one level deeper, into the part of the harness that learns. The claim: an agent learns to fix production by replaying failure in a controlled environment, not by mining what already happened. The archive tells you what to rehearse. The rehearsal is where the learning lives.

Why the archive cannot teach

Consider what your incident history actually is. It is one non-repeatable path through your system's life, recorded from the outside. For every incident, exactly one response was tried, by whoever was on call, at 3 a.m., under pressure. There is no reset button and no counterfactual: you cannot know whether the restart fixed it, or the cache expiring fixed it, or the traffic dropping fixed it, because you only got to live that minute once. A logged recovery that follows an action is a correlation, not a verdict.

Train an agent on that record and you get an imitation of the past. It is behavioral cloning wearing the vocabulary of learning: the agent reproduces what tired humans did, including their shortcuts and their lucky guesses, with no way to test whether any of it was actually the cure. And the incidents that matter most, the rare, compounding, high-consequence failures, are precisely the ones your archive has almost no examples of. The training data is thinnest exactly where the stakes are highest.

Postmortems do not rescue this. They are written by humans, for humans, after the fact, with the inconsistency you would expect from a document produced during recovery week. Ask the engineers: in SRE community threads, postmortems show up as a pain point, not a proud asset. Nobody hands a new hire the postmortem archive and says: read this, then take the pager. We know it does not work for people. It does not work for agents either.

Pilots do not learn from flight logs

Aviation solved this problem, and it did not solve it with data. A pilot's flight history is thousands of hours in which almost nothing goes wrong. If pilots learned only from what happened to them, no pilot would ever be prepared for an engine failure at rotation speed. So aviation built the simulator: a controlled environment where the rare and the catastrophic can be triggered on purpose, survived, evaluated against a known standard, and run again.

Notice the three properties that make the simulator work, because they are exactly what an archive lacks:

• The failure is engineered, so the truth is known. The instructor injected the engine failure. There is no debate about the root cause. The evaluation is against an answer key.
• The environment resets. The same scenario can run again tomorrow, with a different response, and the difference in outcome is attributable to the response.
• The hours are a ledger. Ratings and type certifications are earned by demonstrated performance in the simulator and under supervision, scenario by scenario. Trust is not an impression. It is a logbook.

Site reliability engineering already believes this, for humans. Game days, chaos engineering, the "Wheel of Misfortune" incident rehearsals that teams run to build what the AWS fault-injection team calls muscle memory: the entire practice says that operators learn by rehearsing failure in a controlled environment, because production will not schedule its failures for your training calendar. The industry trains its humans in a simulator and proposes to train its agents on an archive. That is backwards.

How machine learning changes incident remediation: the replay loop

So what does the simulator look like for an autonomous SRE? In the harness terms from the last post, it is the loop that connects the verify job to the govern job. Concretely, it runs like this:

• Every fault becomes a replayable case. A failure worth learning is reproduced as a controlled fault: a script that injects it into a sandbox environment on demand. A ConfigMap corrupted, a permission revoked, a memory leak seeded, a dependency severed. The catalog of these cases is the agent's curriculum.
• The agent runs the full loop against it. Detect, diagnose, act, verify, in a non-load-bearing environment that looks like production but owes nothing to it.
• The reward is verifiable, because the failure was engineered. The environment knows what was injected. The agent's diagnosis is graded against the answer key, and its fix is graded by whether the system actually recovered. No model grades another model's homework. The research on model judges is unambiguous: they show self-preference, they get gamed, and in operations a judge that keeps agreeing with the agent while the incident metrics get worse is not a safety mechanism.
• The environment resets, and the case runs again. Same fault, different attempt, attributable difference. This is the counterfactual production can never give you.
• The verdicts accumulate into a ledger. Per fault class: how many rehearsals, what success rate, how many shadowed production runs where the agent's proposed fix matched what the humans did. Autonomy is widened per fault class as the ledger fills, and narrowed when it slips. Trust is a number with an audit trail, not a vibe.

The replay loop: production tells the catalog what to rehearse; the sandbox is where the learning happens; the ledger is what earns autonomy.

Now look at where history fits. Production incidents are not the training data. They are the syllabus committee. A new incident's real job is to become a replayable case: reproduce it, add it to the catalog, and rehearse it until the response is boring. The archive tells you what to rehearse. It never was the rehearsal.

This is also where the economics land kindly, because the replay loop finishes an argument I started earlier: it commoditizes the lake. An agent does not need a fancy data lake. It reads raw signals through an API, so the agent is not the customer for what the premium platforms actually charge for, the pane, the per-seat editors, the indexed just-in-case retention. Keep those for the people who still use them and right-size the rest. For the agent, a plain managed backend does the job alongside what you already run: Amazon Managed Prometheus for the metrics, Amazon OpenSearch for the logs, read in place. In my cost teardown of exactly this question, the premium platforms priced out at 5 to 9 times a self-hosted floor for the identical workload, while read-in-place Amazon Managed Prometheus landed at roughly 1 to 1.2 times. And a sandbox rehearsal costs sandbox prices on top: no customer traffic at risk, no premium telemetry bill, no 2 a.m. human. The expensive thing was never the compute. It was learning on the systems that pay your salary.

The evidence is already in

None of this is hypothetical. When researchers needed to measure whether AI agents can actually run operations, they did not point the agents at incident archives. They built environments. Microsoft Research's AIOpsLab evaluates cloud-ops agents on live benchmark problems: it injects faults into running services and generates an oracle for each scenario. IBM's ITBench does the same with reproducible incident scenarios, and its scores are the strongest argument in this post: every frontier model lands below 50 percent on Kubernetes root-cause tasks, clustered together. The model is not the moat, and more archive will not move that number. The environment, the curriculum, and the verified loop will.

The frontier labs have done the same math for their own agents: purpose-built training environments are now a funded industry of their own, because for coding and browsing agents the environment, not the data, is the bottleneck. Operations is arriving at the same conclusion a year later, with one difference. Ops has no training environment on the shelf. It has to be built, fault by fault, and building it takes deep knowledge of how systems actually fail. That is exactly the kind of unglamorous engineering that never shows up in a demo, and exactly the half that compounds.

What this gives the skeptics

Go back to the r/sre thread, because its trust ladder deserves a real answer. Read-only investigation first. Drafted fixes. Human-approved changes. And then what? On the archive theory of learning, the answer is: trust us, it has seen a lot of incidents. That is an impression, and the engineers are right to refuse it.

On the replay theory, the answer is a logbook. For example, this fault class: forty-one rehearsals, then thirty shadowed production incidents where the agent's diagnosis matched the verified outcome, then supervised fixes, then autonomy, for this class only, revocable by the same ledger that granted it.

The logbook, illustrated: rehearsals, shadowed incidents, verified success rate, and the autonomy each fault class has earned (illustrative numbers).

The gap between "we would let it draft a fix" and "it fixed it while I slept" is not closed by a better model. It is closed by a logbook both sides can read.

Pilots earned the cockpit that way. Your agents should too. When a vendor shows you an autonomous SRE, ask the simulator questions: Where does it rehearse? Who grades the rehearsal, and against what answer key? Can I read the ledger? If the answers are "your historical data," "our model," and "trust us," you have your answer, and it is the one the engineers on that thread already gave.

The archive is a syllabus. The simulator is the school.

This is the loop we are building at DataAgent, an autonomous observability and remediation platform. It starts read-only: a fault-coverage report shows which incident types the agent can detect, diagnose and potentially remediate today, before you give it permission to act, and it runs alongside the tools you already have (how the product works).

Convinced agents should earn trust in a simulator, but wondering what the simulator looks like? That is exactly why I started a free, open-source training series on how to build your own autonomous SRE: the detect, diagnose, act, verify loop, wired to your own Kubernetes and cloud planes, built up step by step. Start here: How to build your own autonomous SRE (free, open-source training series).

FAQ

What role does machine learning play in production incident response automation?

In production incident response, machine learning is most useful for learning which corrective action resolves which fault class, and for proving it. That needs a verifiable reward: the fault is injected on purpose in a sandbox, so the diagnosis is graded against what was injected and the fix against whether the system recovered. A model trained only on past incident logs learns to imitate past responders, not to verify a fix. Autonomy is then granted per fault class, from a ledger of graded rehearsals and shadowed production runs.

How is a replay sandbox different from chaos engineering?

Chaos engineering tests the system: it injects faults to see whether the architecture degrades gracefully. A replay sandbox tests the responder: the same engineered fault runs again and again, and each attempt by the agent is graded against a known answer. The two share tooling, and a chaos experiment that exposes a weakness is a good candidate to become a replayable case.

Which fault classes should an AI SRE agent rehearse first?

Start with faults that are frequent, cheap to reproduce, and have an unambiguous recovery signal: an OOMKilled pod, a corrupted ConfigMap, a revoked permission, a bad rollout that needs rolling back. Cheap, measurable correctness is what lets the ledger fill quickly. Rare, compounding failures belong in the catalog too, but they earn autonomy last.

What does shadow mode mean for an AI SRE agent?

In shadow mode the agent watches real production incidents and produces a diagnosis and a proposed fix, but takes no action. Its proposal is compared afterwards with what the on-call engineer did and with the verified outcome. Shadowed runs are the bridge between sandbox rehearsals and supervised fixes in production.

Why not use an LLM to grade the agent's fixes?

Model judges show self-preference and can be gamed, so an agent graded by a model can look better while incidents get worse. When the fault is engineered, the environment already knows the answer: what was injected, and whether the system recovered. That ground truth is a cheaper and more trustworthy grader than another model's opinion.