The demo is the easy part

A working demo is the cheapest part of an AI system and the least informative. It proves the happy path exists. Everything that makes the system usable every day, on inputs nobody curated, still remains to be built. I have watched that remainder quietly swallow projects that looked finished on the projector.

Key takeaways

• A demo proves feasibility on inputs chosen by the person presenting it; it says nothing about the input distribution of a normal working day.
• A synthesis of 27 benchmark, taxonomy and audit papers on LLM agents finds performance degrades nonlinearly with task complexity, and component success does not guarantee end-to-end completion.
• Additional scaffolding does not consistently improve reliability; narrowing the scope works better than adding machinery.
• The work after the demo is a lifecycle: monitoring, drift detection and feedback loops, which current MLOps research treats as first-class components.
• Judge any demo by asking what happens on malformed input and who notices when quality drops.

What does a demo actually prove?

A demo is an existence proof. It shows that for some input, under some conditions, with a person steering, the system produces the intended result. All three qualifiers matter. The inputs were selected, consciously or not, by someone who knows where the potholes are. The person driving retries silently when something goes wrong. The audience sees a selection, not a sample.

None of this makes demos dishonest. A demo answers a real question: is this feasible, and roughly what would it look like. That is worth knowing, and cheap to find out. The mistake is reading the demo as evidence about reliability, when reliability was never on trial. The demo was built to win a meeting, and everything in it serves that goal.

My rule is to treat the demo as the start of the estimate, not the end. When a demo works, the honest statement is that the cheap part is done and the expensive part is now better specified.

What changes when the system runs every day?

Production removes all three qualifiers at once. Inputs arrive uncurated, nobody steers, and errors compound across steps instead of being quietly retried. The gap this opens is documented systematically. A 2026 synthesis of 27 benchmark, taxonomy and audit papers, spanning 19 distinct benchmarks, assembled a taxonomy of LLM agent failures: tool invocation and parameter errors, planning and constraint-satisfaction failures, long-horizon degradation as context accumulates, multi-agent coordination failures, safety failures under adversarial input, and measurement validity problems.

Two findings in that synthesis match what I see in practice. First, performance degrades nonlinearly with task complexity: a system that handles each step at ninety percent does not handle a ten-step chain at anything close to that. Second, additional scaffolding does not consistently improve reliability. Wrapping a fragile agent in more orchestration mostly relocates the failure. The same review notes where genuine progress holds: narrow domains, single-turn tool use, short-horizon tasks. Constrained scope is not a compromise; it is the condition under which these systems currently work.

Why do benchmark scores not settle the argument?

Benchmark results are demos at scale, and they inherit the same selection problem. The tasks are fixed, the distribution is known, and the score summarises performance on that distribution rather than yours. The synthesis cited above puts it bluntly: reported benchmark gains often obscure recurring failure modes that keep being documented across otherwise unrelated evaluations.

A leaderboard position answers the question the leaderboard asks. Whether a system survives your Tuesday afternoon traffic is a different question, and no public number answers it. The only score that predicts production behaviour is one computed on your own data, which is why the first piece of engineering after any demo should be measurement: log every model call, label a sample of real traffic, and watch the number move over time. I made the same argument about masking layers in why the masking layer matters more than the model.

The incentive problem has no methodological fix. Demos and leaderboards exist to persuade. Production metrics exist to disappoint you early, and a team that has only ever built the persuasive kind of evaluation has never been disappointed at the right time.

What does it take to close the gap?

The distance between demo and daily operation is filled with unglamorous components: monitoring on real traffic, drift detection when the input distribution shifts, feedback loops for correcting the system, access control, data masking, audit trails, and a plan for the day your model version is retired. None of these appear in a demo, and each takes longer than the demo did.

Research infrastructure is catching up to this reality. A recent framework for LLM-orchestrated data pipelines dedicates specialised agents to ingestion, monitoring and drift detection, includes human-in-the-loop checkpoints, and reports drift recovery among its lifecycle-level reliability improvements. Whatever one thinks of the architecture, the allocation of effort is telling: the post-deployment half of the lifecycle now gets as much machinery as training, because systems fail there, not on the projector.

The practical conclusion is budgetary. If the demo took two weeks, the production system is a matter of months, and most of those months go into components the demo audience will never see. A team that plans for this is slower to celebrate and far more likely to still be running a year later. This has not made me popular in demo meetings.

FAQ

How can I tell whether an AI demo will survive production?

Ask three questions: what happens on malformed input, who notices when output quality drops, and what is explicitly out of scope. A team that answers concretely has engineered for the boring days. A team that answers with another demo has not, and the gap will surface after the contract is signed.

Why do agent demos look so much better than agent products?

Agent demos are short-horizon and steered, precisely the conditions where the research literature finds agents reliable. Documented failure modes, degradation over long contexts, planning errors and compounding tool mistakes need time and complexity to appear, and a five-minute demo offers neither.

Should teams stop building demos?

No. A demo is the cheapest way to test feasibility, negotiate scope and expose hidden assumptions with stakeholders. The failure mode is treating it as evidence of production readiness. Present a demo as an existence proof with a price tag attached, and it does honest work.

What should be built first once the demo convinces everyone?

Measurement. Log every model call, hand-label a few hundred real examples, and compute a quality number you can watch weekly. Every later decision, about scope, retraining or cancellation, depends on that number existing. Register the thresholds before the numbers arrive; the practice is described in why I pre-register a kill-gate for every experiment. Features can wait; the ability to notice degradation cannot.

References

• Wael Albayaydh, Rui Zhao, Ivan Flechais. Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents, 2026. arxiv.org/abs/2607.05775
• Aueaphum Aueawatthanaphisut, Badri Raj Lamichhane. Trustworthy Self-Composable Big-Data-as-a-Service: An LLM-Orchestrated Multi-Agent Framework for Automated Data Engineering, AutoML, MLOps Deployment, and Drift-Aware Lifecycle Optimization, 2026. arxiv.org/abs/2606.17915