The Build File, issue 02. A season on running a voice build without being an engineer.
Voice agent demos work.
Not usually. Not most of the time. They work, essentially always, and that should be far more suspicious than it is.
It isn't because anyone is cheating. It's because a demo is, structurally, one call: one voice, one clean line, one question, chosen by the person doing the demonstrating. That isn't evidence. It's a sample selected by someone with an interest in the selection.
Which is fine, as long as everyone in the room knows that's what they're looking at. The problem is what happens next. The demo lands, the team feels validated, and a sentence enters the project that will cost you four months: we already have it working.
You don't. You have the first ten percent, and it looks like the last ninety.
The inversion
Here is the shape of a voice build, and it is the opposite of what everyone assumes.
Getting an agent to hold one good conversation is now a small piece of work. Genuinely small. A capable developer can do it in a few days, and the result will be impressive enough to show a board.
Getting it to hold the thousandth conversation, with the caller you didn't pick, on the line you don't control, about the product that changed last week, is most of the work. All of it is invisible in a demo, because a demo is designed — reasonably — to show the thing succeeding.
So the ratio people carry in their heads is upside down. The prototype feels like ninety percent of the project because it produced ninety percent of the visible progress. It is about ten percent of the work.
The six things a demo leaves out
Each of these is weeks. Several are months.
1. The second kind of caller. The person speaking in the demo is almost always someone on the project. They articulate, they wait their turn, and they ask questions they know it can answer. They are, without meaning to be, the easiest caller your business will ever have. The demo tells you nothing about the customer in a van with the window down, or the one from Bari, or the one who drops English product names into the middle of a sentence.
2. The path where things go wrong. Every demo follows the route where everything goes as expected. Real calls leave that route inside the first twenty seconds — the caller changes his mind, asks two things at once, gives the wrong reference number and corrects it, or wants something you don't sell. The unhappy paths aren't a subset of the work. They are the work.
3. Live data, behaving badly. Demos run against a snapshot, or a copy, or a fixture someone prepared. Nobody demos with the system running slow. Nobody demos the moment the stock figure is twenty minutes stale, which is exactly when a confident agent tells a customer something that was true earlier. This is the layer where in-house builds most often quietly die, and it never appears in the room.
4. The second language. If you sell in more than one country, a demo in one language has tested one of your markets. The others aren't a setting. They're a repeat of most of this work, and the cost isn't linear. What a voice agent actually costs to run goes through why.
5. Volume. One call at a time and forty calls at once are not the same system behaving differently. They're different systems. Nothing in a demo tells you which one you have.
6. Time. A demo is a photograph. The thing has to work in March, when the underlying models have changed beneath it, someone has edited the instructions, a supplier's data format has moved and three new product categories exist that nobody thought to test.
Why the demo is specifically seductive to you
This is the part I'd want the person approving the budget to sit with.
Of everything in a voice build, the conversation is the only component you can personally evaluate. You can hear it. You have forty years of expertise in whether something sounds right on a phone, and that expertise is real.
You cannot hear the data layer. You cannot hear how the agent behaves when the system is unreachable. You cannot hear what it's permitted to change in a customer record, or what happens at 9pm on a Saturday when there's nobody to transfer to, or how it handles the fortieth simultaneous call.
So the one part you're qualified to judge is the part that's least diagnostic — and it's also the part that's furthest along, because it's the part your team enjoyed building. Every incentive in the room points at the same wrong conclusion, and nobody in it is acting in bad faith.
That's why "it sounded great" keeps producing projects that slip two quarters. It sounded great because that's the easy part and you're the expert on it.
What to ask instead
Don't ask for a better demo. Ask for the opposite one.
"Show me three calls where it did the wrong thing."
That's the whole intervention. A team that has been testing properly will have them ready, will be slightly pleased to show you, and will already know why each one happened. A team that can't produce three has not been looking for them — which is the actual finding, and it's worth more than anything in the successful demo.
Then two follow-ups:
"What did it do when the data was wrong?"
Not unavailable. Wrong. Stale, contradictory, or pointing at a product that was discontinued.
"Who has phoned it who isn't in this company?"
If the answer is nobody, the agent has been tested on the friendliest possible population, and the results mean roughly nothing.
If you want the structured version of this, it's the twenty calls — the same instinct, written out so someone can score it in an afternoon.
The reframe
A prototype's job is not to prove the thing can work. Everyone already knows it can work; that question was settled by the whole industry a while ago.
A prototype's job is to find out how it breaks, in your business, with your customers, on your data. Measured that way, a prototype that only ever succeeded taught you nothing, and cost you however long it took to build.
Which flips what "we already have it working" means. It isn't a status report. It's a description of the starting line — and if it's being offered as a reason to shorten the timeline, that's the moment to slow down rather than speed up.
The good news is that this is a cheap thing to fix. A week of deliberately trying to break it tells you more than another month of polishing it, and it's the week that decides whether the scope you approved was the right one — which is the scoping problem, and the next thing worth getting right.
The Build File is a season for people approving voice builds rather than writing them.