Build or buy enterprise AI: what changed, and how to decide

Jan 12

A year ago, conversations with enterprise technology leaders followed a predictable pattern. They had a budget for AI. They had engineering teams. They had proprietary data they believed would give them an advantage. The question was not whether to pursue AI, but how to build it themselves.

The confidence was understandable. Large organisations had watched smaller competitors deploy AI and concluded that, with enough resources, they could do the same, better, because they knew their own domain, data and workflows.

A year later, the same conversations sound different. Timelines have slipped. Internal teams that were meant to deliver production systems are still refining pilots. The question has moved from "how do we build this?" to "who can help us deploy this before next quarter?"

The numbers behind the shift

Menlo Ventures' 2025 State of Generative AI in the Enterprise report found that the balance reversed within twelve months. In 2024, enterprises built 47% of their AI use cases and bought 53%. By 2025, they bought 76% and built 24%. Over the same period, enterprise spending on generative AI roughly tripled, to about $37 billion.

MIT's research on enterprise AI points the same way. Purchasing from specialised vendors and partnering succeeded about 67% of the time. Purely internal builds succeeded about a third of the time.

The headline figures matter less than what explains them.

The model is the small part

In 2015, Google engineers led by D. Sculley published a paper that every enterprise AI team should read: "Hidden Technical Debt in Machine Learning Systems". Its central diagram showed that in a real-world machine learning system, the model code is a small box surrounded by much larger ones: data collection, verification, configuration, feature extraction, monitoring, serving infrastructure and process management. The model was the easy part. Everything around it carried the cost and risk.

A decade later, the same is true of agentic AI, only more so. Capable foundation models are available to anyone with a budget. What has not become a commodity is the scaffolding that turns a capable model into a reliable system:

Context: giving the system the right information for each task, without overwhelming it or introducing noise.
Memory: maintaining continuity across interactions, sessions, and months, so the system doesn’t start from scratch.
Evaluation: measuring not just whether outputs sound right, but whether they are accurate, compliant and useful.
Exceptions: handling the cases that don’t fit the standard pattern, with clear escalation to people.
Observability: seeing what the system is doing and why, and diagnosing failures.
Cost control: keeping usage sustainable as volume grows.
Governance: audit trails, access controls and explanations that satisfy regulators and internal reviewers.

Most internal teams scoped their projects around model integration, which is straightforward, and later discovered that the scaffolding consumed most of the time and effort.

Where building gets hard

A pattern appears across sectors. Automation handles the standard cases well, and stalls on the rest.

Legal processes: existing automation handles most routine matters, while the remaining exceptions, ambiguous cases and judgement calls still need manual handling.
Financial services: conversational systems handle education and standard enquiries, but conditional eligibility, context-dependent regulation, and decisions that must be explained to auditors multiply the required scaffolding.
Manufacturing: quote automation compresses cycle times on standard configurations, but non-standard requests, margin-sensitive customers and specifications needing engineering judgement need access to precedent that rarely exists in usable form.

The exceptions are where building becomes difficult. Addressing them takes architectural decisions about memory, learning, governance and human oversight that most initial plans did not include.

How to decide what to build

Two frameworks help.

The economist Oliver Williamson, who won the Nobel Prize for his work on transaction cost economics, explained when organisations should make something themselves and when they should buy it. Make it when it is highly specific to you, strategically central and hard to contract for. Buy it when it is common, well understood and available from capable suppliers.

Simon Wardley's mapping technique adds a time dimension. Every capability moves along a path from novel, through custom-built and product, to commodity. Building makes sense early on, when nothing suitable exists. Once a capability becomes a product or a commodity, building it yourself usually distracts from what makes you different.

Applied to AI, the conclusion is clear. Foundation models are commodities. The scaffolding around them is fast becoming a product. What remains specific to each organisation, and worth owning, is its configuration: its rules, its exceptions, its data and the decision memory that builds as it operates. The best approach for most enterprises is neither pure build nor pure buy. Buy the proven scaffolding and own the configuration.

What enterprises are really buying

The shift is not about buying software licences in the old sense. Enterprises are buying speed to production: the ability to run capabilities in weeks rather than quarters, with governance that satisfies compliance and patterns proven in similar settings. The question has changed from "what can your technology do?" to "how quickly can we be live, and what do we need to provide?"

Enterprises have learned that impressive demonstrations and pilot success do not predict production. They want evidence that a provider has solved the scaffolding before, and can apply that experience to their operation.

Trust has to be earned in stages

The most visible pilot failures were often those that promised too much too quickly. They worked in demonstrations, struggled with real variability, lost credibility with users and were quietly shelved. The failure was not technical incompetence but expectations: the system was positioned as ready for autonomous operation before it had earned that trust.

What works is progressive trust. The system starts with a limited scope, where failure is recoverable, and oversight is close. As it shows reliability, its scope widens. Autonomy is earned through evidence, not claimed in a sales deck.

Questions for any AI provider

What does your system do beyond the model: context, memory, evaluation, exceptions, observability and governance?
How many deployments like ours have reached production, and how long did it take?
What do we own: our configuration, our data, our decision memory?
Can models be changed as better ones arrive, without rebuilding?
How does autonomy widen, and on what evidence?
What do you need from us to go live, and when?

How Mitochondria's agentic AI systems fit the build or buy decision

The approach. Mitochondria provides the scaffolding as a shared foundation under every unit: context, decision memory, evaluation, exception handling, observability and governance. Each unit is then configured to the organisation's own rules, formats and systems. Models are chosen per workflow and can change as better ones arrive.

What it enables. Enterprises buy what is proven and own what is theirs. Deployment moves through four stages, starting with a limited scope and close oversight, and widening as reliability is shown. The configuration and the decision memory it builds belong to the organisation.

The impact. Speed to production without giving up what makes the organisation different, and AI capability that keeps improving with use.