The AI that caught itself lying.

What it does

Most "AI for operations" demos stop at suggesting a fix. A dashboard lights up, an LLM writes a paragraph about what might be wrong, and a human does the actual work. That's a chatbot wearing a hard hat.

This system takes real action. It watches a fleet of running containers, notices when one goes bad, reasons about what's actually causing it, and then issues real commands against real infrastructure. An actual restart on an actual machine. Then it checks whether that fixed anything, writes its own postmortem, and when it notices a pattern in its own mistakes, it proposes a change to its own detection logic.

Six agents, each with one job:

• Detector: reads the metrics, notices anomalies, opens an incident
• Triage: reasons over the dependency graph and past cases to find root cause
• Proposer: matches a runbook, decides what needs human approval
• Executor: runs the real remediation, records what happened
• Postmortem: grades the work against ground truth, writes to memory
• Injector: breaks things on purpose, so the loop can be tested honestly

The number that looked like failure

Once the system was running unattended, the dashboard surfaced an ugly statistic.

A 58% false-positive rate means the system was crying wolf more often than not. In a real operation, that number gets your alerting ignored within a week.

Here is the tempting move, and it's the one most people make: turn up the detection thresholds until the number looks good. Make the system less sensitive, false positives drop, dashboard turns green, ship it.

That fix would have worked. It also would have suppressed real incidents to make a metric look better, which is how you build a monitoring system that's quiet right up until the moment it matters.

What the data actually said

Instead of tuning to the number, I used the platform's own records to root-cause it: three queries joining the postmortem verdicts back against what had actually triggered each incident in the first place.

The false positives clustered on CPU. And the CPU values on those "false" alarms weren't noise drifting near idle. They were 97.0. That's a machine pinned at full saturation. That's not a false alarm. That's about as real as a fault gets.

# the "false positives" weren't false
incident_id  metric  trigger_value  postmortem_verdict
─────────────────────────────────────────────────────
  1042       cpu       97.0          false_positive
  1043       cpu       97.0          false_positive
  1047       cpu       96.4          false_positive

The bug wasn't in the detector. The bug was in the grader.

The postmortem agent was asked to judge whether an incident had been real. But by the time it looked, the fix had already worked. The machine had recovered, and CPU was back to normal. So the agent saw a healthy machine and concluded nothing had ever been wrong.

It had collapsed two completely different questions into one: "was this a real problem?" and "is it better now?" A successfully-fixed emergency looked identical to a false alarm. The system was doing its job correctly and then grading itself as if it had failed.

Why this is the whole point

There's a design decision underneath all of this, and it's the one I'd defend hardest.

The AI is never allowed to be the judge of whether it succeeded.

When the postmortem agent decides whether a fix worked, that verdict comes from measured metrics: hard numbers pulled from the database. The AI is used for what it's genuinely good at: categorizing, explaining, ranking hypotheses, writing the narrative. But the booleans, meaning did this work, yes or no, come from data the model cannot talk its way around.

This matters more than any other choice in the system. An AI that grades its own homework will always eventually give itself an A. Once you let a self-improving loop score itself on vibes, it stops improving and starts congratulating. The grounding in real metrics is the only thing standing between "self-improving" and "self-deluding."

The system found a pattern in its own failures and proposed a fix to its own detection logic. A human still approves that change. Fully autonomous self-modification is how you get runaway feedback loops in production.

What broke along the way

Two other bugs are worth naming, because they're the kind of thing that only shows up when a system actually runs.

The detector cried wolf on idle machines

The first version flagged anomalies using a standard statistical test. It kept firing on nearly-idle machines, because when a machine's CPU drifts from 0.1% to 3.5%, that's statistically enormous relative to its own baseline, and operationally meaningless. Nobody cares. The rebuild added absolute floors (a value has to actually matter before the statistics matter), a baseline that refuses to be poisoned by the anomaly it's measuring, and a requirement that a problem persist across multiple readings before anyone gets woken up.

The faults were healing before the fix arrived

After fixing the grader, everything started grading as "flapping". The fix ran, but the problem didn't stay fixed. The timing data explained it: the injected faults lasted 15–30 seconds, while the full detect→diagnose→repair pipeline took 80–270 seconds. The problems were curing themselves before the cure showed up. The system was heroically "fixing" things that had already recovered on their own, and then honestly reporting that its fix hadn't held.

Two independent processes racing on shared state: a classic distributed-systems problem, and one you cannot find in a demo. You find it by running the thing for real and reading the timestamps.

Then I forgot to turn it off

Last night I left the platform running and went to bed. I didn't mean to. I just forgot it was up.

By morning it had quietly worked a full night shift.

That is the entire pitch for an AI employee, and I didn't stage it. Ninety-one faults detected, diagnosed, fixed, and graded, while the person responsible for the system was asleep. Mean time to resolve: nine-tenths of a second. Every machine healthy in the morning. The replica database still streaming, zero bytes behind.

Cumulatively, the platform has now opened 277 incidents, triaged 279, and run 239 automatic remediations against real infrastructure.

What it costs to employ it

Here's the part that reframes the conversation.

Six-tenths of a cent. That's what it costs for an AI agent to notice a production emergency, work out what caused it, fix it on the actual machine, confirm the fix held, and file the paperwork.

A human on call costs you a salary and a ruined night's sleep. This costs less than the electricity the server burned while doing the work.

I want to be precise about what that number is and isn't. It's the AI cost per incident, measured across 516 real calls, not an estimate. It doesn't include the machines it runs on, and it doesn't include the hours I spent building the thing. But as a picture of what the work itself costs once the system exists, it's honest, and it's the number that scales.

What this has to do with your business

You probably don't need an autonomous incident-response platform for a container fleet.

But if you're going to hand any part of your operation to AI, whether that is document processing, order handling, claims intake or reconciliation, you should want it built by someone who has already learned, the hard way, that an AI system will confidently tell you it's working when it isn't.

An extraction pipeline that reports every invoice parsed cleanly. An agent that logs every exception as routed. A workflow that marks every record reconciled. Every one of those can be wrong in exactly the way this system was wrong: reporting success against its own opinion instead of against reality. At your volume, that's not one mistake. It's a systematic error arriving at scale, invisibly, for as long as nobody independently checks.

The habit of grounding every claim in ground truth is the difference between an automated process you can trust and one that quietly needs auditing.

It's also why every system I build ships with a monthly report showing where it got things wrong, and why that report is on the engagements page, not buried in a contract.