Choosing an AI stack feels like it should be about models. In practice the consequential decision is architectural: for each layer of the stack, do you build it, buy it, or wrap a vendor's? Get this wrong and you either pour engineering into rebuilding commodities or hand your roadmap to a vendor at a layer you can't easily leave. Here's a framework for deciding without regret.

Map the stack first

A typical AI application has layers, roughly: the model (the LLM doing the inference); the orchestration (prompts, chains, agent loops, tool-calling); retrieval (embeddings, vector search, RAG); data and pipelines (getting your content into a usable form); the application (your actual product UI and logic); and observability (logging, evaluation, monitoring). Each layer has a build/buy/wrap decision, and they're not all the same answer.

The default: don't build commodities

Start from a strong prior — most of this is commodity, and building it yourself is usually a mistake. Inference providers, orchestration frameworks, vector search, observability tools: these are mature, widely available, and identical across thousands of teams. Rebuilding them yourself burns engineering effort that should go into the part of your product that's actually yours. The classic failure is a team spending months building a generic RAG pipeline or an agent framework — infrastructure that confers zero competitive advantage because everyone has it.

The question for any commodity layer is: "Would building this make our product meaningfully better, or am I just reinventing something I could buy?" Usually it's the latter. Buy or wrap, and move on.

What's worth owning

The pieces worth building are the ones specific to you — where your domain knowledge and your data create something no vendor can hand you:

Your data layer. How your proprietary content is structured, cleaned, chunked, and enriched for retrieval is specific to your domain and often a real source of quality advantage. This is worth owning.

Your domain logic. The application-level intelligence that encodes how your business works — your rules, your workflows, your judgement — is your differentiation by definition. Nobody sells that.

Your evaluation. A test harness built from your real tasks and your quality bar is bespoke to you and pays off forever. Own it.

The pattern: own the layers that touch your unique data and domain; rent the generic plumbing underneath.

Lock-in: where it bites and where it doesn't

Not all dependencies are equally risky. The question is how hard it would be to leave.

Keep the model layer swappable. Models are improving and repricing constantly, and you'll want to switch — to a cheaper one, a better one, an open-weight one you self-host. Architect so the model is a replaceable component behind a clean interface, not woven through your code. This is the single most valuable bit of future-proofing, because the model is the layer most certain to change.

Be cautious at the data layer. Lock-in is most painful where migration is hardest — typically where your data lives in a vendor's proprietary format. Switching vector stores or knowledge bases can mean re-embedding and re-ingesting everything. Weigh that migration cost before committing.

Relax about easily-swapped tools. Observability and orchestration are usually straightforward to replace, so vendor lock-in there is low-stakes. Optimise these for convenience, not portability.

A decision checklist

For each layer, ask:

• Is this commodity or differentiating? Commodity → buy/wrap. Differentiating → consider building.
• Does building it make the product meaningfully better, or am I reinventing a wheel?
• How hard is it to leave this vendor later? High migration cost → choose carefully and keep an exit. Low → don't overthink it.
• Is the model layer swappable in this design? It should be.

The shape of a good stack

The teams that get this right end up with a recognisable shape: bought or wrapped commodity infrastructure underneath, a model layer kept deliberately swappable, and their own engineering concentrated on the data layer, domain logic, and evaluation that make their product distinct. They don't rebuild what they can rent, and they don't rent what makes them special. That discipline — knowing which is which — is most of the battle.