Value Accrues to the Product Layer

The thesis that, in the AI stack, durable economic value accrues to the product layer, the applications people actually use, rather than the model or API layer, the raw inference sold by the token. Brendan Foody: "The value will accrue to the product layer. I don't think about OpenAI as much as an API business. How low the switching costs are for API: it's a line of code to switch back and forth and see how new models are doing. It's really going to be in the product layer."¹

The argument

API switching costs are near zero: swapping one model provider for another is a line of code, and buyers continuously test new models against each other, so no API vendor can hold pricing power on raw capability alone. Capability itself is commoditizing as models converge and intelligence becomes cheap to access, so the model layer increasingly behaves like a commodity input. Customization is now cheap and spreads widely, since data-efficient reinforcement-learning customization lets many application-layer companies build differentiated capability without frontier-scale spending, diffusing value outward to wherever products actually meet customers. Defensibility therefore lives at the product layer, in distribution, workflow integration, proprietary data and evaluation sets, and brand, rather than in the model API itself.¹

The commodity counter-frame

A natural counterpoint is that commodities can still anchor great businesses, since oil is a commodity and yet the companies that drill and sell it are enormous. The reconciliation is that even if raw inference is a commodity, the real question is who captures the margin, and the answer is that the capture point sits downstream at the product layer rather than at the commodity itself, in the same way value in oil accrues to those who control reserves, refining, and distribution rather than to the spot price.¹

The AGI override

There is a sharp caveat rooted in the foundation-model founders' own logic. If value accrues to the product layer for roughly a decade and then becomes irrelevant once artificial superintelligence arrives, racing to build the model layer is rational despite near-term value living at the product layer. This is part of why researchers who leave established labs keep starting new foundation-model companies: the bet is on the long-horizon endgame, not on near-to-medium-term value capture. The two theses are not contradictory, they simply operate on different time horizons.¹

Why it matters

It guides where to build, favoring application and product companies over pure API resale, which is treated as structurally weak. It connects to disintermediation dynamics, since cheap, swappable models accelerate the risk that thin product wrappers around a single model get displaced, and it rewards companies that own multi-product platforms and the customer relationship rather than a single point solution.¹

The marketplace version of this argument comes from Brian Chesky: the guest-facing Airbnb app is only about 20 percent of the company, with the other 80 percent being the operation itself, payments, customer-service adjudication, a three-million-dollar damage guarantee across roughly a million homes a night, and the host network.² The guest app would be fairly easy to copy in an age of AI, so even if a rich agentic layer commoditizes discovery and booking, value stays with the operational and network layer an agent cannot replicate. This both supports the thesis and complicates the simpler version of the disintermediation story, since the chatbot interface, however capable, does not capture the underlying moat.

Tensions and open questions

Model-layer moats may be underrated: frontier scale, distribution, and a genuinely integrated product can blur the line between model and product for chat assistants, letting the model layer capture value after all. Switching costs also rise with customization, which cuts against the thesis from the other direction, since a heavily customized model with proprietary evaluation environments is no longer a one-line swap, reintroducing lock-in closer to the model layer. And the argument is naturally made by application-layer founders with an obvious interest in the conclusion, directionally mainstream but not disinterested.¹

Where the differentiated capability is created

A further refinement holds that because the data and verifiers for enterprise verticals largely do not exist online, differentiated capability has to be manufactured: humans build the context and evaluation sets that make a model good at a specific workflow. That production work happens at the application and product layer, not in the base API, so value pools where the evaluation and context engineering actually happens, and the durable winners pair that work with a network-effect moat that software alone cannot confer.³

A third route to the same conclusion

Robert F. Smith reaches the same destination through the historical ordering of a technology cycle rather than through either switching-cost argument: hardware vendors take the capital first, infrastructure operators second, and application providers usually get the largest share of the economic rent long term, once the technology has diffused into those markets. The earlier waves do not merely capture less over time, they become utilities, ultimately providing a service that application providers use to serve businesses. This route adds a specific timing claim tied to diffusion rather than only a pricing-power mechanism, a cost mechanism as well as a pricing one, since infrastructure functions as a cost of goods sold for the application layer and falls as more capital flows into it, and it comes from an operator's vantage point across roughly ninety portfolio companies rather than a single founder's.⁴ The important qualification attached to this version is that value accruing to the layer is not value accruing to any company within it: a meaningful share of existing application software is still expected to be displaced, with the durable rent reserved for firms that hold genuine ownership over specific workflows and data sets rather than simply occupying the product layer by default.⁴