Field note
The demo runs on twenty hand-picked examples. Production runs on the twenty thousand nobody looked at.
We are usually the second or third firm a company talks to. By then they have seen a demo that worked, signed something, waited a quarter, and ended up with a system nobody switched on. The post-mortem is nearly always the same, and it is not about the model.
A pilot dataset gets assembled by a person, and people assemble examples they understand. The twenty orders chosen to show the agent working are twenty orders that were already legible: complete addresses, one SKU, a customer who wrote in full sentences. That set is not a random sample of your queue. It is a sample of the part of your queue that was never the problem.
The first thing we do on any engagement is pull a genuinely random slice — usually 500 items, drawn by a query nobody gets to tune. On one wholesale client, the hand-picked set was 96% resolvable and the random set was 61%. Nothing about the model had changed. The difference was entirely in who chose the examples.
If your pilot examples were selected by a human, you have measured how well the system handles the cases that human finds representative. That is a different question from the one you are paying to answer.
Operations queues follow a brutal distribution. In the exception queues we have measured, something like 70% of items fall into six or seven recognisable shapes, and the remaining 30% are a scattering of one-offs — a supplier who sends dates as free text, a market where the postcode goes before the city, a returns reason that only exists because of one promotion three years ago.
The trap is that the 70% is what makes the demo look magical, and the 30% is where all the human hours actually go. Automating the easy majority and leaving the tail untouched can produce a system that handles most of the volume and saves almost none of the time. We have seen a deployment absorb 74% of tickets and reduce staffing pressure by under 10%, because the tickets it absorbed were the ones that took ninety seconds each.
So we measure the baseline in minutes, not counts. Before anything is built, someone times the real process across a real week. If nobody knows how long the task actually takes, the business case is a guess, and the pilot will be judged against a number that was never true.
A demo has no escalation path because there is nobody to escalate to. Production has one whether you designed it or not — and if you did not design it, the path is: the agent gets it wrong, a customer complains, someone senior hears about it, and the system gets switched off that afternoon.
Every task we deploy carries four things decided before a line of code: the accuracy bar in a number, the confidence threshold below which the agent drafts instead of acts, a named human who receives escalations, and a log that shows what the agent saw. The fourth matters more than it sounds. When something does go wrong — and it will — the difference between a fixable incident and a cancelled project is whether anyone can explain what happened within the hour.
Demos run on exported CSVs. Production runs on a system that rate-limits you, changes its schema without telling anyone, returns stale stock for ninety seconds after a write, and goes down for maintenance in a time zone you do not live in.
Our rough split on a typical build is 20% model and prompt work, 30% evaluation and guardrails, and 50% integration and data plumbing. Teams that budget for the first 20% and discover the other 80% mid-project are the ones that stall. It is worth saying plainly: if the plumbing is not in the estimate, the estimate is wrong, and no amount of model quality rescues it.
The single highest-value month in any deployment is the one where the agent does the work and nobody uses the output. It proposes, a human disposes, and both decisions get recorded side by side. You get a real accuracy number against a real queue, you find the failure shapes nobody predicted, and your team develops calibrated trust instead of either blind faith or blanket suspicion.
Autonomy is then granted per task, not per system. On one deployment the agent was fully autonomous for stock-availability replies in week five and still drafting-only for refund decisions in month seven. That is not a failure. That is the design working.
None of these questions are about AI. That is rather the point. The projects that reach production are the ones where the operational questions were settled before the technical ones got interesting.
Keep reading
Recognise the process?
Bring one process that is eating your team's week. We will tell you on the call whether it is a good candidate — and we say no to roughly a third of what we are asked about.
