Your Model Is Not Your MoatIn 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? The moat is what you learn by operatingStrong 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 changingBy 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 behindOne 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. |