Build vs. Buy vs. Wire Together: The Enterprise AI Decision Nobody Frames Right

The Question Everyone Gets Wrong

Every enterprise AI deck I've sat through in the last two years has some version of the same slide: build vs. buy. Two columns, a checklist, a recommendation. It's the wrong question, and it's costing companies millions in rework.

I watched a top-15 pharma company spend $4.2M building a custom LLM orchestration layer from scratch, then quietly retire it 14 months later for a vendor platform that did 80% of the job for a fraction of the cost. Not because the build team was incompetent. Because nobody had framed the decision at the right altitude.

Build vs. buy assumes AI is one thing you're deciding about. It isn't. A modern enterprise AI stack has at least five distinct layers, model access, orchestration, retrieval and data, governance, and interface. Each layer has a different cost curve, a different rate of commoditization, and a different half-life. Treating them as one decision is how you end up with $4M sunk into infrastructure that a vendor sells for $200K a year.

The real skill isn't picking a side. It's knowing which capability belongs where, and being willing to redraw that map every 12 to 18 months as the market shifts underneath you.

The Third Option Nobody Puts on the Slide

Build and buy get all the airtime. Wire together, meaning composing best-of-breed components (a foundation model API, a vector database, an agent framework, your existing identity and data governance stack) into something purpose-built for your environment, rarely gets named as its own strategy. That's a mistake, because it's what most successful enterprise AI programs actually end up doing.

Wiring together isn't the lazy middle ground. It's an architectural discipline. It requires knowing exactly which seams in the stack are stable enough to build on and which ones will move under you in the next model release cycle.

At Novartis, we ran something close to this across 90 countries and 1,200-plus websites, though the components were CMS and localization tools rather than LLMs. The lesson transfers directly: you don't build the commodity layer, you don't buy the differentiated layer, and you spend your integration budget making the seams invisible to the business user. That discipline is what separates a wired-together stack that scales from an integration project that becomes a maintenance sinkhole.

Decision Criteria, Layer by Layer

Here's how I actually walk a CIO or head of AI through this, layer by layer, instead of as one binary choice.

• Foundation models: buy, almost always. The rate of improvement (GPT, Claude, Gemini leapfrogging each other every few months) means anything you build here is obsolete before procurement finishes the paperwork. I have never recommended a client train a foundation model from scratch, and I don't expect to.
• Orchestration and agent frameworks: wire together. This layer is moving too fast to buy a locked platform, but it's too specialized to justify building from primitives. Use an open framework, keep your abstraction layer thin, and assume you'll swap the underlying tool in 18 months.
• Retrieval and data infrastructure: build, or at minimum own the schema and pipelines even if you buy the vector store. This is where your proprietary data lives, and it's the layer that actually differentiates your AI outputs from a competitor using the same foundation model.
• Governance, audit, and compliance tooling: buy in regulated industries, build the policy logic yourself. A pharma company doesn't build its own SOC 2 equivalent for AI audit trails, but it absolutely should own the rules for what 'compliant AI output' means in its specific regulatory context.
• Interface and workflow layer: build. This is where user adoption lives or dies, and it's the layer most tied to how your specific teams actually work. Generic AI interfaces are why so many enterprise pilots die in change management, not in the model.

Where I've Seen This Go Wrong

The most common failure mode I see is buying at the orchestration layer. A vendor sells a full agentic platform, promises it handles everything from prompt routing to tool calling to memory, and the enterprise locks in an 18-month contract. Then the vendor's roadmap diverges from the client's actual use cases, and the client is stuck rebuilding six months into a contract they can't exit.

The second failure mode is the mirror image: building the retrieval layer without owning the data quality problem underneath it. I've reviewed retrieval-augmented generation pilots where the technical architecture was sound and the outputs were still unreliable, because nobody had audited the source documents for duplication, staleness, or conflicting versions. You can wire together a flawless RAG pipeline and still get garbage answers if 30% of your knowledge base is outdated policy documents nobody archived.

The third, and the one that costs the most politically, is building the interface layer with a vendor's opinionated UI instead of your own. I worked with a commercial team that adopted a vendor's out-of-the-box chat interface for field reps. Adoption sat at 11% after four months. We rebuilt just the interface layer, kept the vendor's model and orchestration underneath, and adoption hit 64% within a quarter. The model didn't change. The seam the humans touched did.

The Trade-Offs Nobody Puts in the RFP

Every layer decision has a cost that shows up later, not in the initial proposal. Buying gets you speed and vendor-managed security patching, but it locks you into someone else's roadmap and their pricing model, which for many AI vendors is still evolving in ways that aren't favorable to enterprise buyers.

Building gets you control and differentiation, but it means you own the maintenance burden forever, including keeping pace with a foundation model landscape that changes every quarter. I've seen internal AI platform teams of 12 engineers spend 70% of their time just keeping integrations current with upstream model API changes, work that produces zero new business value.

Wiring together gets you flexibility, but it demands the strongest architectural judgment of the three, because you're the one deciding where the seams go and living with that decision when a vendor deprecates an API or a model provider changes its pricing tier without warning.

The Skill That Actually Matters

None of this is really about build vs. buy vs. wire together as a one-time choice. It's about building an organization that can re-evaluate that map every year without a full re-architecture. The enterprises winning with AI right now aren't the ones who picked the right vendor in 2023. They're the ones who built architecture flexible enough to have picked wrong and recovered cheaply.

If you're heading into a budget cycle trying to decide where your AI dollars go, don't start with a vendor bake-off. Start with a layer-by-layer map of your stack and an honest answer to one question for each layer: is this commodity, is this differentiated, and how fast is it moving? That framing will save you more money than any procurement negotiation.

If you want a second set of eyes on that map, that's exactly the conversation I have with CIOs and heads of AI before they sign anything. Book a strategy call and let's walk your stack layer by layer before you commit budget to the wrong one.