The dashboard was green

Every failure that has cost me real time in my agent system had one thing in common. Nothing looked wrong.

No error message, no red light, no angry email. The morning briefing arrived, the status page was green, and somewhere underneath, something had quietly stopped doing its job. I usually found out days later, by accident, when a piece of work I expected simply wasn’t there.

This surprised me at first. Then it didn’t, because I had seen the same thing for years in buildings.

A building teaches you to distrust silence

In facility operations, the most dangerous alarm is the one that never fires. A sensor that has lost its connection reports nothing, and “nothing” looks exactly like “fine”. Good operators learn early that an alarm being cleared, a system being technically restored and the people who depend on it accepting that it works are three different states. A ticket marked closed tells you about the ticket, not about the room.

AI agents need the same discipline, and almost nobody building with them talks about it. Here are the patterns I have learned to look for. Each one taught me something the hard way.

Six ways a system tells you it’s fine when it isn’t

A job that never runs can never fail. A task that was defined but never actually scheduled produced no errors for weeks, because it produced nothing at all. Silence is not health. Now every scheduled job has to prove it ran, not just avoid reporting that it failed.

“Nothing to check” got scored as a pass. A safety check looked for problems in a list that, because of a setup mistake, was empty. It found no problems, so it passed, every day. This turned out to be the most common defect in the whole system. An empty input should be treated as a failure, never as a clean bill of health.

The recovery layer hid the outage. I built automatic retries so that small failures wouldn’t need me. They worked so well that a growing failure stayed invisible while output quietly fell. Self-healing is good. Self-healing with no report of what it healed is a cover-up.

The checker was the fault. For a while the health monitor reported failures that weren’t real. Every number it had produced until then was worthless. The lesson is uncomfortable: whatever watches your system needs its own watcher, or at least an occasional test against a known answer.

An honest warning became wallpaper. One warning was accurate and showed up every day. Because it showed up every day, it was read as noise, until the day it mattered. My rule now is that “unverified” is a task, not a state. If something can’t be confirmed, someone has to go and confirm it.

A rule on paper is a suggestion. An agent that was allowed to draft once took a step that only I should take. The policy said it shouldn’t. Nothing in the code stopped it. Now the rules that matter are enforced at the point of action, and the off switch sits where the work leaves the building, not at one of the doors it can come in through.

What this means for anyone deploying AI

None of these failures were about intelligence. The models were capable. The problem was always status: a system describing itself more confidently than the facts allowed.

That changes the question I ask, whether I’m looking at my own agents or a vendor’s product. I no longer ask how smart it is. I ask three things.

1. Show me your unknowns. Time that can’t be accounted for should be its own category, not folded into “normal”.
2. Show me what you fixed by yourself. Every automatic recovery should leave a record a human can read.
3. Show me who checks the checker. If the answer is the same system that did the work, the answer is no one.

The real lesson

People expect AI to fail loudly, with nonsense answers and obvious mistakes. Those failures are easy. The expensive ones are polite. They arrive on time, look tidy and say everything is fine.

The fix isn’t more intelligence. It’s the oldest habit in operations: trust the room, not the ticket.

These are my personal views, based on running my own system at home.