The agent that reads production errors and cannot touch a file

This is another post in the series on the fleet of agents that runs my infrastructure. The bug hunter writes code. This one is the opposite: it diagnoses production incidents and is not allowed to change a single file.

The problem it solves

My monitors watch the deployments of two payment platforms and one of my own products. When errors spike, I get an alert on my phone. The alert tells me that something broke. It does not tell me whether it is my bug, a provider having a bad day or a misconfigured variable, and that is the first thing I need to know before deciding whether to get up.

Answering that question used to mean reading logs and opening files myself. Now the agent does that reading and I get the answer as a second message, a couple of minutes after the alert.

What it does

When a monitor sends an alert, it also leaves a job in a queue. A worker picks up one job at a time, gathers the recent logs of that deployment and runs an agent over a local copy of the repository.

The agent returns four things: a classification (our bug, external error, configuration or unknown), a severity, the probable cause with the file and line when it can point to one, and a recommended action. I read it and I decide.

Read-only is a property of the tools

I do not ask the agent to please not edit anything. It runs with a list of tools that only read, and the ones that write are explicitly denied. It cannot edit code, open a pull request or deploy. If a log line convinced the model that the fix was urgent, there is nothing it could do about it.

That matters here more than anywhere else in the fleet, because the input is production logs, and logs contain text written by whoever is hitting the endpoint.

The other limits are cheap and boring. One diagnosis runs at a time. There is a daily cap, so an error storm cannot turn into a bill. Every run has a time limit. And the worker postpones the job when the server is short on memory, because that server already went down once from exactly that.

The numbers so far

From the worker's own log, since it started in July 2026: 123 runs, 109 diagnoses delivered and 14 runs where the agent call failed.

Of the last 25 diagnoses it kept, 11 were classified as configuration, 6 as our bug, 6 as an external error and 2 as unknown.

The split surprised me. I built this expecting to find bugs, and the largest group is configuration. Less than a quarter of the alerts pointed at code I had to fix.

What I do not have is an accuracy number. I read every diagnosis and most of them hold up, but I have not scored them one by one, so I am not going to put a percentage on it.

Why it does not fix anything yet

The obvious next step is to let it open a pull request with the fix. The design is ready: its own working copy, pull requests only, never a deploy, and the same rule as the bug hunter for anything that moves money.

I have not turned it on. An agent that diagnoses badly costs me a few minutes. An agent that fixes badly on a payment platform costs something else. It stays read-only until I have scored enough diagnoses to trust the next step.

If you are building something similar, or want this running on your own deployments, write to me. The service is described on the AI agents page.