An honest split between the parts worth automating and the parts that are not

There are two failure modes in AI-for-operations projects and they are mirror images. The first is automating too little — a chatbot bolted to the incident channel that summarises what everyone can already read. The second is automating too much — a system that restarts a database at 3am on a model's say-so and is wrong.

Both come from the same missing step: nobody separated the parts of incident response that are mechanical from the parts that require judgement. They look similar from a distance and they are not remotely the same problem.

The three things an incident asks of you

Strip an incident down and it makes three demands, in order.

Gathering is running the same six queries you ran last time. It is mechanical, verifiable, and has a correct answer that does not depend on who asks. There is no reasonable argument against automating it, and it is where most of the elapsed time goes — we timed an incident in the previous post and it was over half.

Interpreting is deciding what the evidence means. A language model is genuinely good at this — correlating a deploy timestamp with an error signature across heterogeneous evidence is exactly the shape of problem it handles well. It is also where models produce confident nonsense, so the output is only usable if it arrives with a confidence that means something and with the evidence it rests on attached.

Deciding is choosing to change production. Failing over, rolling back, restarting, scaling. This is not primarily a technical question; it is an accountability question. Somebody is answerable for the consequence, and "the model suggested it" is not an answer anyone will accept in the review.

Where each approach actually lands

Task	Automate?	Why
Run the standard checks for this alert	Yes, always	Deterministic, repeatable, and the biggest single time sink
Correlate a release with an error signature	Yes, with the evidence shown	Models are good at this; the reader must be able to check it
Summarise the incident for handover	Yes	Nobody writes this properly at 3am, so today it simply does not exist
Decide an alert was benign and close it	Yes, above a confidence floor	Only where the evidence establishes it — and the floor is yours to set
Wait and re-check a draining backlog	Yes	Patience is mechanical; humans are bad at it and resent it
Restart a service, scale a cluster	Only with approval	Consequential and hard to reverse; a person owns it
Fail over a database, roll back a release	No	Blast radius exceeds what any confidence score can justify
Diagnose something genuinely novel	No — but gather for it	The expert should start from a complete picture, not an empty one

The failure mode that kills pilots

Here is how it goes wrong, and it is nearly always the same story.

The damage is not the one wrong answer. Engineers are entirely used to monitoring tools being wrong. The damage is that the confidence was fabricated, and once an engineer catches a system doing that, they stop reading its output permanently — and they tell their colleagues. Trust in this category is spent once.

So the interesting engineering question is not "how do we make it right more often". It is how does the system behave when it is wrong, and specifically whether it knew.

What "knowing" looks like in practice

A conclusion that can be audited has three properties, and all three are testable in a pilot.

Each claim names the evidence that carries it. Not "confidence 92%" but "a deployment happened inside the alert window — established by recent_deploys" alongside "the errors are attributable to that deployment — assumed".

An assumed link caps the confidence. If the causal step is correlation rather than demonstration, the number must come down and the reader must be told why. In InsightResolve an assumed link caps confidence at 0.75 and an unsupported one at 0.4, regardless of what the model first said.

The gaps are stated. "A rollback that clears the errors, or the same signature absent in the previous version, would settle it." That sentence tells the engineer exactly what to do next, which is more useful than any score.

Notice that the verification step sees only the evidence, not the conclusion's reasoning. That is deliberate: a critic given the argument tends to agree with it. A critic given only the facts cannot invent support that is not there.

Where models are worse than rules

A point rarely made by anyone selling AI: for a large share of incident work, a rule is better than a model, and you should prefer it.

• Threshold comparisons. "Is the lag below ten thousand?" does not need inference. It needs arithmetic, and arithmetic is always right.
• Known-signature matching. If connection refused to redis always means the same thing in your estate, encode that. It is faster, free, and cannot drift.
• Anything auditable. Where a regulator or an incident review will ask why, a deterministic rule you can point at beats a probabilistic answer you have to defend.

This is why InsightResolve runs perfectly well with no model configured at all. Classification and verification fall back to rules, every artifact states which decided it, and the honest consequence is that confidence scores are lower and more things escalate. That is the correct behaviour, not a degraded one.

A test you can run in an afternoon

Before any procurement conversation, this separates the serious systems from the demos. Take five resolved incidents from your own history. For each, give the system only what was known at minute zero — the alert, nothing else — and let it run.

1. Did it gather the same evidence your engineer gathered? (Tests the integration surface.)
2. Did it reach the same conclusion? (Tests the reasoning — but this matters least.)
3. On the ones it got wrong, did its confidence reflect that? (Tests whether you can trust any of its output.)
4. What did it do when a system was unreachable? (Tests whether it guesses to fill gaps.)

Question three is the whole evaluation. A system that is right eighty per cent of the time and confident about the other twenty is unusable. A system that is right sixty per cent of the time and says so on the rest is something an on-call engineer will actually read.

Two ways to read this

Keep reading