Build vs buy for AI support: the five questions that decide it

Ask whether to build or buy an AI support agent and the search results answer before you have finished typing. Every page on the first screen is published by a company that sells one, and every one of them concludes that building is slow, expensive and risky, and that you should buy. Usually from them.

They are not entirely wrong. For a lot of companies buying is the right answer, and I tell clients so. But the decision turns on a handful of facts about your product and your support load, and a vendor cannot weigh those honestly because it only has one answer to sell. Here are the five questions I use, in the order I ask them.

First, what you would actually be building

Build vs buy is rarely all or nothing. An AI support system has layers, and some of them nobody should build:

So the real question is about the middle rows: does the agent itself, the part that decides what to say, need to be yours?

1. Is the right answer the same for every customer?

If you sell one product at one price and every customer sees the same features, the correct answer to a question depends only on the question and the documentation. That is exactly what vendor agents are good at, and building your own gains you nothing.

If the answer depends on plan, add-ons, contract terms, feature flags or the asker's role, which is true of most B2B products past their first year, you need the entitlement layer described in the B2B support agent post. Vendors let you sync custom attributes for this, and for one or two plan gates that is fine. Once you have contract overrides and role-dependent answers, that logic lives in a configuration screen with no tests and no version history, and it is part of your authorisation system.

2. Does the agent need to do things, or only say things?

An agent that answers questions from documentation is a search problem with good manners. An agent that resets a user's two-factor, retries a failed export, changes a seat count or issues a credit is taking actions in your product on someone's behalf.

Most vendors support custom actions that call your API. The question is how they authenticate. If the vendor calls your API with one shared key, every action runs with full access and you are relying on the model to choose the right account. If the vendor can pass a per-user, per-account credential that your API checks like any other request, the boundary stays in your code. Ask exactly which one you are getting. For anything that moves money or changes access, it should be the second, with approval steps you control.

3. Where does the knowledge live?

If your support knowledge is a help centre and a set of macros, a vendor will index it in an afternoon and do a good job. If the answers that matter are in your database, your logs, your incident status per region and the customer's own configuration, they are not knowledge base content at all. They are tool calls, and you will be writing those tools whichever way you go.

4. What does it cost at your volume?

Vendor pricing for AI support has mostly settled on charging per resolution, often around a dollar each, sometimes on top of seat fees. Building has a large fixed cost and a small variable one. Which is cheaper depends almost entirely on volume. The figures below are illustrative assumptions, not quotes; replace them with yours:

Assumptions: about 1.5 conversations per resolution at around $0.15 in model costs each, with retrieval and two or three tool calls, and roughly one day a week of engineering to keep prompts, sources, tools and evals current. Add a build cost up front of somewhere between six and ten weeks of work, depending on how much of the entitlement and tool layer you need.

At 500 resolutions a month, buy and do not think about it again. At 5,000 the monthly costs are close and the up-front build cost tips it towards buying, unless questions one and two already pushed you to build. At 50,000, the vendor bill is a salary and a half every month, and the build pays for itself within a quarter. Two adjustments to make honestly: model costs fall every year, which favours building, and routing simple turns to a cheaper model cuts the token line further. Check, too, what the vendor counts as a resolution. A conversation where the customer gave up and left is sometimes counted.

5. Who will own it in month seven?

This is the question that most often decides it, and the one asked least. An AI support agent is not a project that finishes. The product changes, plans are renamed, a feature moves tiers, the help centre is rewritten, a model is deprecated. Somebody has to update the sources, run the evals after every change and read the conversations where it went wrong.

If you have an engineer who will own that for a day a week, and wants to, building is viable. If the honest answer is that the person who built it will move on to the roadmap after launch, buy. A vendor agent maintained by the vendor is better than your own agent maintained by nobody, and that one sentence settles more of these decisions than the cost table does.

Putting the five together

The answer is usually both

The common outcome for a B2B product with real plan complexity is a hybrid. Buy the helpdesk, the widget and the human handoff. Build the entitlement resolution, the account-bound tools and the eval suite, and expose them to the vendor's agent through its custom actions, or to your own agent if the volume justifies it. Built that way, switching from the vendor's agent to yours later is a change of caller, not a rewrite, because the parts that encode your business were never in the vendor's configuration to begin with.

Questions to ask a vendor before you sign

1. 1How do custom actions authenticate, and can they carry the asker's identity rather than a shared key?
2. 2What exactly counts as a resolution for billing, and can I see the conversations I was billed for?
3. 3How are past tickets used, and is anything from one customer's tickets retrievable in another customer's conversation?
4. 4Can I run my own test cases against your agent before each of your releases, not just mine?
5. 5What can I export when I leave: conversations, ratings, the configured sources and the action definitions?

A vendor with good answers to all five is worth buying from, and several have them. A vendor that is vague on the first or third is asking you to trust a boundary you cannot test.

Buy what is the same for everyone. Build what is specific to your customers. The mistake is buying the second because the first came in the same box.

If you are deciding between a vendor agent and your own, I will go through your plans, your support load and your current tooling and give you a written recommendation: build, buy or the hybrid, what each costs at your volume, and what to own regardless. Sometimes the answer is to buy, and the review says so. Book an AI support architecture review.