Should You Build or Buy an AI Voice Agent? Cost the Second Year

Should we build or buy an AI voice agent?

Build when the calls are the product rather than a channel to it, when you have a permanent team rather than a person, and when the domain is so specific that no supplier will ever hold the knowledge. Buy in every other case, and in particular whenever the honest answer to "who runs this in month eighteen" is a name rather than a team.

That is the whole decision rule. The rest of this article is why it lands there: the expensive part of a voice agent is not the building. It is the standing obligation to keep a conversational system correct while the business, the regulation and the models underneath it all move independently, and none of them tell you when they have moved.

It is worth being precise about what is being compared. This is not a price comparison; the price side of the question is already covered in our breakdown of voice agent pricing models, our comparison against in-house front desk staffing and our earlier side-by-side of an in-house build against a managed service. This is about who is holding what, twelve to twenty-four months after launch, and what happens on the day that person is unavailable.

Why is the first version not the hard part any more?

It has not been for a while now. The components are commodities with documentation. An engineer who has never touched telephony can wire a number to a speech pipeline, put a language model in the middle and have something that answers, understands and books, inside a fortnight of work. On a clean line, with a cooperative caller asking well-formed questions in a sensible order, it will sound better than the phone system it is replacing.

That demo is the trap, because a demonstration proves the system can succeed. It says nothing about the calls where it must not succeed at the wrong thing: the caller who changes their mind mid-sentence, the one asking for a service withdrawn last month, the one who should have been handed to a person three exchanges ago. Those calls decide whether the thing is an asset or a liability, and none appear in a fortnight of building. We have written separately about what it actually means to test a voice agent and about where an agent's rules have to live for it to be reliable.

This is a very old observation about machine learning specifically. The Google research paper that named it, Hidden Technical Debt in Machine Learning Systems, opens on the point that developing such systems is fast and cheap while "it is common to incur massive ongoing maintenance costs in real-world ML systems" (Sculley et al., NeurIPS 2015). A voice agent is one of these systems with a telephone number attached and a customer on the other end of it in real time.

So the build estimate is usually honest and usually irrelevant. It is an estimate of the cheap part.

Who owns the evaluation set when the business changes its own rules?

The evaluation set is the written record of what the agent must do and, more importantly, what it must never do. Never confirm an appointment that was not written into the diary. Never quote a price that is not in the current price list. Never promise a service the business does not offer. Never keep talking after somebody asks for a human. It exists as a fixed suite of deliberately awkward calls, each with a verdict.

Building that set once is a project. Keeping it current is a job, and it is the job that gets dropped first, because nothing visibly breaks on the day it is dropped.

Consider what changes in an ordinary business over a year. A clinician leaves and their appointment types go with them. A deposit policy appears for new patients but not existing ones. A service is withdrawn. Opening hours change over a holiday and change back. Every one of those alters what the agent must say and must never say, and almost none arrive as a ticket in an engineering queue. They arrive as a conversation at the front desk that somebody has to notice, turn into a prohibition, and add to the suite.

This cannot be done casually, because changes to a language-model system are not local. The same Google research names it the CACE principle, Changing Anything Changes Everything, and observes that it applies to essentially every possible tweak. An instruction edited to fix one confusion can degrade behaviour somewhere nobody was looking, which is what the CACE principle predicts, which is why the whole suite has to re-run rather than the part somebody thinks they touched. Our own version of this discipline is on how an agent gets verified before it speaks to a customer.

Who is on call when the phone is the front door?

For a great many businesses the telephone is not a support channel. It is the front door, and a call that goes wrong at eight in the morning is revenue that does not arrive. That makes a voice agent availability-critical, which means somebody carries a pager, which means the rotation has to be big enough to exist.

Google's site reliability engineering book is unusually specific about the arithmetic. Its teams "strive to invest at least 50% of SRE time into engineering: of the remainder, no more than 25% can be spent on-call", and it caps the load at two incidents per twelve-hour shift on the reasoning that handling one incident properly, including root-cause analysis, remediation and a postmortem, takes about six hours. Those numbers describe a team. One engineer with a phone is not a rotation, it is an availability expectation with no redundancy in it.

There is a second, quieter problem. The failure that matters here is not the agent falling over. It is the agent carrying on, fluently and incorrectly. Uptime monitoring says the service is up, and it is; it is just booking people into a clinic on a day the clinic is shut. Catching that means somebody reads calls, which is a habit rather than an alert, and habits need an owner too.

What happens when the model underneath is retired?

This one surprises people most, because it is not a risk, it is a published schedule belonging to somebody else. Whichever provider a build sits on, the lifecycle policy is theirs and it is written down.

One large cloud states that generally available models have a retirement date set programmatically at launch to eighteen months out as the standard lifecycle, with some partner models on twelve, that at retirement all inference returns an HTTP 410 Gone, that the notice is at least sixty days for generally available models and thirty for preview models, that the official replacement is only declared roughly ninety to one hundred and twenty days before retirement, and that retirement dates are not extendable. Standard deployments are auto-upgraded region by region; a deployment configured not to auto-upgrade simply stops working on the retirement date. Preview deployments are force-upgraded or terminated, with no option to remain.

Another provider publishes its own commitments: at least six months of notice for generally available models, at least three months for specialised variants, and preview models that "may be retired with much shorter notice, such as 2 weeks". A third publishes no period on the page at all: it names the "Discontinuation of Services" section of its cloud terms of service as the definition of the deprecation policy for its generative AI services, and says only that a deprecated item stays available for at least the period defined there. The single worked example in its own deprecation table, for an SDK module rather than a model, runs from 24 June 2025 to 24 June 2026. Reading your migration window out of a terms-of-service cross-reference is itself part of the job somebody has to do.

None of that is a criticism. The policies are clear and are exactly what a serious supplier should publish. The point is what they imply for a business that builds: part of your engineering calendar is now set by a third party, on a cadence the published policies put at twelve to eighteen months per model. Changing the model name is trivial. Knowing whether the new one still refuses what the old one refused is the entire evaluation suite, re-run, with a human reading the disagreements. A model that scores better on public benchmarks can behave worse on your own prohibitions, and the only way to find out is to ask it, on your own calls.

In-house, that lands on the same person who was going to spend the quarter on the thing the business actually asked for.

Who maintains the integrations when the other vendor ships a breaking change?

An agent that cannot write into the system of record is taking messages, not booking, and that difference is the whole value of the thing. The distinction is set out in taking a message versus actually booking and on our page about booking into your system of record.

The integration is also the part of the build with the shortest half-life. Practice-management systems, diaries and CRMs ship breaking changes on their own release schedules, deprecate endpoints, rotate authentication models and occasionally change what a field means without changing its name. The Google technical-debt paper names the layer this creates: glue code, the scaffolding that ends up dominating a mature system and quietly resists change. In a voice deployment it is load-bearing, because when it breaks at nine in the morning the agent does not stop, it books into nothing.

So the maintenance question is not "will it integrate", which is a launch-week question. It is who reads the changelog of every connected system in month nineteen. Our connector surface is on the integrations page, and the general architecture is on how it works.

Who answers the security questionnaire and the data-subject request?

A recorded telephone conversation is personal data from the first second, which attaches obligations that are not engineering tasks and cannot be closed by writing code.

Under the GDPR, a request from a data subject must be answered "without undue delay and in any event within one month of receipt of the request", extendable by two further months where the request is complex. A personal data breach must be notified to the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. That exception is not relief. It is an assessment somebody has to be competent to make, and to have made, inside the same 72 hours. And a processor "shall not engage another processor without prior specific or general written authorisation of the controller", and where the authorisation is general must inform the controller of intended additions or replacements so it has the opportunity to object. Build a voice agent yourself and you have assembled a chain of processors: telephony, speech, model inference, storage. That list has to be current, documented and defensible to a procurement team, and it changes whenever one of those suppliers changes something.

On top of that sits the transparency duty. Article 50 of the EU AI Act requires that providers ensure AI systems intended to interact directly with natural persons are designed so that the persons concerned are informed they are interacting with an AI system, unless that is obvious from the context. The obligation has applied since 2 August 2026, the date the European Commission confirms the Act became applicable with new transparency requirements enforced from that point. It is a small piece of engineering and a permanent piece of ownership: the disclosure has to hold on every call, including the ones where the caller talks over the opening line, and somebody has to be able to demonstrate it did. What follows for the data path is in where call data actually goes and the AI Act checklist.

The practical trap is that in a small build all of this gets assigned, informally, to the engineer who built it. That makes one person the single point of failure for the compliance posture as well as the code.

What happens when the one engineer leaves?

This is the item that never appears in a build estimate and is usually the one that decides the outcome.

Voice AI in house tends to concentrate in one engineer who understands the whole thing: the telephony quirks, why a particular refusal is worded the way it is, which two prompts must not be edited together, what the experiment that did not work proved. The risk is not that they are bad. It is that they are singular. When they take a new job the phone system leaves with them, and what remains is a running service nobody can safely change.

Two published numbers sit next to that, both from official statistics rather than from anybody selling anything. In the United States, the Bureau of Labor Statistics reported that median tenure with a current employer was 3.9 years in January 2024, and 2.7 years for workers aged 25 to 34. In the EU, Eurostat reports that of the enterprises which recruited or tried to recruit ICT specialists in 2023, 57.5% had difficulties filling those vacancies, with lack of applications the most cited reason, followed at almost the same level by lack of relevant qualifications, high salary expectations and lack of experience. Neither figure is about voice AI specifically. Together they describe the ordinary condition a build plan has to survive: the person is likely to move before the system is old, and the replacement is slow to find.

On what that person costs, price it in your own market rather than taking a blended number from anywhere, us included. Two published anchors: Eurostat put average hourly labour cost across the whole economy at €34.9 in the EU in 2025, ranging from €12.0 in Bulgaria to €56.8 in Luxembourg, and the US Bureau of Labor Statistics put the median annual wage for software developers at $135,980 in May 2025. An engineer who can run a production voice system is not the median of either distribution, and a whole-economy average is not a developer rate. Treat them as the wrong number in the right order of magnitude, each tied to a named market on a named date, to be replaced by your own recruiter's numbers before anyone signs anything.

When is building actually the right call?

Often enough that any page concluding otherwise from a supplier is worth ignoring. There are six conditions. The first three decide it; the other three are each sufficient on their own.

1. The calls are the product, not a channel to it. If telephone conversations are what customers pay for, the conversation logic is core intellectual property and outsourcing it is outsourcing the business. A collections operation or a contact centre selling call handling itself sits here.
2. You have a team, not a person. Enough engineers for a rotation that survives a resignation and a holiday, with more than one person who has read the prompts. Below that, the system is one CV away from being unmaintainable however well it was written.
3. The domain is too specific for anyone to hold it for you. Where the rules are idiosyncratic, unpublished and moving, the translation cost between your experts and a supplier's exceeds the build.
4. The volume is large enough that the unit arithmetic changes. Commercial models, per minute or per seat, are priced for the middle of the market. Above some volume the arithmetic stops favouring a service and starts favouring running the stack yourself, and the second-year burden becomes worth carrying. Where that line sits depends on your call mix, your concurrency and your language coverage. Nobody selling you a service will hand you that number, ourselves included. Work it out with your own.
5. The audio genuinely cannot leave your own infrastructure. Not a preference but a contractual, sectoral or national requirement that no third party processes the recording at all. That excludes most suppliers by construction rather than on merit, and it is a legitimate reason to build even where everything above argues the other way.
6. Full code ownership is contractually or regulatorily required. Rarer than it is claimed, and real when it is real.

If all of the first three are true, or if any one of the other three is, build, and this article is not for you. What is for you is the architecture: our technical guide to building a voice agent for debt collection sets out the layers a regulated build has to carry, including the unglamorous ones that hold up launches. Where exactly one of the three is true, the usual answer is a hybrid: own the policy and the evaluation set, which is where the knowledge is, and rent the operating burden, which is where the headcount is.

How do you cost the second year before you commit?

Cost the second year, not the build. Take the six standing items below and write a name against each for month thirteen through month twenty-four. Not a team, not a function. A name, and a second name for when the first is on holiday.

Ask the same six questions in the other direction too, including of us. A supplier whose voice capability rests on one engineer carries the identical key-person risk, arriving with an invoice attached. The follow-up to any confident answer is "who else there can do that", which is hard to answer smoothly if the answer is nobody. The shorter, structural version of this argument is on our page about build versus buy for voice AI, and the full vendor-side list is the vendor evaluation checklist.

What we offer next is a working session rather than a demo. Forty-five minutes on your actual call flow: we take the policies your front desk already follows, work through the edge cases that break them, and you keep the written version at the end whether or not anything else happens between us. It is the first draft of the evaluation set described above, and it is useful to a team that goes on to build the thing themselves. If that is worth an hour, send us the flow and we will talk it through. Where an engagement follows, it is one workflow, missed calls and after hours, roughly two weeks, before anything else moves.