Why Most Agent Demos Don't Survive Contact With Production

Every impressive agent demo has the same secret ingredient: someone, at some point, ran it more than once and only recorded the run that worked. That isn't dishonest, exactly — it's how demos have always worked, in software and everywhere else. But it means the gap between "we have an agent that does this" and "we have an agent doing this in production, today, for real users" is routinely underestimated by an order of magnitude, and the underestimation isn't about the model being less capable than it looked. It's about everything the demo quietly didn't have to deal with.

We've watched enough of these transitions to notice a pattern: the parts that make a demo compelling — a clean task, a cooperative input, a single confident run — are almost exactly the parts that production strips away first.

The demo is one trajectory; production is a distribution

A demo shows a single path through the system, chosen because it's the path that works, often after a fair amount of quiet retrying off camera. Production doesn't get to choose its inputs. It gets whatever the actual population of users, documents, and edge conditions happens to throw at it, and that population always has a long tail the demo never sampled.

Concretely: the demo's document is well-formatted; production's includes a scanned file with a table that doesn't parse cleanly. The demo's user asks a clear question; production's user asks something ambiguous, or asks two questions at once, or asks something the system has no tool for and should say so instead of guessing. None of these are exotic failures. They are the median case once you're operating at any real scale, and a system that was tuned against one clean trajectory has no particular reason to behave well against a distribution it never saw.

There's a specific flavor of long-tail failure worth naming directly: content the agent processes that wasn't written with the agent in mind. A document containing text that looks like an instruction — boilerplate at the bottom of a form, a comment embedded in a file, a snippet inside a customer message — can get treated by an under-defended system as though a legitimate user typed it. A demo never surfaces this because the demo's inputs were, invariably, written by someone who wanted the demo to succeed. Production inputs make no such promise, and a system that doesn't clearly separate trusted instructions from untrusted content it merely happens to be reading is exposed to a failure mode that has nothing to do with the model's raw competence.

Error recovery is where the real engineering budget goes

Here's a rough but useful rule: in a demo, the tools always succeed. In production, tools time out, return malformed data, hit rate limits, or fail for reasons that have nothing to do with your agent and everything to do with some upstream service having a bad afternoon. What the agent does next is the entire game, and it's almost never shown in a demo because "here's what happens when the call fails and we retry with backoff and then fall back to a cached result and then tell the user we couldn't complete this part" doesn't make for a compelling thirty seconds of video.

This is genuinely most of the engineering effort in a mature agent system — not the first successful path, but the dozens of recovery paths for when the first one doesn't work. Does a failed tool call get retried, and how many times, and with what backoff? Does the agent try an alternative approach, or does it need to tell the user honestly that it's stuck? Is there a difference in how you handle a transient failure — a timeout worth retrying — versus a structural one, like a tool that will never succeed for this particular input no matter how many times you call it? Teams that skip this layer end up with agents that either loop indefinitely chasing a dead end or fail silently in a way nobody notices until a user complains.

There's also a design decision demos never have to make, because they never fail partway through: what does the agent hand back when it can only complete part of a multi-step task? A pipeline that either finishes cleanly or throws an exception is easy to reason about. An agent that gets three of five steps done before hitting a wall needs an explicit answer for whether it reports the partial progress, rolls back what it already did, or holds the result and asks for guidance — and "explicit answer" is the operative phrase, because leaving it undefined just means the system will pick one of those behaviors essentially at random, based on whatever the model happens to generate in the moment.

The cost curve nobody puts on the slide

A single-shot prompt has a cost you can predict almost exactly: one call, roughly known input and output length, done. An agentic loop has a cost that's a distribution, and distributions have tails. Most requests might resolve in two or three steps. A meaningful fraction will hit five, or eight, or occasionally spiral toward whatever ceiling you've set, and every one of those steps is a full model call with its own token cost.

The number that actually matters for a business isn't cost per attempt — it's cost per successfully completed task, and those two numbers diverge fast once you account for retries, failed trajectories that still burned tokens before giving up, and the steps spent recovering from errors that a cleaner system wouldn't have hit in the first place. A demo never has to reckon with this, because a demo runs once, on a good day, and nobody's tracking the aggregate spend across ten thousand real conversations with a long tail of expensive ones. Production has to reckon with it immediately, because that number is what determines whether the product is viable at all.

It helps to think in terms of two different numbers a team should be watching, not one. The first is the average cost of a single attempt — easy to estimate, easy to put in a spreadsheet. The second is the cost of the attempts that don't finish cleanly: the trajectories that hit a tool failure, loop past a sensible step count, or get abandoned partway through and re-run from scratch. In a demo, that second number is always zero, because a demo only ever shows the run that worked. In production, over any meaningful volume, it's rarely zero, and a team that hasn't instrumented for it is, in effect, running a business without visibility into a real and growing line item.

Confidently wrong is worse than obviously broken

A script that crashes tells you something is wrong. An agent that completes its loop, returns a clean, well-formatted, entirely plausible answer, and is simply incorrect tells you nothing — until the consequences show up somewhere downstream, sometimes much later and sometimes in a context where the mistake is expensive to unwind. This is, in our view, the single most underrated production risk in agentic systems, because it doesn't look like a bug. It looks like a normal, successful response.

Demos are structurally protected from this problem, because the person running the demo usually already knows the right answer and would notice if the agent got it wrong — so wrong-but-confident answers get filtered out before anyone outside the room sees them. Production has no such filter unless you build one deliberately: verification steps, sanity checks against known constraints, confidence signals that trigger a human review, or simply designing the system to say "I'm not sure" instead of guessing when the underlying evidence is thin. None of that shows up in a two-minute walkthrough, and all of it is the difference between a system you can trust and one that merely sounds trustworthy.

One pattern is worth naming here, because it's unglamorous enough that demos never bother with it: a second, narrower model call whose only job is to check the first answer against the specific evidence that was gathered, before anything reaches the user. It's not a guarantee of correctness — nothing is — but it catches a meaningful share of the cases where an agent's fluent, confident tone outran what its own tool results actually supported, and it costs a fraction of what the original task did to run. Demos skip it because it adds a step that isn't needed to impress anyone watching a single successful run. Production skips it at its own risk.

The ground keeps moving under you

An agent built and tuned against one version of a model is not a fixed artifact — it's a system with a dependency that updates on someone else's schedule, and provider-side model updates can shift behavior in ways that break carefully tuned prompts, tool-selection habits, or edge-case handling without any code in your own system changing at all. A demo, recorded once, never has to survive this. A production system does, indefinitely, for as long as it keeps running.

The teams that handle this well tend to have something a demo never needs: a standing set of evaluation cases — real or realistic tasks with known-good outcomes — that they can rerun against a new model version before rolling it out, so a silent regression gets caught in a test suite instead of in front of a customer. Building that evaluation harness is unglamorous, unrewarded-in-the-moment work, and it's exactly the kind of work a demo timeline never has room for, which is precisely why its absence is so often what separates a project that survives its first year from one that quietly gets rewritten.

What actually separates the projects that last

The uncomfortable truth is that none of this is really about the agent. It's about everything a demo is allowed to skip and a real system is not, and the teams that internalize that early stop asking whether they can get an agent to do something and start asking the more useful question: what does it cost, in engineering time and real dollars, to make it do this reliably, for the thousandth request as well as the first. That question rarely gets a satisfying answer in the first sprint, and treating that as a failure rather than the normal cost of building something durable is usually where the real trouble starts.