The Demo-to-Production Gap Is an Evaluation Gap

Agent demos are unusually convincing and agent deployments are unusually disappointing, and the distance between the two is larger than for most software. The reason isn't that demos cheat. It's that a demo and a deployment measure different things, and almost nobody measures the second before committing to it.

What a demo measures

A demo shows that a capability exists: on this input, with this setup, the agent did the thing. That's genuine information — a year earlier it might not have been possible at all.

What it doesn't show is the distribution. The demo input was chosen, usually unconsciously, from the region where the agent works. The tools were healthy. The context was short. Nobody had been using the system for three weeks, accumulating the state that makes real inputs messy.

None of that is dishonest. It's that "can it?" and "how often, across what I'll actually send it?" are different questions, and only the first is cheap to answer.

The four things production adds

Input diversity. Real requests are ambiguous, multi-intent, malformed, in unexpected languages, or about edge cases nobody documented. A demo has one input shape; production has a long tail that is most of the volume once you count it.

Accumulated state. Long conversations, large memory stores, contexts near their limit. Behavior at turn forty differs from turn four, and no demo runs to turn forty.

Failing dependencies. In a demo, tools return quickly and correctly. In production they time out, rate-limit, return partial data, and occasionally return something wrong-but-plausible. Agent behavior under tool failure is almost never demonstrated and frequently poor.

Adversarial and careless input. Users who paste an entire document, who try to make it misbehave, and — with any external content — text written specifically to redirect it.

The eval set that closes the gap

The productive move is to build the eval set that represents production before deciding the demo means something. Four sources, in order of value:

Real logged requests, if you have any adjacent system — search queries, support tickets, existing form submissions. Even a hundred real inputs beat any number of invented ones, because the invented ones inherit your assumptions about how people will phrase things.

The ambiguous and multi-intent cases. Deliberately collect requests with two intents, missing information, or a false premise. The right behavior is often "ask a question" or "decline," and if your suite has no cases where that's correct, you've never tested it.

Failure injection. Every tool, made to fail: timeout, error, empty result, malformed response. Assert the agent degrades sensibly rather than proceeding on a wrong assumption. ⚠️ This is the highest-value category and the most commonly absent — an agent that treats an empty result as "nothing exists" produces confident wrong answers with no error anywhere.

Long-context cases. Runs that reach turn thirty, contexts that trigger your compaction path. Whatever your summarizer does, it does it in production every day and probably has never been tested.

🔍 The five-minute version

If a full eval set isn't going to happen this week, do this instead. Take the demo scenario and produce five variants:

1. The same request, phrased vaguely.
2. The same request, with a second unrelated request appended.
3. The same request, where the key tool returns an empty result.
4. The same request, at turn twenty-five of a long conversation.
5. The same request, containing information that contradicts itself.

Run each once and read the traces. This is not a rigorous evaluation and it will tell you more about production-readiness than the demo did, because every variant probes an assumption the demo silently made.

What to do with what you find

The finding is usually not "the model isn't good enough." It's a list of specific behaviors: doesn't ask clarifying questions, treats empty results as negative results, loses constraints after turn twenty, proceeds confidently when a tool fails.

Each of those has a concrete fix in the loop, the tools, or the prompt — and each is invisible until something in your process generates the input that exposes it. ✅ The teams that cross the gap smoothly aren't the ones with better models; they're the ones whose eval set contains the ugly inputs.

The takeaway

A demo answers "is this possible?" A deployment asks "how does this behave across everything real users send, when dependencies misbehave, at turn thirty?" Those are separate questions and the second is answerable in advance — with logged inputs, deliberate ambiguity, injected tool failures, and long-context cases. Build that set before you commit to the timeline, not after the deployment disappoints.