Our demo line runs on the production call path, on purpose

Staging parity is a myth you pay for twice; we isolate the demo by data, not by path, and test it with a probe that publishes real audio.

Where the field is

The environments literature has quietly given up on perfect staging parity. Production accumulates years of schema migrations, organic edge cases, and data combinations no synthetic snapshot reproduces; the current advice is "relevant parity" (match the runtime, database versions, and external service config that actually change behavior) plus controlled testing in production for everything else. Voice AI makes this worse than ordinary web software, because the thing being demoed IS the production behavior: latency under real telephony, turn-taking against a real carrier leg, tool calls under a live latency budget. One industry analysis attributes the majority of failed AI-calling deployments to exactly this demo-to-production gap: the demo ran on a path the product never runs in production.

So the standard vendor demo (a staged environment, a canned video, a happy-path web widget) is not just a sales shortcut, it is an engineering claim the production system was never asked to back. The interesting question is the inverse: what does it cost to demo on the real path, and how do you cap the blast radius when you do?

What we shipped against it

Olive's concierge demo line is a real phone number answered by the production stack. The routing is a config flip on the platform side, not a deploy: platform config marks the demo number, inbound routing sends it to a concierge agent, and the concierge hands off to vertical demo agents through a bridge into the voice engine. From there the call takes the same webhook auth, the same intake ingestion, and the same notification path as any paying shop's call.

The isolation is at the data tier, not the path tier. Demo agents' tools resolve against a fictional-data service: deterministic fictional shops, appointments, and lookups that behave like tenant data without touching any. That's the whole trade in one line: every service the demo exercises is production (so the demo is evidence), and everything the demo can read or write is fictional (so the blast radius is a dataset we invented). The two honest costs: a config flip in production is still a production change and gets treated like one, and the fictional-data boundary has to be complete, because any tool that falls through to real data turns a demo into an incident.

Demoing on prod created a second obligation: testing it like prod. The same work shipped an end-to-end probe that joins a web call as a media-room participant publishing a mic-like audio track, seconds of silence, then a spoken WAV. The real-audio part is not decoration: a silent join stalls the realtime model's generation and reproduces nothing. The probe drives both orderings that have actually broken, speech-first (greet, caller speaks, verbal transfer) and transfer-first (a control-API agent transfer before any caller speech, which produces an assistant-greeting-only history shape the model once rejected outright). Limit worth stating: the probe surfaces symptoms (final status, transcript) but cannot see engine errors itself; worker logs stay part of the loop.