Build vs buy in AI:
what weighs on the decision to build or buy

Build vs buy in AI is the choice between assembling the stack and contracting it ready-made

Building means assembling in-house the pieces that let a language model operate inside a process:

• Integrations with CRM, ERP, helpdesk, databases and documents;
• Context, with entities, relationships and definitions of each term;
• Permissions, so that each person gets only the data they can already see;
• Evaluation, with tests that measure whether answers stay correct;
• Operations, with monitoring, call logging and model switching.

Buying means contracting a platform, which delivers part of the stack, or an application, which delivers the whole use case. Either way, someone still connects the sources, sets up access and keeps an eye on quality.

Seven criteria weigh more than the team's technical skill

• Differentiation. If the process sets the company apart in the market, its logic is a strategic asset.
• Total cost over time. License, tokens, integration and the team that maintains the system.
• Time to value. How long until the first process runs on real data.
• Available talent. Engineers who know how to run probabilistic systems in production.
• Risk and governance. Who answers for an error and how permissions are enforced.
• Dependency and portability. The effort needed to switch vendor or model.
• Ownership of data and context. Where the definitions and the links between records live.

Building pays off when the process is the company's advantage

A distributor that prices freight with its own rule, refined over years, has little to gain from a generic quoting agent. In that company's build vs buy, the rule is the advantage, and handing it to a vendor that serves the whole market dilutes the difference.

Building also makes sense with proprietary data that no off-the-shelf product understands, with regulatory requirements the vendor does not cover, or with volume that makes per-call pricing more expensive than a dedicated team. In all three cases, the condition is having people to maintain the system after launch.

Buying pays off when the process is the same as everyone else's

Transcribing meetings, classifying tickets and answering security questionnaires work much the same way in almost every company. In these cases, build vs buy leans toward buying: a vendor with many customers spreads maintenance across them and delivers the first result in weeks.

Maintenance is the cost build vs buy tends to underestimate

The build budget covers delivery, and the larger cost comes later. In 1992, Ward Cunningham compared shipping first-time code to going into debt, where every minute spent on not-quite-right code counts as interest until it is repaid with a rewrite, an idea that applies to every integration and filter the team builds and maintains.

With language models, the list grows. A new model version changes the answers. A source changes its schema and the integration breaks. A team revises its access policy and the copy inside the agent goes stale. Comparing a license to a project cost leaves out the team that looks after all this for years.

Applications bought one by one repeat integration and create context silos

The risk on the buy side of build vs buy shows up with the third or fourth application. Each one connects to the CRM in its own way, keeps a copy of the permissions and learns its own version of what an active contract is. Context ends up scattered across vendors, and two applications answer the same question in different ways.

When one of them is replaced, the entity mapping, the tuned definitions and the correction history leave along with the contract.

The third way requires deciding which side leads

A common build vs buy arrangement is to buy the base layer and build the use cases that differentiate. It works when the split is written down: the base concentrates integration, context and permissions, and the team spends most of its hours on the few cases that set the company apart, with no separate integration per case.

The risk is getting stuck in the middle, with a half-adopted base and use cases nobody owns. An early warning sign is the team spending more hours maintaining connections than delivering new use cases.

The Company Brain is the base layer adopted once

The Company Brain connects the sources once and organizes the context into a knowledge graph, a business ontology and a semantic layer. Permissions are inherited from the source system, and every answer points to its source.

On top of that base, the build vs buy choice is made case by case. The team builds the agents that differentiate the company and connects purchased agents the same way, through MCP, the open protocol that links models to context sources. The context stays inside the company's perimeter when an agent or model is replaced. Each agent receives only the slice the question requires, which cuts tokens and makes it possible to use a cheaper model.

The build vs buy decision starts with an inventory of use cases

The base layer reduces repeated work and leaves the decisions with the company: which process differentiates, who owns each definition and who runs each agent. It depends on reachable sources and on someone accountable for the shared context.

The first step is to list the planned use cases and mark, for each one, whether the process differentiates the company and which sources it queries. Cases that reuse the same sources show what should go into the base. Generic cases are candidates for buying. The few that differentiate join the build queue, with a named person to maintain them.