A few days ago, my monitoring dashboard sat frozen for three days. It aggregates the application errors from my projects every hour. For three days, the tile displayed perfectly plausible numbers. They were three days old.
The monitoring service itself had never stopped answering. The data was there, available, one API call away. What had failed was the piece I had slipped into the middle of the pipe: an AI session.
A silent failure, the worst kind
The unpleasant part of the story is not the outage. It is that the outage did not look like one.
An agent that crashes shows an error, raises an alert, gets noticed. Here, the hourly agent failed cleanly, wrote nothing, and the page kept serving the last known state with its usual formatting. Nothing blinked. I found out while looking for something else.
The cause was mundane: the authentication on the command line tool carrying the session had expired. No quota exceeded, no model unavailable, no bad answer. Just a stale token on a component I had never counted as part of my data collection chain.
Why the AI was there in the first place
Convenience, and that is the interesting part.
Access to the monitoring service already existed as a tool wired into my assistant. Writing a prompt along the lines of “fetch the unresolved errors, classify them, write the summary” takes ten minutes and works on the first try. Writing the equivalent API client, handling pagination, fields and edge cases, takes half a day and produces no impressive demo.
So the decision was rational the moment I made it. It was much less so a month later, when that shortcut had become a production link carrying the only view I had of my applications’ health.
It is a pattern I see a lot right now in companies “adding AI” to their processes. The prototype is spectacular, shipping it is painless, and nobody circles back to ask what happens the day the newest and least deterministic component in the chain stops answering.
The fix, two hundred boring lines
The replacement is about two hundred lines of Python. It reads the monitoring service’s REST API with a dedicated token, filters out the projects that are none of my business, applies a keyword based classification and writes the result. No AI anywhere on the path.
The model did not disappear, it moved. Fine grained triage, phrasing a diagnosis, deciding whether to create a task: that stays as a layer on top, one that can fail without consequences. If it does not run, I lose commentary. Before, I lost the data.
The difference fits in one sentence: the truth shown on my dashboard no longer depends on an assistant’s authentication state.
This was not the first warning
A few weeks earlier, the agent that watches the other agents started sending me outage alerts for services that were perfectly healthy. The reason: it computed the current timestamp itself, and the model got the day wrong in certain time windows. Eight false alerts before I figured it out.
The fix was to forbid it from producing a date at all. A date is something you ask the operating system for, not something you infer.
Here again, the lesson is not “AI is unreliable”. It is more precise than that: a language model is non deterministic by construction, and that is exactly what you want from it when you need rephrasing, summarising or judgement calls. The problem only shows up when you also hand it tasks where non determinism is a defect: counting, dating, adding up, fetching a value that already exists somewhere.
The rule I apply now
My personal system currently runs forty eight active agents. Twenty nine of them contain no AI at all. They are scripts: they read an API, compute, write a file, send a notification. They run on time, they cost nothing, and their failure mode is legible.
The other nineteen use a model because they do something a script cannot: read a client conversation and extract an intent, draft a text, rank heterogeneous signals, propose three options and recommend one.
That is where I draw the line. AI above the system, for judgement. Never inside it, on the path where data is acquired or computed.
The question to ask before putting it everywhere
For an executive evaluating an automation with AI inside, the useful question is not “does the demo work”. It is this one, in two parts.
If the model is unavailable for three days, what exactly stops? And does anyone notice, or does the screen keep showing numbers that look normal?
If the second part is fuzzy, the problem is not the AI. It is that a dependency was added without being held to the standards every other dependency is held to: failure detection, an explicit degraded mode, and a clear assumption about what happens when it is not there.
An automation that cannot tell you it is down is not an automation, it is a display.
If you have a process where AI settled in without that line ever being drawn, we can look together at what deserves to stay and what would be better off as a script again.