The voice agents I run at Spyne are a wrapper. A language model I did not train, a speech-to-text model I did not train, a text-to-speech model I did not train, and a real-time framework I did not write. Strip those four out and there is no product. I want to start there, because "it's just a wrapper" is usually said as a dismissal, and I have spent two years finding out how much work is hiding inside the word "just."
When I first wrote this in May 2025, I made the argument the way everyone was making it at the time: by quoting valuations. A reported three billion dollar offer here, a nine billion dollar valuation there, as though the price tag proved the thesis. Since then, the specific deals I cited resolved in ways the headlines did not predict, and at least one of the companies I held up as the model got taken apart and sold in pieces. That was a useful lesson about citing valuations as evidence. So the numbers are gone from this post, and what is left is the question they were standing in for.
If the model is not yours, what do you actually own?
The model is a commodity input, and you should design like it is
The uncomfortable version first. Every capability I depend on gets better, cheaper, and more widely available on a schedule I do not control. That cuts both ways. A better model arrives and my product improves for free. It also arrives in my competitor's product on the same day.
So anything that improves when the provider ships is not a moat. It is a floor that keeps rising under everyone at once. Prompt engineering is not a moat. A nicer chat interface over the same model is not a moat. Being three months earlier than someone else is a head start, not a position.
The parts that do not move when the provider ships are the interesting ones. In my case, they turned out to be almost everything except the model.
What actually has to be yours
The workflow, not the conversation
A voice agent that can hold a conversation is a demo. The product is what surrounds the conversation: which lead gets called, when, how many attempts, what counts as reached, what gets written back to the CRM, what happens on a callback, when a human takes over.
None of that is a model capability. It is the dealership's actual follow-up process, encoded. The platform I built expresses it as a typed runtime profile per call, naming providers, prompts, tools, transport, recording, voicemail behavior, idle handling, duration limits, and transfers. That profile is the product. The model is one field in it.
The integrations nobody wants to build
The model pipeline was not the hard part. The phone system was. SIP trunking. Three carriers behind one internal telephony API. Caller identity, CNAM, and STIR/SHAKEN attestation, because an unattested number gets labeled as spam and never answered. A2P 10DLC registration for the messaging alongside it. Banned-number filtering.
This work is boring, it is slow, and it is mostly regulatory. That is exactly why it is defensible. An excellent model does not shorten carrier onboarding, and nobody gets to skip it.
The failures the provider cannot see
Model providers see requests. They do not see the caller who said hello twice and hung up because the agent went quiet for two seconds. They do not see answering machine detection returning a verdict after the agent already started speaking. They do not see what narrowband phone audio does to a model that was benchmarked on clean recordings.
Those failures are my problem, and the record of them is mine. Per-stage latency, end reasons, transcripts keyed by call and tenant and use case, false-human and false-machine rates tracked separately. That accumulated knowledge of how the system fails in the field is the asset, more than any dataset I could hand to a fine-tuning job.
The ability to grade a change
This is the one I underrated at the start, and the one I would now put first.
If you cannot measure whether a swap made things better, you cannot swap. Which means you are structurally locked to whichever provider you happened to start with, no matter how portable your code is. Evaluation is not a quality practice, it is the thing that keeps your options open.
For cost work this is the whole game. Cheaper per minute is trivially achievable and frequently worse. Task completion, transfer success, premature interruptions, and p95 response gap have to sit in the same report as the bill, or a shorter and less useful conversation reads as a win.
Reliability, which is unglamorous and non-negotiable
A chat product that fails renders an error state. A phone call that fails has a person on the other end of it, in real time, who now thinks your customer's business is broken. Disaster recovery, failure handling, and bounded behavior under load are not features anyone asks for in a demo. They are the entire difference between something a dealership will point at its inbound line and something it will not.
Provider-neutral is a structural bet, not a preference
The design decision I am most glad about is treating the runtime as replaceable before I needed to replace it.
I wrote a typed call contract while still on a managed platform, which bought nothing visible for months. Then the migration to LiveKit added a second worker behind the same contract instead of starting a rewrite, and traffic moved by profile rather than by flag day. A second worker on a different framework still runs against the same profiles, which is how a new runtime gets graded before any real call reaches it.
The cost is real and I will name it. Every contract change now has to cross two workers, and the abstraction is wrong in places where the two frameworks genuinely disagree. I pay that tax deliberately, because the alternative is that my product's shape is decided by whichever vendor's SDK I happened to import.
The part of the old argument I got wrong
The original version of this post had a section on token economics: providers profit from more tokens, wrappers profit from fewer, therefore the arrangement is unsustainable and consolidation follows.
I now think that framing was too neat. Prices per token kept falling, and the number of tokens a useful task consumes went up at least as fast, because reasoning, long context, and tool loops all spend tokens. More to the point, in my own cost breakdown the language model is not the largest line. Telephony, speech, and runtime capacity all compete with it. An analysis built entirely on token prices would have pointed me at the wrong optimization for over a year.
The thing that is genuinely unsustainable is narrower: a product whose only function is to pass text to a provider and format the reply. That gets absorbed, and it should. The providers are steadily moving up the stack, shipping agent frameworks, tool execution, and increasingly the orchestration layer too. I fully expect some of what I maintain today to become a checkbox in somebody's platform.
What I do not know
Whether owning the pipeline is the right call at low volume. It probably is not. A managed platform arrives with media transport, telephony, and interruption handling on day one, and at a small number of concurrent calls that fee is cheaper than the engineering to replace it. I owned my pipeline because of reach into the failure modes, not because of the unit price, and I would be suspicious of anyone who tells you the arithmetic works at every scale.
I also do not know where the line lands. If a provider ships credible turn-taking, carrier-grade telephony, and per-stage observability in one product, a large part of my answer to "what do you own" gets thinner. My bet is that the dealership-specific workflow, the integration surface, and the accumulated record of how real calls fail outlast the parts that are currently mine by default.
That bet is the actual content of the word "wrapper." Not whether you built the model. Whether anything would be left if the model were handed to everyone tomorrow.