Build, Buy, or Borrow: The AI Platform Decision That Decides Your Exit

Consider an illustrative steering committee. The pilot worked. Leadership wants the agent in production by next quarter. Three proposals sit on the table. The platform team wants to build an internal agent framework on open components. Procurement has a shortlist of three vendors with polished demos. A product team points out that they already call a frontier model through an API and could simply keep going. Each proposal is reasonable. Each is presented as the whole answer.

That framing is the mistake. Build, buy, and borrow are not three strategies for one system. An agent is a stack of layers that age at very different speeds, and the right answer differs for each. Choosing one verb for the whole stack means you either build things that are commodity by spring, or rent the things that make you different.

Chapter 18 frames choice as the protection that survives model churn. This essay turns that principle into a decision you can actually run in a single meeting.

**Build** means your engineers write and operate the capability. You control every detail, and you pay for every detail, including the maintenance nobody budgets for in year two.

**Buy** means you license a product: an agent platform, a governed retrieval service, an evaluation tool. You get speed and a support contract. You also inherit the vendor's roadmap, data formats, and pricing model.

**Borrow** means you call capability you neither own nor license as a product: a hosted model through an API, a public embedding service, an open-source library you never fork. Borrowing is the cheapest way to start and the easiest way to switch, provided your own code does not wrap itself around one provider's quirks.

None of the three is good or bad. Each has a cost of entry and a cost of exit. Most teams compare only the first.

**The model layer** changes every few months. Last year's best model is this year's cheap tier. Building your own frontier model is out of reach for almost every enterprise, and fine-tuning one ties you to a base that will be superseded. Borrow it, and keep a second provider ready, as One Model Is a Single Point of Failure argues.

**The platform layer** (orchestration, tool calling, tracing, gateways) changes every year or so and is converging fast. Protocols such as MCP are making it more interchangeable, which Chapter 19 describes. Building it yourself is rarely a differentiator. Buy it, or adopt an open framework, but insist on open formats.

**The context layer** (definitions, permissions, memory, curated knowledge) changes with your business, not with the market. No vendor can sell it to you because no vendor has it. Chapter 6 and Chapter 12 explain why it must be portable and owned.

**The evaluation layer** (golden questions, scoring rules, regression history) is the only objective record of what good means for your work. If a vendor holds it, you cannot even measure whether leaving would hurt. Chapter 29 treats it as the backbone of trust. Own it.

**Building the commodity.** A platform team spends nine months on an internal orchestration framework. By launch, three open alternatives do the same thing better, and the team now maintains a product nobody chose. The capability was real; the timing made it a liability.

**Buying the differentiator.** A vendor's platform includes a convenient knowledge store, so the company loads its definitions, policies, and examples into a proprietary format. Two years later, the exit cost is not the licence. It is rebuilding the meaning. The Exit Test measures exactly this.

**Borrowing without an adapter.** A team calls one model directly from fifty places, with prompts tuned to its quirks. Borrowing was supposed to be the flexible option, but the code has made it the most rigid. The Model Router shows the thin layer that prevents this.

The entry cost of any option is easy to see: licence, headcount, tokens. The exit cost is hidden, and it is the number that decides whether choice is real. Before committing to any layer, write down how long it would take, and what it would cost, to move off it.

Ask four questions per layer. Can we export everything we put in, in a format another system reads? Can we run our evaluation set against an alternative within a week? Which of our assets would need rewriting, and who would rewrite them? What does the contract say about data, notice, and price changes at renewal? Chapter 34 lists the contract clauses that matter; the AI Vendor Scorecard turns them into a score.

A useful rule: speed of entry is worth paying for only up to the point where it raises the cost of exit on a layer you need to own. Fast is good. Fast and trapped is not.

Building looks cheap because salaries are already budgeted. Buying looks expensive because the licence is a new line. Both impressions mislead. Built platforms carry on-call, security review, upgrades, and the opportunity cost of engineers not working on context. Bought platforms carry seat creep and usage tiers that grow faster than value, as The Seat Is Dead describes.

Compare the options on cost per correct outcome, not cost per month. Chapter 16 and Chapter 17 give the unit-economics frame. A cheaper platform that lowers answer quality is the most expensive choice on the table.

Buying a platform does not buy accountability. Permissions, approval gates, and audit trails must still reflect your policies, and someone in your organisation must still own each agent's behaviour. Chapter 13 and Chapter 15 cover governance and audit; whatever you buy must let you express them in your terms and export the logs.

A good test: if your regulator asked why the agent took a specific action last Tuesday, could you answer from records you hold, without opening a support ticket?

Replace the steering-committee debate with a single page that has four rows, one per layer, and five columns: the verb chosen (build, buy, or borrow), the reason, the entry cost, the exit cost, and the named owner. Anyone who wants to change a row must change the exit-cost column too.

Revisit it every six months. Layers move. A capability you built may have become a commodity worth buying; a vendor you bought may have become a lock-in worth unwinding. The memo makes those shifts visible before renewal, not after.

This is also a career artefact. The person who can write this memo clearly is doing the work Chapter 9 describes for the context engineer, and the work The Context Engineer Job Description says is worth hiring for.

**1.** Split the decision into four layers: model, platform, context, evaluations.

**2.** Borrow the model layer, and keep at least one tested alternative.

**3.** Buy or adopt the platform layer, and require open formats and protocols.

**4.** Own the context layer in a format no vendor controls.

**5.** Own the evaluation set and its regression history.

**6.** Write down the exit cost for each layer before signing anything.

**7.** Put a thin adapter between your code and every borrowed model.

**8.** Compare options on cost per correct outcome, not cost per month.

**9.** Confirm audit logs and permissions are exportable and expressed in your policies.

**10.** Record the decision as a one-page memo with named owners and revisit it every six months.

Reader question: if your main AI vendor doubled its price at renewal, which layer of your stack would be hardest to move, and why did you decide not to own it?