The Demo-to-Production Tax: The 90% of AI Work the Prototype Hid

The demo worked. You typed a question, the agent called three tools, reasoned through a multi-step plan, and produced an answer that made the room lean forward. Someone said "ship it." Three months later you're still not shipped, and nobody can quite explain where the time went.

Here is where it went: the demo was 10% of the work. It was the brain. The other 90% is the plumbing — the evals, guardrails, observability, cost controls, and fallback paths that nobody claps for because they're invisible when they work and catastrophic when they don't. That 90% is the demo-to-production tax, and most teams budget for it as if it were a rounding error.

The numbers say otherwise. MIT's 2025 study of enterprise AI found that 95% of generative-AI pilots delivered no measurable P&L impact. A separate analysis put it more bluntly: for every 33 proofs of concept an enterprise starts, four reach production. That's an 88% mortality rate, and the cause of death is almost never the model. It's everything the demo let you skip.

Why the Demo Lies to You

A prototype is a controlled experiment dressed up as a product. You picked the inputs. You ran it three times and showed the run that worked. The tools were healthy, the corpus was clean, the user said exactly what you trained them to say. None of that survives contact with production, where inputs are adversarial by accident and the cost of being wrong is real.

The cruelest part is the math. Suppose your agent is 95% reliable at each step — genuinely good for an LLM calling a tool. Chain ten of those steps together and your end-to-end success rate is 0.95^10, which is about 60%. The demo was a three-step task on a good day, so you saw 86% and called it excellent. Production is a ten-step task on an average day, and now two of every five sessions fail somewhere in the middle. Nothing got worse. You just stopped hiding the compounding.

And the failures don't look like the clean errors you tested for. They look like this:

• Wrong tool, confidently. Roughly one call in twenty, the model reaches for the hotel-booking API when the user asked about hiking trails, because the embeddings put "trip" near "booking." It doesn't hesitate. It books.
• The slow dependency. A search API that returned in 3 seconds during the demo returns in 30 under load. The agent doesn't wait — it times out and hallucinates a plausible result, or it retries in a loop and triples your token bill.
• The partial success. A paginated API returns 2 results instead of 15 because of a bug upstream. The agent has no idea it's reasoning over a fragment, so it produces a complete-looking answer built on a third of the data.
• State that drifts. In a long task the agent picks Paris in step one, books a flight to CDG in step three, and recommends a restaurant in London by step five. Each step was locally reasonable. The trajectory was nonsense.

You cannot prompt your way out of these. They are systems failures, and systems failures need systems engineering. That's the tax.

Evals: The Part That Feels Optional and Isn't

The single biggest line item in the tax is evaluation, and it's the one teams cut first because it feels like testing — and "we'll add tests later" is a phrase every engineer has lied with.

But an LLM eval suite isn't a test suite. It's your only instrument for answering the question that matters every single day: did the change I just made improve the product or quietly break it? Without it, every prompt edit, model upgrade, and retrieval tweak is a coin flip you can't see the result of. You ship, something feels worse, and you have no way to tell whether it's the change, the model provider's silent update, or your imagination.

The production-grade version has two halves. Offline evals run in CI against a versioned set of a few hundred to a couple thousand labeled examples, scored by rubric, and they block the pull request when the pass rate regresses. Online evals sample 5–20% of live traffic, attach a quality score to each request, and alert you when the rolling average drifts — a 2% drop is "go look," a 5% drop is "page someone." The demo had neither. It had you, watching, deciding by vibe whether the output was good. That doesn't scale past one user, and the one user was you.

Build this early, because it's the scaffold everything else hangs on. You can't safely add a fallback model if you can't measure whether the fallback is worse. You can't tune cost if you can't see what cheaper routing does to quality. Evals are how you turn "it feels fine" into a number you can defend.

Guardrails, Observability, and the Cost of Being Blind

Loading…