This turns on one question, and it is not cost.
Is running a conversational AI agent going to be a permanent internal capability for you, or is it something you want handled? Answer that honestly and the route picks itself.
Why cost is the wrong first question
Because the build is the cheap part and the visible part, and neither of those makes it the important part.
A capable in-house AI engineer in the UK runs around £90,000 fully loaded. Most teams that go this way end up needing a second, because an agent nobody maintains freezes in place. So the real comparison is not one-off build cost against a retainer, it is a permanent two-person function against a managed service.
People compare the wrong two numbers constantly and then wonder why the maths stopped working in month eight.
The risk nobody prices in
Key-person risk, and it is severe.
A production agent is four layers. The conversation, the knowledge, the integrations, the handover. All four need ongoing attention. Knowledge goes stale as prices and policies change. Integrations drift as the systems around them get updated. Edge cases surface that no test anticipated.
The moment the person who built it leaves, or gets pulled onto the thing the CEO cares about this quarter, all four start decaying quietly. A large share of internal AI builds reach roughly 60% complete and freeze there, and what is left is a liability nobody wants to inherit.
That is not a hypothetical failure mode. It is the most common one.
When in-house is genuinely right
Three conditions, and you want all three, not two.
Conversational AI will be a standing competency rather than a project. You can hire and retain that talent against everyone else currently trying to. And your integration surface is specific enough that an outside party could not reasonably learn it.
Businesses with an existing engineering team, unusual internal systems and a long-term view do meet all three. If that is you, build it, and budget for the operating rather than the launch.
When a partner is right
When you want the outcome without standing up a function to produce it.
The trade is dependency, so the thing that matters is choosing one who stays embedded rather than one who hands over a build and leaves. Ask what happens after launch. If the answer trails off after go-live, you are buying a project with a service label on it, and you will own the decay.
I run one of these, so treat that as disclosure rather than neutral advice. The logic holds regardless of who you pick.
The middle option people forget
Buy a platform and run it yourself.
You get a toolkit and the obligation to wield it. Fine if you have the team, which puts you back in the in-house column with a shorter build. For a great many operators the platform ends up half-configured, which is the worst of both.
Worth being honest with yourself about which of those you are before the licence renews.
