The real reason enterprise AI is stuck

The reason enterprise AI remains stubbornly artisanal is not because models are too weak. It is not because context windows are too short, or agents need better prompts, or companies are resisting adoption. Those are all visible problems. But they are not the deepest one. The deeper problem is that the industry is still building from metaphors. And metaphors do not industrialize. Over the last two years, enterprise AI has become filled with human analogies. We talk about memory, reflection, planning, delegation, feedback, even sleep. Business Insider recently described Anthropic’s “dreaming” technique for AI agents , a telling example of how naturally the industry reaches for human metaphors when describing systems that are, in reality, computational architectures. The metaphors are useful. They make complex systems easier to understand. They help product teams explain what their systems do. They help executives believe they are buying something familiar. But there is a difference between a metaphor and a model: a metaphor describes something. A model formalizes it. That distinction may explain why enterprise AI still feels trapped between astonishing demos and frustrating deployments. Software becomes industrial when it becomes formal Every major software revolution followed the same pattern: first came capability. Then came formalization. Only then came the platform. Relational databases did not emerge because someone built a better filing cabinet: they emerged because Edgar F. Codd introduced a formal relational model of data , defining a way to think about relations, operations, redundancy, consistency, and data independence. SQL, applications, vendors, and ecosystems came later. First came the abstraction. The web did not become transformative because browsers got prettier: it became transformative because resources acquired formal identities. The W3C’s Architecture of the World Wide Web defines the web as an information space in which resources are identified by URIs. HTTP, formalized in RFC 9110 , is a stateless protocol whose requests can be interpreted independently. HTML, URLs, HTTP methods, status codes: these were not decorative details. They were the grammar that made the web industrial. ERP followed the same path. SAP did not become dominant because it wrote prettier interfaces than consultants. It succeeded because it formalized the enterprise around processes, transactions, master data, accounting logic, inventory, procurement, and operational relationships. That shared grammar made implementation repeatable enough for partners, integrators, templates, extensions, and eventually entire ecosystems to form around it. This is how software scales: not through better metaphors. Through formal abstractions. Enterprise AI has capability. What it still lacks is formalization. Memory is not a data model Consider one of the most common concepts in AI today: memory. Most modern AI platforms now offer some version of it. Microsoft’s documentation for the Azure OpenAI Assistants API describes persistent threads that store message history and truncate it when the conversation exceeds the model’s context length. Anthropic’s engineering team, writing about long-running agents , describes the challenge of agents working across many context windows and the need to preserve continuity between sessions. All of this is useful. None of it, by itself, is a data model. A memory tells you what happened, but a model tells you what can happen. A proper model defines identity, state, relationships, permissions, constraints, and valid transitions. It creates invariants: properties the system guarantees regardless of who uses it or how often it runs. Memory alone does not provide that. It can retrieve context. It can reconstruct history. It can summarize decisions. But it does not formally represent a customer, a contract, an approval chain, a compliance rule, a risk threshold, or a workflow state. That distinction matters because companies do not operate on memories: they operate on structures. Why agents remain artisanal This helps explain one of the strangest developments in enterprise AI: as frontier models become more capable, deployment is becoming more human-intensive. OpenAI, Anthropic, Google, and others increasingly rely on people who work directly with customers to map workflows, define constraints, connect systems, and translate organizational reality into something AI can operate within. In a previous article , I argued that if intelligence were truly a utility, vendors would not need to send engineers to every customer to make the faucet work. The persistence of that model tells us something important: the missing layer is still being supplied manually. Someone still has to determine what matters, which constraints apply, which systems are authoritative, how permissions work, how decisions are tracked, and how outcomes are measured. In a mature platform, much of that would already be represented formally. T