What to build, and what to buy

Two findings about enterprise AI this year point in opposite directions, and most programs are living inside the contradiction between them.

The first is that buying has won. Menlo Ventures' survey of 495 enterprise AI decision-makers, run last November, found that 76 percent of AI use cases were purchased rather than built, up from a roughly even split the year before. MIT's study of enterprise deployments reached the same place from the other side: projects led by specialized vendors reached production about 67 percent of the time, internal builds about a third as often. The reasons are not mysterious. Internal teams spend their first year on plumbing, the talent is scarce and expensive, and the models move faster than any internal roadmap can.

The second is that everyone is worried about what they bought. Andreessen Horowitz's survey of enterprise CIOs this year found that switching costs are rising rather than falling as programs move to agents, because prompts, tools, and workflows get tuned to one provider's behavior. One CIO put it plainly: changing models is now a task that can take a lot of engineering time. The same survey found 37 percent of enterprises running five or more models, up from 29 percent, which is what hedging looks like.

Both findings are correct, and the contradiction comes from the question. Build or buy gets asked once, per project, as though an AI program were a single purchase. It is a stack, and the right answer is different for different parts of it. More precisely, and this is the claim this piece makes, the line between build and buy does not run between the layers of the stack. It runs through every one of them.

The test

For any component of an AI program, two questions decide which side of the line it falls on.

Does it get better and cheaper without you? Frontier models do, every few months. Agent runtimes do, as protocols standardize. Chat interfaces do. If the industry is spending billions to improve something you would otherwise maintain yourself, maintaining it yourself is a bet against the industry.

Is it created by your own work, and would losing it set you back? Your definition of a customer across three systems. The rubric your reviewers apply. The corrections they made to an agent's output last quarter. The threshold above which a refund needs a director. Nobody else can produce these, they cannot be bought, and they are what make an AI system yours rather than generic.

The first kind of thing commoditizes. Rent it, and let the vendors compete to improve it. The second kind compounds. Own it, and make sure it stays yours when every vendor underneath it changes.

The line runs through every layer

The usual build-or-buy framework is layered: buy the infrastructure, build the applications. It is tidy and it is wrong in both directions, because every layer of an AI stack contains something that commoditizes and something that compounds.

Models. Rent the frontier. It moves monthly, the cost curve falls every quarter, and routing across labs by task is how you capture both, as we described in Flash or Thinking. Own any weights you post-train on your own data. Those encode your examples, and the conditions under which training pays are exactly the conditions under which the result is worth keeping.

Infrastructure. Rent it, unless a workload's charter requires isolation. That is the one place where the decision is set by regulation rather than economics, and our operating playbook treats it as a rung chosen per workload rather than a default for the program.

Orchestration. Rent the agent runtime, the tool-calling layer, the retry logic, the memory plumbing. It is commoditizing faster than anything else in the stack, and building your own agent framework in 2026 is the equivalent of building your own container orchestrator in 2016: a large project whose best outcome is parity with something you could have rented. Own the policy that governs it: which models a team may use, what an agent may do without asking, and the thresholds above which a person approves.

Integration. Rent the standard connectors. Every vendor has one for the same fifty SaaS products, and none of them is a competitive advantage. Build, or have built, the integrations to the systems only you have: the mainframe, the homegrown ERP, the portal with no API. Those are where the valuable workflows usually live, and nobody will build them for anyone else.

Context. Rent the storage, indexing, and graph engines underneath it, which are infrastructure. Own the model of your business outright. The ontology that says what your objects are and what may be done to them, and the decision model that says who decides and what happened last time, are the least portable and most valuable assets a program produces. This is also the layer vendors are most eager to hold for you.

Measurement and workflows. Own the eval set, because it is the definition of done and it outlives every model. Own the workflow logic and the bespoke applications on top, because they encode how you operate. Rent the surfaces those workflows appear in, whether a chat interface, a channel, or a mobile app, which is the point we made about meeting the work where it happens.

Read the stack this way and both findings make sense. Enterprises that buy are right to, for everything left of the line. Enterprises that worry are right to, if what they bought includes things right of it.

Two ways to get it wrong

Build everything. The program hires a platform team, writes its own agent framework, its own model gateway, its own connectors to Salesforce, and its own chat interface. Eighteen months later it has a maintenance organization, a framework that trails what it could have rented, and a small number of workflows in production. This is the internal-build failure rate in the MIT data, and it is almost never a talent problem. It is a portfolio problem: the team's capacity was spent on the left side of the line, where it could not create advantage, and was not available for the right side, where it could.

Buy everything. The program signs with a platform that does all of it. Two years later the prompts are tuned to one vendor's models, the evaluation cases live in that vendor's console, the corrections reviewers made are training that vendor's system, and the definition of a customer exists only in a configuration nobody can export. The switching cost the CIOs describe in the Andreessen Horowitz data is not really the cost of moving models. It is the cost of recovering know-how that was allowed to accumulate on the wrong side of the line.

The second failure is the more expensive of the two, because it is invisible until the day you need to leave, and because by then the asset has been compounding for someone else.

Owning is not building

The word own is where most of this goes wrong, so it is worth being precise about it. Owning a component does not mean you wrote it, and it does not mean you run it on your own hardware. It means you can move it.

An ontology a partner built for you, running on a vendor's platform, is owned if it exists in a documented format, your engineers can read it, you can export it, and you can point it at a different runtime without rebuilding it. An eval set is owned if the cases, rubric, and results export and the harness can grade a model the vendor does not host. Weights are owned if the contract says so and the file is yours. Each of those can be built for you by someone else, and that is usually the fastest way to get them.

The opposite case is the one teams miss. A workflow your own engineers built in a vendor's proprietary configuration language, that cannot run anywhere else, is not owned. It is lock-in you paid to build.

Questions to ask before you sign

Most of this can be settled in procurement, before anyone writes a line of configuration. For anything that sits right of the line:

• Can we export our prompts, eval cases, rubrics, corrections, and context in a documented format, today, without a professional services engagement?
• Can our eval set grade a model you do not host?
• If we leave, what happens to what our people taught the system, and in what form do we get it back?
• Who owns the weights of anything trained on our data, and can we take the file?
• Is our data used to improve your product for other customers, including through safety systems and logs?

A vendor that answers these well is safe to buy from for everything left of the line. A vendor that cannot is one to rent commodities from and nothing else.

Where Fig sits

We are a deliberate combination of both sides of the line, and the combination only works if we are honest about which side each piece is on.

For the layers that commoditize, Fig is what you buy. Frontier models from several labs routed by task, the agent runtime, connectors to the tools your company already runs, the surfaces your people work in, and the governance machinery that enforces your policy. We compete to make those better every quarter so you do not have to.

For the layers that compound, Fig builds them with you in the engagement and hands them over. Our forward-deployed engineers model the ontology from your systems, build the integrations to the ones only you have, assemble the eval set from your real work, write the workflow logic and bespoke applications on top, and post-train models on your data when the conditions hold. Every one of those is exportable and yours, because a transformation that leaves your know-how inside our platform would be the buy-everything failure with better branding.

Key takeaways

• Buying won this year, and it was right to: vendor-led projects reach production about twice as often. But switching costs and lock-in anxiety rose at the same time.
• The build-or-buy line runs through every layer of the stack, not between layers. Rent what gets better without you. Own what your work creates.
• Rent the frontier, the runtime, standard connectors, and interfaces. Own the ontology, the decision model, the eval set, post-trained weights, integrations to unique systems, the policy, and the workflow logic.
• Owning means being able to move it. Having someone else build it is usually the fastest route to owning it.

The companies that come out of this decade ahead will not be the ones that built the most or bought the most. They will be the ones that knew which was which.