Build vs Buy: Vertical Integration and Dependency Risk

A frontier artificial intelligence lab does not decide whether to build or buy in the abstract. It decides where ownership changes its strategic position. Renting a model, cloud capacity, data source, or distribution channel may be the fastest route to a working product. It may also hand the most important part of the business to someone else. The practical question is not whether buying is cheaper this quarter. It is which layers of the stack create durable advantage, which dependencies create unacceptable exposure, and how to design the system so any rented part can be replaced before it becomes a trap.

Treat the stack as a set of separate ownership choices

Model capability arrives through a stack, not through a single magical asset. Compute provides the processors and networking. Base models provide broad capability. Post-training adapts that capability to tasks, policies, style, and domains. The harness orchestrates prompts, tools, memory, retrieval, routing, and error handling. Data supplies the examples, context, feedback, and rights. Distribution determines who can actually use the system.

Each layer has its own build-or-buy answer. Renting cloud accelerators may be sensible while demand is uncertain, but large steady workloads can justify committed or owned capacity. Using a vendor model through an application programming interface (API) may be the right way to reach the frontier quickly, while owning post-training may be where the product becomes meaningfully different. Buying distribution through a marketplace can create early reach, but relying on that channel forever can make growth dependent on another company’s rules.

The strategic rule is simple but demanding: integrate where ownership changes your position, and rent where it does not. Many teams do the reverse. They spend heavily on the visible prestige layer, such as pretraining a base model, while underinvesting in the quieter layers that determine quality, repeatability, customer trust, and margin.

📌

Layer by layer. A good decision at one layer can still leave the business fragile at another.

Each layer of the stack is its own build-or-buy choice.

Dependency risk is not one thing

The phrase vendor lock-in is too broad to be useful by itself. A team cannot manage a foggy risk. It has to name the specific dependency and the specific failure mode. Price risk is different from policy risk. Availability risk is different from data-flow risk. Roadmap risk is different from a capability ceiling.

Price exposure means a supplier can raise prices or change packaging faster than you can change architecture. Policy exposure means acceptable-use rules, moderation behavior, rate limits, or account terms can change underneath the product. Availability exposure means outages, regional failures, deprecations, and capacity shortages affect your own reliability. Roadmap exposure means a model, feature, or interface you tuned around may be changed or removed. Data-flow exposure means sensitive prompts, documents, telemetry, or customer context may leave a boundary where compliance or competitive secrecy requires control. Capability-ceiling exposure means you cannot exceed what the supplier makes available at that layer.

These risks have different treatments. Price exposure may be handled with volume commitments, routing, or substitute suppliers. Policy exposure may require a self-hosted path for sensitive use cases. Data-flow exposure may require keeping certain workloads inside a controlled environment. Capability-ceiling exposure may require owning research, post-training, or specialized models. Calling all of this lock-in hides the actual engineering and commercial work.

Price exposure: your margin depends on another company’s pricing power.
Policy exposure: your product behavior depends on rules you do not control.
Availability exposure: your uptime depends on another system’s reliability.
Roadmap exposure: your optimizations decay when a supplier changes direction.
Data-flow exposure: sensitive information may cross a boundary it should not cross.
Capability-ceiling exposure: your product cannot outperform what the supplier exposes.

Vertical integration pays when ownership compounds

Building is not automatically more strategic than buying. Owning a difficult asset can be a burden if that asset depreciates quickly, requires rare talent, and does not differentiate the product. A base model that is expensive to train and merely matches outside options is not a moat. It is a capital sink with a public benchmark score attached.

Integration pays when the asset improves the company’s position over time. Post-training can compound because every customer interaction, correction, evaluation, and domain-specific example can make the system more reliable for the next customer. A harness can compound because orchestration patterns, tool schemas, memory design, retrieval policies, fallback logic, and safety checks become durable product knowledge. Rights-cleared data can compound because it is hard for competitors to reproduce legally and operationally. Owned distribution can compound because customer relationships, usage loops, and trust stay with the company rather than with a channel partner.

The opposite case is the rapidly improving outside frontier. If a rarely used task needs the strongest general reasoning model available, renting may be rational. Building a weaker version of a fast-moving external model can destroy value. The art is to rent the expensive frontier tail when it is intermittent, while building the high-volume specialized middle where a tuned asset can beat a general model on cost, latency, quality, and control.

Ownership pays only when the asset improves your position over time.

Model independence is an architecture, not a slogan

A team is not model-agnostic because it says so in a slide. It is model-independent only if the system can replace a model without rewriting the product or losing the ability to improve. That requires putting durable value outside any single model’s weights. The harness, memory, retrieval, tools, task definitions, evaluation suites, safety checks, and routing policy should belong to the product, not to the chosen model.

The practical test is blunt: if the primary model disappeared tomorrow, could the product keep improving on other models? Not every metric must remain perfect overnight, but the architecture should allow substitution, measurement, and recovery. If prompts, output formats, business rules, and customer workflows are deeply entangled with one model’s quirks, the product has become a custom wrapper around a dependency.

Model independence usually requires a normalized model interface, where models are called through a common contract. It requires keeping prompt and response-format assumptions out of business logic. It requires task-specific evaluations, so replacement candidates are tested against the actual jobs they will perform. It also requires a router that can shift traffic by task, customer, cost, latency, region, or safety requirement without a release train or a rewrite.

✅

Proof beats claims. Independence is real only when shadow evaluations show that replacement models can carry production tasks.

You are model-independent only if the product survives losing a model.

The decision leaders actually face

The board-level version of build versus buy is often framed as capital expenditure versus operating expenditure. That framing is incomplete. Leaders and practitioners are deciding which risks the organization is willing to carry, which capabilities must become core competence, and which external improvements it wants to benefit from rather than compete against.

A useful review treats each layer as an investment memo. What happens if the supplier doubles the price? What happens if a policy change blocks a customer segment? What happens if capacity disappears during a launch? What happens if a model is upgraded and the product’s carefully tuned behavior changes? What happens if a regulator or customer says a class of data cannot leave the company’s boundary? These are not abstract risks. They become contract terms, architecture requirements, staffing plans, and go-to-market constraints.

The most concrete decision is often not build everything or buy everything. It is to own the control plane. Own the evaluations that define quality. Own the harness that turns models into a product. Own sensitive data paths. Own enough distribution to avoid being replaceable. Then rent or swap models and infrastructure where the market is improving faster than you can.

Score strategic leverage: does ownership change competitive position, or only the bill?
Score workload shape: is the task high-volume, stable, or unusual enough to reward specialization?
Score external improvement: is the outside option improving so quickly that building would depreciate fast?
Score self-lock-in: would an internal build trap the team in its own architecture?
Score data-flow constraints: are there tasks, customers, or jurisdictions that require an owned path?

Agents multiply dependency risk

An agentic system does not make one model call and stop. It plans, retrieves context, calls tools, asks for clarification, writes intermediate state, checks results, and often calls more than one model. That makes dependency risk cumulative. A small policy change, output-format change, latency shift, or tool failure can ripple through an entire trajectory.

The answer is per-step substitutability. Planning, retrieval, tool selection, code generation, summarization, verification, and final response generation should each have their own evaluation where possible. If the summarization model changes, the team should not have to revalidate the entire agent from scratch. It should know which step changed, which task classes are affected, and which fallbacks are safe.

Agents also intensify data-flow exposure. A multi-step task may send the same sensitive context to several external models or tools. That can create compliance risk, secrecy risk, and customer trust risk. Even when individual models are rented, the harness, evaluations, logging policy, permissions, and sensitive-task route should be owned and designed deliberately.

An agent trajectory needs each step evaluated and swappable on its own.

Common mistakes are usually layer mistakes

The most expensive mistake is building a base model for status. Pretraining can be necessary for a small number of organizations with unique capability goals, sufficient capital, deep research talent, and a credible path to use the model at scale. For everyone else, a copy of the frontier is usually worse than the frontier, more expensive than expected, and obsolete sooner than planned.

A quieter mistake is outsourcing the layers that actually make the product defensible. If post-training, evaluations, retrieval design, routing, and workflow orchestration are all vendor defaults, the product may look differentiated in a demo but remain thin in production. The company is left with user interface code and a supplier relationship, while the learning loop lives elsewhere.

Another mistake is treating a launch channel as a permanent strategy. Partner marketplaces, platforms, and embedded surfaces can be excellent accelerators. They can also become choke points. If customer access, telemetry, pricing, and renewal motion are all mediated by someone else, the company may be renting its future distribution.

Finally, teams often declare independence without testing it. A shadow evaluation is the antidote. Run candidate models against real task classes before they receive traffic. Compare cost, latency, quality, safety, and failure modes. Keep the replacement path warm. A backup that has never been exercised is not a backup.

⚠️

Prestige is costly. The glamorous layer is not always the layer where the business wins.

A practical operating rule

Build-versus-buy decisions should be revisited as volume, regulation, customer mix, model quality, and supplier behavior change. A young product may rent almost everything to learn quickly. A scaled product may need to own more of the harness, post-training pipeline, data rights, and distribution to protect margin and trust. A regulated product may need an owned sensitive-task path from the start.

The durable rule is to own the control points and rent the replaceable capacity. Own the evaluations that define success. Own the harness that applies policy, context, memory, and tools. Own the data rights that allow learning to compound. Own the customer relationship wherever possible. Rent the fast-moving frontier when you need it, but do not let it become the only place your product knows how to think.

Vertical integration is not a philosophy of doing everything yourself. It is a discipline for deciding which dependencies are acceptable, which are dangerous, and which must be turned into owned capability before they define the limits of the company.

Key takeaways

Build versus buy is best understood as vertical integration under dependency risk, not as a simple cost comparison.
Each layer of the artificial intelligence stack has a different ownership case and a different risk profile.
Vendor lock-in should be decomposed into price, policy, availability, roadmap, data-flow, and capability-ceiling exposure.
Model independence must be engineered through interfaces, routing, and evaluations, then proven with shadow testing.
Own the harness, evaluations, data rights, sensitive-task path, and distribution wherever they create durable advantage.
Rent fast-moving frontier capability when it is rare or replaceable, and build the stable specialized middle where ownership compounds.

Glossary

Application programming interface: An application programming interface is a formal way for one software system to request services or data from another system.
Base model: A base model is a broadly trained model that has not yet been deeply adapted to a specific product, policy, or domain.
Dependency risk: Dependency risk is the chance that reliance on an outside supplier or layer will harm cost, reliability, compliance, quality, or strategy.
Evaluation: An evaluation is a structured test that measures whether a model or system performs a defined task well enough for its intended use.
Frontier model: A frontier model is one of the most capable generally available models at a given point in time.
Harness: A harness is the orchestration layer that surrounds models with prompts, tools, memory, retrieval, routing, policies, and error handling.
Post-training: Post-training is the process of adapting a trained model after its broad initial training so it performs better for specific tasks or behaviors.
Router: A router is software that chooses which model, tool, or path should handle a request based on task, cost, latency, quality, policy, or availability.
Vertical integration: Vertical integration is the choice to own multiple layers of the value chain rather than relying on external suppliers for those layers.