The AI SRE Runs Inefficient Queries, and That Is the Whole Problem

Every AI SRE demo runs the same way. An incident fires. The agent reads the alerts, forms a hypothesis, checks a few dashboards, and hands back a tidy root cause with a confidence score attached. It is genuinely impressive work. It is also not where the problem is.

Nobody demos what that agent does to your data layer.

A human engineer investigating an incident is expensive to employ and cheap to run. They fire a handful of queries, because every query costs them effort, and because they carry a mental model of the system that tells them which three to ask. An AI investigator is the exact inverse. It is cheap to employ and expensive to run. It does not have your model of the system, so it substitutes volume for intuition. It asks ten questions where you would have asked two. It re-runs the ones that timed out. It widens the time window just in case. It pulls back more data than it needs, because it cannot yet tell what matters.

That is fine in a slide. It is not fine on your invoice, and it is not fine at three in the morning while the thing is still down.

So the interesting question about autonomous incident response is not how good the reasoning is. It is what that reasoning costs to perform, and how fast it can be performed, on the storage and query layer you already have.

The asymmetry is the whole thing, so it is worth being precise about it.

Human triage is shaped by scarcity. You have one engineer, awake, at limited capacity, and every query they run has a cost in attention and elapsed time. That scarcity is what produces the discipline. Experienced responders are not better at querying, they are better at not querying: they know which two questions collapse the search space, and they skip the other eight.

Agentic triage removes the scarcity and, with it, the discipline. An agent has no attention budget. Running forty queries is no harder for it than running four, so it runs forty, and it runs them in parallel, and it runs them again with a wider window when the first pass is inconclusive. This is not a defect you tune out with a better prompt. It is the honest behaviour of a system that has to rediscover the shape of your estate on every single incident.

I have sat on those bridge calls. The expensive minutes are never the thinking. They are the waiting.

Which means the thing that decides whether an AI SRE is useful or ornamental is not the model. It is whether your telemetry backend can absorb forty questions from a machine, mid-incident, without becoming either unaffordable or unavailable.

Storage is where this bites first.

The shape of the problem is not controversial, even if the numbers people quote for it are. Commodity object storage in a format you control is cheap, and it stays cheap as it grows. Retention on a proprietary platform, in a proprietary format, priced per gigabyte ingested and per gigabyte held, is not cheap and does not stay cheap. Vendors on the cheap side of that gap like to quote the multiple. Treat their figures as marketing, because that is what they are, and treat the direction as real, because it is.

Here is the tell that the direction is real: there is now an entire commercial category whose product is reducing your observability bill. Telemetry pipelines that sample, filter and drop before ingest. Tiering products. Consultancies that will do a cost review. None of that industry exists if observability data is cheap to keep.

I have written before about what that industry actually represents: engineers doing financial engineering on telemetry spend instead of real engineering on the pipelines that produce it. The AI SRE is what happens when you add a tireless, undisciplined querying machine on top of that cost base. You do not get a smarter on-call rota. You get a bigger invoice, and then you get a procurement conversation, and then someone caps the agent's query budget and quietly turns the autonomy back down to advisory.

Where does this break? It breaks the other way if your telemetry volume is genuinely small. A single-product team on a few hundred gigabytes a month can run an agent hard against a commercial platform and never feel it. The economics only become decisive at estate scale, which is exactly where anyone is seriously considering autonomous triage in the first place.

Cost is the slow failure. Speed is the fast one.

An autonomous investigator is only useful if it can ask, get an answer, ask again, and converge before your customers notice. That loop has a clock on it. If your backend answers a human's occasional query in two seconds, nobody cares. Make it answer an agent's burst of forty and you find the real ceiling, which is almost never compute. It is the rate limit on the API.

Metered query APIs are throttled by design, and they are throttled hardest under load, which is to say during an incident, which is to say at the exact moment the agent is supposed to be earning its keep. So the failure mode is not a wrong answer. It is your clever AI SRE sitting in a retry loop, backing off politely, while the outage runs and the engineer who got the call goes back to doing it by hand with a worse mental model than they had a year ago.

That is not a hypothetical. It is the predictable consequence of putting an unbounded query generator on the far side of a metered interface.

Change the question you ask in the demo.

Not "how good is your AI". Everyone's AI demos well, because demos are curated and the estate is small. Ask instead:

Most vendors cannot answer either, and the reason is not evasion. It is that the honest answer is uncomfortable: the autonomy is only ever as good as the infrastructure it is allowed to query, and a lot of that infrastructure is theirs, metered, and priced on the assumption that humans are the ones asking.

The design consequence is the useful bit, and it is dull, which is why it gets skipped.

If you want AI-assisted incident response to be viable rather than demonstrable, you invest in the layer underneath first. Telemetry in an open format, in storage you control, queryable by more than one engine, so that an agent's habit of over-asking is affordable and a throttle on one vendor does not take the whole investigation down with it. That is the same argument I made about owning your signal and renting the platform, arriving from a different direction: this time the pressure is not renewal leverage, it is an automated consumer that asks far more questions than a human ever would.

I could be wrong about how long this stays true. Query engines get cheaper, agents get better at pruning their own search, and some of this may look overwrought in three years. But the ordering holds regardless. The capability is a purchase decision you can make in an afternoon. The foundation is an engineering programme that takes a year and shows up on no vendor's slide.

And be honest about the cost of the alternative. "Own your buckets" buys you schema discipline, retention policy, query performance and an on-call rota for the pipeline itself. That is a real bill. It is just a bill you can see, priced in engineering rather than in per-gigabyte ingest, and it does not double the day you point a machine at it.

None of this is anti-AI. It is the oldest lesson in operations wearing a new jacket. The exciting layer gets the budget and the attention. The layer underneath, the one that actually decides whether any of it survives contact with load, gets skipped because it is boring to buy.

The AI SRE running inefficient queries is the whole problem in miniature. Nobody ships a patch for a foundation.

Build the floor before you buy the robot.