The pilot worked. Production is a different question
A demo runs the happy path on hand-picked data. Production runs everything it excluded: retries, idempotency, service identity, backpressure, and proof of what the agent actually did.
Most AI agent pilots succeed. That is not a sign the system is ready; it is a sign the demo was scoped to succeed. A demo runs the happy path, on data someone picked, with an engineer in the room to nudge it back on track when it drifts. Production runs everything the demo excluded — unattended, at three in the morning, on inputs nobody previewed. The gap between the two is not the model. It is the operational surface around the model, and it is where most pilots quietly stall.
The questions a demo never has to answer
Line up the questions a demo is never forced to answer and the shape of the real work appears. What does the agent do when a tool call times out halfway through a write — does it leave a half-finished record, or nothing at all? If the same request is replayed, does it create one record or two? Which identity does the agent act under when no human is watching, and what is that identity allowed to touch? What happens to the queue when the model provider degrades for forty minutes instead of failing outright? Who gets paged when something breaks, and what do they actually see when they open the trace?
None of these questions is about accuracy. Each of them is about what happens around the decision, not the decision itself. A pilot can score perfectly while every one of them is quietly ignored.
None of these are model problems
Retry semantics, idempotency keys, least-privilege service identities, backpressure, observability. This is ordinary distributed-systems engineering — the same work you would do for any service that writes to a database and calls other services. What makes it harder with an agent is the failure mode. A crashed process throws an exception you can catch. A wrong LLM output does not: it is a plausible, well-formatted answer that returns HTTP 200 and flows downstream looking exactly like a correct one.
That single property reorders the priorities. You cannot rely on the process failing loudly. You have to design for the case where every layer reports success and the content is still wrong — which means the record of what the agent did has to be engineered as carefully as the action itself.
The last meeting
Then comes the meeting that decides whether the pilot ships. Risk, or an auditor, or a partner's security team asks one narrow question: what did the agent do on this specific case, four months ago? If the answer is a log table in the same database the application writes to, the pilot ends there. Anyone with admin rights can edit that table, and nobody can prove they didn't. "Trust our logs" is not an answer a serious counterparty accepts.
This is where the operational work meets the part that unblocks the budget. The decision record has to be written by a component with its own identity, reviewed like any other piece of production code, and made tamper-evident — the cleanest way being to anchor the fingerprint of the ledger on a chain nobody controls, so a third party can verify the record was not rewritten without having to trust the operator. The action is what the pilot demonstrates. The provable record of the action is what lets it survive contact with the enterprise.
A pilot is scored on accuracy. Production is scored on what happens when it is wrong — and on whether, months later, you can prove what it did.
Which of those questions is your pilot still missing?