Build, buy, or assemble
The build-versus-buy question is the wrong shape for the intelligence layer, because the real decision is which parts you can afford to have someone else own.
Build versus buy is framed as a single decision and it never is. An intelligence layer is a stack of components with very different characteristics: models, orchestration, retrieval, integration, evaluation, and the workflow logic that encodes how your business actually operates. Deciding them together is how businesses end up either rebuilding commodity infrastructure or renting the one part that constituted their advantage.
Decompose it. For each layer, the question is not whether you could build it. It is what happens to you if the party that owns it changes its pricing, its terms, or its mind.
| Layer | Sensible default | The test that overrides the default |
|---|---|---|
| 01Foundation model | Buy. It is capital-intensive, commoditising, and improving faster than you could match. | Override only for data residency or unit economics you can demonstrate at real volume. |
| 02Orchestration | Assemble from open components you can read and fork. | A framework that hides control flow you need to debug costs more than it saves. |
| 03Retrieval and data | Own. The corpus, its metadata, and its permission model are yours. | The index can be a vendor. The content, ownership, and freshness path cannot be. |
| 04Workflow logic | Build. This is the encoding of how your business decides things. | There is no override. If this lives in a vendor, your process is their feature. |
| 05Evaluation | Build. The definition of a correct answer is yours and nobody else has it. | Tooling can be bought. The rubric and the dataset stay in-house. |
| 06Observability | Buy the plumbing, own the traces. | Any vendor that will not export your full trace history is a lock-in you have not priced. |
Buy the parts that are becoming cheaper. Own the parts that encode how you win. Most procurement gets this exactly inverted.
The exit test
For each vendor in the stack, answer one question honestly: if they tripled their price or shut the product tomorrow, what happens? If the answer is a weekend of work, buy freely. If the answer is that your operation stops or that a year of accumulated context is unrecoverable, that layer needed to be owned regardless of how good the product is.
Run the test on data as well as software. Your prompts, your evaluation sets, your trace history, and your corrections are the assets that compound. A vendor that holds them without an export path is not a supplier, it is a dependency with a renewal date.
Assembly is the underrated middle
The framing that gets lost is assembly: composing open components inside infrastructure you control. It gives you the speed of buying with the ownership of building, and it is the right default for most of the middle of the stack. The cost is that you carry the integration work rather than a vendor carrying it, which is a real cost and usually a smaller one than it looks next to a platform licence and a migration you cannot perform.
The rule that holds across every engagement: buy capability, own context. Capability is what the models and tools can do, and it gets cheaper every year. Context is what your business knows, how it decides, and what it has learned from being wrong. That is the part worth owning, and it is the part most stacks accidentally give away.
Want this graded for your own stack?
A systems audit runs your operation against exactly these dimensions and hands you the report.
Request a systems audit