Every company is briefly a model company

Three times in three years, a wave of companies concluded that the way to build an AI product was to own a layer that turned out not to be theirs.

The pattern is consistent enough to be predictive, which makes it worth naming.

wave one: fine-tuning#

The thesis (2023): general models are generic. Fine-tune on your domain data and you get a model that is specifically good at your problem and that competitors cannot replicate.

What happened: base models improved faster than fine-tunes could keep up. A fine-tuned model from six months ago was worse than the new base model with a good prompt. Every fine-tune had to be redone on every model release, which is a treadmill.

Where it settled: fine-tuning is genuinely valuable for narrow, stable, high-volume tasks — classification into your specific taxonomy, output in your specific format, a small model matching a large model's behavior on one task. It is not a moat and it is not a product strategy.

wave two: RAG#

The thesis (2023-24): the model does not know your data. Build a retrieval pipeline — chunk, embed, index, retrieve, rerank — and you have a defensible system built on proprietary knowledge.

What happened: context windows grew by two orders of magnitude, long-context quality improved, and prompt caching made large contexts economical. A large fraction of naive RAG got replaced by putting the documents in the prompt.

Simultaneously, the pipeline components commoditized. Embedding models became interchangeable. Vector search became a feature of every database rather than a product.

Where it settled: retrieval did not go away. It moved. Retrieval is now a tool the model calls rather than a preprocessing step, and it is genuinely necessary at large corpus sizes, where citation is required, and where cost or latency rules out large contexts.

The infrastructure repositioned rather than dying, which is what usually happens.

wave three: agent frameworks#

The thesis (2024-25): models cannot plan reliably. Build the orchestration — task decomposition, tool routing, retry logic, state management — and own the layer that makes agents work.

What happened: the models absorbed it. In-context tool use during reasoning removed the need for an external loop. Native parallel tool calling removed the need for a dispatcher. Memory tools and context editing removed the need for external state management.

Each capability the framework provided became a model feature within about a year.

Where it settled: in progress, but the shape is clear. Orchestration frameworks are converging on thin conveniences. The durable parts are evaluation, observability, and the domain-specific policy that no model will ever have.

the pattern#

Every wave follows the same arc:

1. The model has a limitation.
2. Companies build infrastructure to work around the limitation.
3. The limitation gets fixed in the model.
4. The infrastructure either finds a new position or disappears.

The consistent error is building on a gap rather than on an asset. A gap is temporary by construction — the labs are actively working to close it, with more resources than you have.

what has actually been durable#

Across all three waves, the same things kept their value:

Proprietary data. Not "we have documents" — everyone has documents. Data that is genuinely yours: production logs, customer interactions, labeled outcomes, domain expertise encoded as examples. Nobody can buy it and no model was trained on it.

Evaluation specific to your task. The company that knows, precisely, how well a system performs on their actual problem can adopt a new model in a day. The one that does not spends a month on vibes. That gap compounds every release cycle.

Distribution and workflow integration. Being where the user already works. The most boring answer and the most durable.

Domain constraints. The rules, regulations, edge cases, and institutional knowledge that make a generic capability into a usable product. This is unglamorous and it is the actual work.

Trust. Security posture, compliance, reliability, support. Enterprises buy this and it takes years to build.

the test to apply#

Before building on top of a model limitation, ask: if this limitation disappeared next quarter, what would I have left?

If the answer is "nothing," you are building a bridge over a river that is being drained.

If the answer is "the data, the evaluations, the integrations, and the customer relationships," build it, and expect to throw the bridge away.