There are three ways to put an AI voice agent on your phone lines: build it yourself on a platform or API, buy a configured off-the-shelf product, or engage a managed service that builds and runs the agent on your calls. These are not three price points for the same thing; they are three different answers to who owns the prompts, the integrations, the telephony, and the regressions after go-live. Build gives you control and makes your engineers responsible for all of it. Buy gets you live fast on the vendor's template and struggles where your calls deviate from it. Managed puts a vendor's team on your specific call types and keeps them tuning in production. This guide lays out what each model actually commits you to, when each one is the right choice, and the questions that reveal which model a vendor really is.
What are the three deployment models for voice AI?
The build model means your engineers assemble the agent from a voice AI platform or from raw APIs: speech recognition, a language model, text to speech, telephony, and the glue between them. You write the prompts, build the tool integrations, run the evaluations, and operate the result. The buy model means you purchase a product that already is a voice agent for a defined job, such as appointment reminders or after-hours answering, and configure it: your greeting, your hours, your calendar connection. The vendor owns the machinery; you fill in the template. The managed model, sometimes called forward-deployed, means the vendor's engineers build the agent on your actual call recordings and your systems, deploy it on your lines, and keep working on it after launch, reviewing transcripts, handling edge cases, and absorbing model updates. The distinction that matters is not features. All three models can produce an agent that answers a phone. The distinction is where the ongoing work lands, because a voice agent is not a static artifact: calls drift, systems change, and models update underneath it. For what that agent does on a call regardless of model, see our AI voice agents overview.
Want this mapped against your own call and claim volume? Book a 30-minute audit
What does building on a platform actually commit you to?
More than the demo suggests. The platforms are genuinely good, and getting a prototype to hold a conversation is fast. The commitment is everything after that. Your team owns the prompts, which means owning the process for changing them safely: an evaluation suite, test call sets, and review of production transcripts, because a prompt edit that fixes one call type quietly breaks another. Your team owns the tool integrations, and the failure handling around them, since a scheduling API that times out mid-call is now a conversation problem, not just a backend one. Your team owns telephony: numbers, forwarding, transfers, audio quality, and the debugging that spans your carrier and your platform. And your team owns regressions from below, because when the underlying model updates, agent behavior can shift without any change on your side, and someone has to notice, measure, and correct it. Build is the right model for product companies with engineers assigned to own voice as part of the product. It is the wrong model when the agent is operational tooling and the engineers have other jobs, because the maintenance load does not go away; it just goes unstaffed.
Flexbone works on the managed side of this choice, and the reason is the audit: deciding what to automate requires someone to read the calls first, and that work does not come with a platform license. See AI voice agents.
See what AI can run at your facility. In a 30-minute audit we map the calls, eligibility, and follow-ups Flexbone can take off your team first.
Book an auditWhen is buying a configured product the right call?
When your use case matches the template, buy is fast and cheap, and that is a legitimate win. A single, simple, well-bounded call type, such as appointment confirmations, basic FAQs, or a standard after-hours intake flow, maps cleanly onto a product built for exactly that. Setup is configuration rather than engineering, time to live is short, and pricing is predictable. The honest limit is that the product is template-shaped, and your calls eventually are not. The template holds until a caller asks something one step outside it, needs a system the product does not integrate with, or triggers a workflow that requires knowing how your business actually works. Those calls do not fail loudly; they get deflected, half-answered, or dumped to voicemail, and they show up later as complaints rather than error logs. So the question to ask before buying is not "can it handle my main call type" but "what fraction of my real calls are inside the template, and what happens to the rest." If the answer to the first part is most of them and the remainder can route to staff, buy is defensible. If your call mix is varied or your systems are specific, the template becomes the ceiling.
What does a managed or forward-deployed model look like?
In the managed model, the vendor's engineers do the build, on your calls instead of a generic template, and then stay. An engagement starts from evidence: recordings and logs of your actual call traffic, which define what the agent must handle rather than what a demo script imagines. The team builds the agent against your systems of record, deploys it on a narrow slice of traffic, and then does the part that distinguishes the model: continuous tuning in production. They read transcripts, catch the edge cases the first version missed, adjust behavior, and absorb model updates before drift reaches your callers. You are not handed a dashboard of prompts to maintain; the vendor is on the hook for the agent's behavior as an outcome. This is the model Flexbone operates. The tradeoff is real and worth stating plainly: you give up direct control of the internals, and the service costs more than a self-serve template, because sustained engineering attention is in the price. The comparison that makes the decision clear is not managed versus the buy model's sticker price; it is managed versus the loaded cost of your own team doing the build model's maintenance forever.
How should you decide between the three?
Four questions do most of the work. First, do you have engineers whose actual job will be this agent? Not engineers who could do it, but headcount assigned to own it after launch. Without that, build is a prototype with no operator. Second, how standard are your calls? A single bounded flow points to buy; a varied mix with edge cases and judgment points away from templates. Third, how deep are the integrations? Reading a public FAQ is template work; writing back to a scheduling system, a TMS, or a claims platform with your business rules is engineering work someone must own. Fourth, how fast does your environment change? Seasonal call patterns, new locations, changing payers or carriers all mean the agent needs ongoing tuning, and the model you pick determines who does it. Cost belongs in the decision too, priced honestly: platform fees plus engineering time for build, subscription plus the cost of unhandled calls for buy, service fee for managed. Our breakdown of what an AI voice agent costs and our pricing page show how we structure the third model.
What questions expose which model a vendor really is?
Vendors blur these categories in sales conversations, so ask questions that force the distinction. Who writes and changes the prompts after go-live: your team in a dashboard, or their engineers? Who reads production transcripts, and on what cadence? What happened to their deployed agents the last time an underlying model was updated, and who noticed first? When a call type you did not anticipate starts appearing, what is the process and who does the work? Ask for the failure story, not the success story: a call the agent handled badly, and what changed as a result. A platform vendor will answer these with tooling, which is honest; you are the operator. A template vendor will answer with configuration options, which tells you where the edges are. A managed vendor should answer with named process: people who review calls, a cadence, and examples from live deployments. Any vendor who cannot say who owns a regression has told you the answer: you do.
If you want to see what the managed model looks like on your actual call mix, book a call with Flexbone and we will walk through your call types, the systems involved, and what the first narrow deployment would cover.