Your Model Is Not Your Moat
In a recent article, I wrote about companies turning their own data, workflows, and production feedback into specialized intelligence they increasingly control. The deeper idea was compounding. What matters is not simply whether a model performs well today, but whether using it creates assets that make the system better tomorrow. More AI teams are beginning to build around that idea. Which brings me to a question I keep coming back to: if everyone can increasingly rent the same intelligence, what exactly becomes defensible?
Gradient Flow exists because readers pitch in. Consider becoming a paid supporter 🙏
The moat is what you learn by operating
Strong models are becoming easier for everyone to access. What competitors cannot buy is an understanding of how your organization actually works. Which information matters for a decision? Which exceptions do experienced employees notice? Which workflows deserve automation? What does a good result look like, and how do you know when the system has failed?
That makes operational context and evaluations unusually important. A connector that gives an agent access to 400 reports is useful, but it is not much of a moat. Knowing which five reports your best analysts use, when and why they use them, is much harder to copy. Over time, production traces, evaluations, permissions, workflows, customer knowledge, and expert decisions form a company-specific operating layer. I would spend less effort defending access to a particular model and more effort capturing what the organization learns from using models.
There is an economic version of the same argument. Owning a particular layer of the AI stack does not guarantee attractive margins. A generic memory component can become a commodity. A deeply integrated memory system that measurably improves an agent’s performance may not. Depth and outcomes matter more than drawing a box around a layer and declaring it defensible.
Build for a platform that will keep changing
By some estimates, the best open-weight models have gone from roughly sixteen months behind the frontier to about two. I would treat the exact number cautiously, but the direction matters. Open models are not automatically cheaper once you include infrastructure and the people required to operate them. What they increasingly provide is another option.
That matters because depending completely on one provider is a business risk, not just a technical choice. Prices change. Models disappear. Terms get revised. Providers can restrict capabilities or start competing with companies they previously supplied. Security teams have even described closed models refusing legitimate defensive work because attacking software and testing its defenses can look similar from the model’s perspective.
My response would not be to predict which model or agent framework wins. I would make the important parts of the system replaceable. Keep models, business logic, state, policy, and execution reasonably separable. Use open interfaces where they help. Teams working on unrelated problems keep arriving at translation layers between incompatible systems. I take that as a useful signal. The platform is still unsettled, so interoperability has strategic value.
Build products that leave something behind
One idea I keep returning to is that not every product needs to survive indefinitely. Some AI applications will lose their differentiation when the next model absorbs the feature that made them special. That does not mean they were bad things to build.
Suppose a product lasts eighteen months but gives you thousands of real customer interactions, a stronger evaluation suite, workflow data, distribution, and a deeper understanding of the problem. Those assets can feed whatever comes next. The better question may be less “Can somebody copy this feature?” and more “What will we know after operating this product that somebody starting tomorrow will not?”
The same logic applies to the interface. Some teams are bringing full functionality into major AI assistants rather than insisting that customers stay inside their own applications. The reasoning is that value lives in the intelligence and context provided, not necessarily in the window customers look through. If users increasingly prefer assistants, defending the container may become a poor use of energy.
For startups, I also like the analogy to mobile. Incumbents eventually moved almost every important web product onto smartphones. The defining new companies came from things smartphones made newly possible, including cameras, GPS, and constant connectivity. AI may follow a similar pattern. Automating an existing workflow can be valuable, but incumbents can do that too. I am more interested in what becomes possible only because inexpensive intelligence and software generation now exist.
Legacy modernization is one example that deserves more attention. Companies have deferred these projects because documentation is incomplete, experts have retired, and nobody wants to own the migration risk. The interesting approach is not simply asking a model to rewrite COBOL in Python. Treat the old system as the specification, generate tests from it, translate the code, and use deterministic methods to verify that the new system behaves the same way. That turns a risky, open-ended migration into a checklist you can verify step by step.
When generation gets cheap, judgment gets scarce
There is a human version of this shift too. As code, analysis, text, and other outputs get cheaper to generate, producing the first answer matters less. Figuring out whether it is the right answer matters more.
That pushes value toward judgment, debugging, evaluation, and problem selection. Can someone turn a fuzzy objective into something a system can execute and test? Can they spot a failure that looks superficially correct? Can they explain why an agent went wrong and improve the system around it? A conventional coding test may tell you less about those abilities than real projects someone has shipped and a candid postmortem on one that failed.
I also would not assume that rapid productivity gains mean organizations transform overnight. Tools change much faster than job descriptions, incentives, and management structures. The first phase may look mostly like familiar teams producing more, with people spending more time directing and checking automated work.
When customers own the compounding loop
This is where the argument comes back to OpenAI and Anthropic. The challenge is not simply that an open model might catch them on a benchmark. Their best customers can increasingly combine proprietary data, workflows, tools, evaluations, and production feedback into intelligence that improves inside their own organizations.
That changes the competitive landscape. Frontier labs still compete with one another on general model capability, but increasingly they also compete with the accumulated intelligence their customers are building downstream. The more of that learning companies can capture for themselves, the more important it becomes to ask who actually owns the compounding loop.
Models, features, interfaces, and routine output are becoming easier to obtain. Operational context, evaluations, customer knowledge, distribution, and judgment get stronger through use. Buy what commoditizes. Build what compounds.
AI Is Rewiring Work Before It Rewrites Employment
When the AI Compute Bill Arrives
