The Demo and the Tuesday
Almost every demo of an AI system shows the same cutout: the successful run. That isn’t fraud, it’s a format. You just should know what it leaves out.
On stage, it works. Someone types in a question, the system visibly thinks for a moment, and after twenty seconds there is a result that would have taken a person an afternoon. The applause is deserved. The task was real, and so was the solution.
And yet you have just learned almost nothing.
What a demo shows
A demo answers a single question: is this task solvable in principle by this system? That is not a small question. Five years ago, the answer for many of these tasks would have been no. Anyone who sees a model summarize a contract, query a database, and draft an email from the results today is seeing a real capability.
They just don’t see how often.
Between “can” and “reliably does” lies the entire operation. A system that solves nine out of ten cases correctly looks exactly like one that manages ninety-nine out of a hundred in a demo. In both cases, the demonstrated run goes through. The difference between the two systems is the difference between a tool and a nuisance. But on a stage it is invisible.
Why the cutout is always the same
You don’t have to assume bad intent. The format forces the selection.
A demo lasts minutes. In that time, exactly one run can be shown. Whoever picks one sensibly picks one that works. Anything else would be a strange decision. The presenter has tried the case beforehand. They know the phrasing that reliably gets to the goal. The data is prepared, because unprepared data would blow up the demo.
Every one of these steps is reasonable. Together they produce a picture that is systematically better than everyday reality.
On top of that comes a trait of today’s systems that sharpens the problem: they don’t fail visibly. Classic software crashes or throws an error message. A language model delivers a fluent, well-phrased answer even when the foundation is thin. A failed run looks, at first glance, like a successful one. In twenty seconds on a stage, nobody notices the difference. In operation, it gets noticed. Just later and at greater cost.
Three questions no demo answers
How often does it go wrong, and how do you notice? Not the average hit rate, but the distribution: which cases go astray, and do they have something in common? A system whose errors scatter randomly is manageable. One that fails systematically on a certain kind of case is dangerous. Because exactly those cases don’t appear in the demo.
What happens at step twenty? Errors multiply across chains. At a ninety-five percent success rate per step, a twenty-step process is wrong somewhere in roughly every third run. What gets demonstrated is usually a process with three steps.
Who cleans up afterward? Every system that is allowed to act produces cases that someone has to roll back. The demo ends at the result. Operation begins there.
What you could show instead
There is a demo that says more than any polished one: the run with a case the presenter hasn’t seen beforehand. From the audience, with real documents, without preparation. It takes longer, goes wrong more often, and is vastly more informative.
Almost better still: show the logs. Not the result, but the last hundred runs in live operation, with the failed ones among them. Whoever can show that has measured. Whoever has measured knows something about their system that a demo can’t give.
We have rarely seen this. Not because vendors want to hide something. But because the measurement often simply doesn’t exist.
The useful test question
Anyone sitting in front of a demo can skip one sentence and ask a question instead: How many runs do you have per day, and what share needs human rework?
The answer is either a number or an evasion. Both are an answer.
A number means someone has looked. An evasion doesn’t mean the system is bad. It means nobody knows whether it is good. And that you would be taking on the risk of finding out.
A good demo makes a claim memorable. It doesn’t make it true.