The demo was clean. Forty-three test cases, all passing. The agent took a structured input, processed it, wrote the result downstream. I watched it run a dozen times in staging, everything right.
I put it live. Three days later, I found records in the database with dates in 1970.
What the demo hid
The test inputs had date fields formatted consistently. ISO 8601, clean strings, nothing unusual. In production, one upstream system sent dates in a different format. The agent read the field, made a plausible guess about what it meant, and wrote the result. No exception, no warning. Just a wrong date, written confidently, downstream at 3am with no one watching.
The failure mode was not dramatic. The agent did not hallucinate in the way people imagine. It treated an ambiguous input as an unambiguous one, picked the most likely interpretation, and was wrong. Exactly the kind of quiet, confident wrongness that is hard to catch because nothing breaks. The output looks fine. The data type is correct. The value is just from 1970.
I had tested the happy path forty-three times. The bad path happened on day three.
The fix nobody wants to write
I added a validator between the input and the agent, and another one between the agent's output and the write operation.
The first one checks that required fields exist, that date strings match expected formats, that string lengths are within bounds. If anything fails, the item does not reach the agent. It goes to a review queue instead. No agent call, no write, no silent corruption.
The second one runs after the agent produces its output. Before anything is written downstream, the schema gets checked. Required fields present. Types correct. Values within expected ranges. If the output fails, same result: review queue, no write.
The agent itself did not change. The model did not change. The fix was wrapper logic that most production systems already have for traditional software and that almost no one thinks to add for AI outputs.
At Agent Enterprise (aienterprise.dk), where I run the full agent operation, this is now the default. Every agent that writes to a persistent system has both checks. The agents do not get to decide whether their output is well-formed enough to write. The validator decides.
The entire fix took about an hour to write. It is not interesting code.
Reliability is the whole job
The demo proved the agent could do the task. On clean inputs, on the forty-three cases I had prepared, it was excellent.
Production does not send you your forty-three cases. It sends you what the upstream system sends you, on whatever schedule, in whatever format, with whatever fields missing or malformed. The agent that works in a demo and the agent that works at 3am on a bad input are not the same thing. The gap between them is not a model problem. It is an engineering problem.
The fix was a type check on a date field and a decision about what to do when it fails. A branch in a validator that routes failures to a queue instead of letting them write. That is all.
I have since added the same pattern to every agent that writes to anything. Validate the input before it reaches the agent, validate the output before it leaves. Everything the agent touches in between is its domain. Everything outside those bounds is yours.
The demo is about capability. Production is about what happens when capability meets a case you did not design for. Reliability is the only feature that matters in that second environment, and it is almost never what the demo shows you.
Top comments (0)