Enterprise AI isn’t stuck on models—it’s stuck on metaphors

Enterprise AI keeps producing impressive demos but disappointing rollouts because the industry is still describing core system behavior with human metaphors instead of formal models—data models, identity, state, permissions, constraints, and invariants that so

For many teams, the frustration has a familiar rhythm: an enterprise AI demo feels alive, persuasive, even oddly capable—then the rollout stalls. The systems don’t behave the way the pitch promised, and the work of making them safe, repeatable, and accountable keeps landing back on people.

The reason enterprise AI remains stubbornly artisanal isn’t because models are too weak. It isn’t because context windows are too short. It isn’t because agents need better prompts, or because companies resist adoption. Those problems are visible. But they are not the deepest one.

The real bottleneck is that the industry is still building from metaphors—and metaphors don’t industrialize.

Over the last two years, enterprise AI has been packed with human analogies. Memory, reflection, planning, delegation, feedback, and even sleep have become common ways to describe what AI systems do. In one recent example, Business Insider described Anthropic’s “dreaming” technique for AI agents. The description is a window into how naturally the industry reaches for human metaphors when it tries to explain systems that. in reality. are computational architectures.

These metaphors can be useful. They help product teams explain what their systems do. They help executives believe they are buying something familiar. But there’s a difference between a metaphor and a model: a metaphor describes something. A model formalizes it. That distinction—between storytelling and structure—may explain why enterprise AI still feels trapped between astonishing demos and frustrating deployments.

Software becomes industrial when it becomes formal

There is a pattern in past software revolutions: capability comes first, formalization comes next, and then platforms arrive.

Relational databases didn’t take off because someone built a better filing cabinet. They emerged after 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 followed 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, and status codes weren’t decoration. They were the grammar that made the web industrial.

ERP followed the same path. SAP didn’t become dominant because it wrote prettier interfaces than consultants. It succeeded by formalizing 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.

Enterprise AI has capability. What it still lacks is formalization.

Memory is not a data model

The clearest example is the most common concept 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 that is useful. None of it, by itself, is a data model. A memory tells you what happened. 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, reconstruct history, or summarize decisions. But it doesn’t 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 is where the metaphor-to-deployment gap becomes impossible to ignore. As frontier models get 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. The piece frames it as a kind of utility test: 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 setup suggests something missing is still being supplied manually. Someone still has to decide 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. Today, it often is not. The result is a category that remains dependent on custom deployment and organizational translation—artisanal intelligence, not industrial intelligence.

Ecosystems require invariants

That also helps explain why today’s agent platforms struggle to produce true ecosystems.

Developers can build on SQL because tables, transactions, keys, and constraints behave predictably. They can build on the web because URLs, HTTP methods, and document formats obey shared rules. They can build on ERP systems because business objects and transactions have defined meanings.

Those guarantees matter: they allow partners, extensions, integrations, marketplaces, and standards to emerge. Without invariants, every deployment becomes a custom interpretation. When custom interpretation becomes the dominant mode of delivery, the result is not a platform—it is consulting.

This is exactly the trap enterprise AI is currently in. Every organization has its own data, workflows, vocabulary, policies, approvals, systems of record, exception paths, and political reality. Without a formal layer that can represent those things in a reusable way, each deployment becomes a translation exercise. The model may be general, but the company is not.

McKinsey’s latest State of AI research points to the same pattern from another angle: AI usage is widespread. but most companies have not embedded it deeply enough into workflows and processes to produce material enterprise-level benefits. The companies doing better are not simply using more AI. They are redesigning workflows.

That confirmation follows the same through-line: intelligence alone is not enough. It has to be embedded in structure.

The formal layer enterprise AI is missing

This mistake isn’t new. In his classic Harvard Business Review essay. “Reengineering Work: Don’t Automate. Obliterate. ” Michael Hammer warned that companies often use new technology to speed up outdated processes instead of redesigning the work itself. That warning was true in 1990. It is even more true now.

Most companies are still asking, “how do we add AI to our existing processes?” The better question is, “what formal representation of work would allow AI to operate safely, repeatably, and accountably inside the company?”

That layer will not be another chat interface. It will not be a longer prompt. It will not be a prettier copilot or a more anthropomorphic agent. It will be a formal layer: one that represents identity. state. permissions. constraints. provenance. workflows. outcomes. and business semantics in ways understandable both to machines and to humans.

It would create invariants that make enterprise intelligence composable, governable, auditable, and repeatable.

That is when ecosystems emerge. That is when deployments become scalable. And that is when enterprise AI finally leaves its artisanal phase behind.

What comes next

The next stage of enterprise AI will not be defined by who gives the best name to memory, agents, context, or delegation. It will be defined by who formalizes them.

The winning architecture isn’t obvious. Still, its properties are becoming easier to describe: it will preserve state. It will enforce constraints. It will encode business semantics. It will govern permissions. It will track provenance. It will connect actions to outcomes. It will make workflows intelligible to machines without making them opaque to humans.

Most importantly, it will create invariants others can build on.

The industrial era of enterprise AI won’t begin when models become more humanlike. It will begin when intelligence becomes more structured.

Because every major software revolution follows the same pattern: first we imitate reality with metaphors, then we discover the abstraction that makes an industry possible.

A metaphor can inspire a product. A formal model creates an industry.

enterprise AI metaphors vs models formalization agents memory Azure OpenAI Assistants API Anthropic dreaming invariants SQL ERP ERP ecosystems McKinsey State of AI software platforms