The demo ran 50 times without a failure. Then we shipped it.
Three days into production, the agent started returning confident nonsense. Not errors. Not crashes. It finished its task, wrote a result, logged success. The result was wrong. Nobody caught it for six hours.
The agent's job was to pull structured data from a third-party endpoint, summarize it, and route a decision. In testing, that endpoint always returned a list with at least one item. On day three, it returned an empty list. Valid JSON, zero items. The agent had never seen this input. It did not stop. It summarized the absence of data as if it meant something, filled in plausible context, and routed confidently.
Confident autocomplete on an empty input. That is the production failure mode demos never surface.
Why the demo hid it
Every test I ran before shipping used good inputs. Clean structure, expected ranges, the happy path. I tested for API failures. I tested for malformed JSON. I did not test for technically valid responses that meant "there is nothing here."
Demos optimize for showing what works. Production finds everything you missed. This gap exists in all software, but AI makes it harder to see. A traditional system throws an exception or returns null. An LLM writes something coherent and wrong. You have to read the output, understand the domain, and notice that "summarized one recent transaction" should have been "no transactions found." That requires a human check or an explicit assertion. I had neither.
The deeper problem: I had a handoff between the data layer and the reasoning layer with no contract between them. The data layer said "here are zero items" and the reasoning layer said "let me make sense of whatever I received." It did. Badly. No one told it that zero items was a special case worth stopping for.
Benchmarks do not show you this. A hundred happy-path runs do not show you this. The empty-list case shows up on day three, while you are doing something else.
The fix was not clever
I added a guard. Before the agent reasons over any data, it checks whether the input meets the minimum conditions for a meaningful answer. If not, it returns a structured "no data" signal and stops. The downstream system handles that signal explicitly.
That is the whole fix. No prompt engineering, no fine-tuning, no new model, no clever architecture. A check that runs before the model touches anything.
The unglamorous part is that defining "minimum conditions" for every data type the agent processes took longer than building the agent. I had to think through each input type and ask: what does "valid but meaningless" look like here? You cannot skip this. If you do not define it, the model will always find something to say. It is very good at that.
I run several agents at Agent Enterprise (aienterprise.dk), and this pattern repeats across all of them. The demo uses inputs I chose. Production uses inputs no one chose. The diff between those two populations is where your reliability lives or dies.
A piece on reliable agentic AI from Martin Fowler's platform pulled 171 points on Hacker News in June 2026. Not 45. That is not people reading about exciting new agent capabilities. That is people who have hit production and are looking for help. The practitioner community knows where the gap is.
A demo proves an agent can. Production proves it does, on the bad input, at 3am, when nobody is watching. That is the only gap worth closing.
Reliability is the only feature. Everything else is a demo.
Top comments (0)