Enterprise AI Is Stuck Because It Runs on Metaphors, Not Models

The gap between impressive demos and frustrating deployments isn't a capability problem. It's a formalization problem — and every prior software revolution solved it the same way.

Written by Rachel Sloane · Bureau Business · Jun 18, 2026

The demo works. The deployment doesn't.

Every enterprise AI sales cycle follows a recognizable arc. The demo is compelling. The pilot is promising. Then the deployment stalls — not because the model failed, but because someone has to manually map the workflows, define the constraints, connect the systems, and translate the organization's actual operating logic into something the AI can work within.

That translation work is still being done by humans. Often by the vendor's own engineers. That is not what a mature platform looks like.

The argument made in a recent Fast Company analysis cuts to the structural issue: enterprise AI is artisanal because it is built on metaphors rather than formal abstractions. And metaphors, however useful, do not industrialize.

How software actually scales

Every major software revolution followed the same sequence: capability, then formalization, then platform.

Relational databases did not emerge because someone built a better filing cabinet. Edgar Codd introduced a formal relational model — defining relations, operations, redundancy, and data independence. SQL, applications, and ecosystems followed the abstraction.

The web became transformative not because browsers improved, but because resources acquired formal identities. URLs, HTTP methods, status codes, and document formats created a shared grammar. Developers could build on it because it behaved predictably.

SAP didn't dominate ERP by writing prettier interfaces. It formalized the enterprise around processes, transactions, master data, and accounting logic. That shared grammar made implementation repeatable enough for partners, integrators, and entire ecosystems to form.

Enterprise AI has the capability. It does not yet have the formalization.

'Memory' is not a data model

The gap shows up most clearly in how the industry talks about memory. Current platforms offer persistent threads, session continuity, and context summarization. That is useful. It is not a data model.

A data 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 retrieves context. It does not formally represent a customer, a contract, an approval chain, a compliance rule, or a workflow state. Companies do not operate on memories. They operate on structures.

Why every deployment is still custom

This is why agent platforms have not produced true ecosystems. Developers can build on SQL because tables, transactions, and constraints behave predictably. They can build on HTTP because the protocol is stateless and its rules are shared. Without equivalent invariants in AI infrastructure, every deployment becomes a custom interpretation of organizational reality.

Custom interpretation at scale is not a platform. It is consulting.

McKinsey's latest State of AI research points to the same pattern from a different angle: AI usage is widespread, but most companies haven't embedded it deeply enough into workflows to produce material enterprise-level benefits. The companies doing better are redesigning workflows — not just adding AI to existing ones. Intelligence alone is not enough. It has to be embedded in structure.

What the formal layer actually needs to do

The next stage of enterprise AI will be defined by whoever formalizes the abstractions the industry is currently supplying by hand. That layer will need to represent identity, state, permissions, constraints, provenance, workflows, and business semantics in ways that are legible to both machines and humans.

It will create invariants others can build on. It will make deployments composable, auditable, and repeatable.

That is not a longer prompt. It is not a more anthropomorphic agent. It is the same move Codd made with data, and Berners-Lee made with documents, and SAP made with enterprise processes.

The industrial era of enterprise AI begins when intelligence becomes structured — not when it becomes more humanlike.

Key takeaways

The persistence of high-touch, engineer-intensive AI deployments signals a missing formal layer, not a missing capability.
Relational databases, the web, and ERP all scaled the same way: capability first, then formalization, then ecosystem. Enterprise AI has the first but lacks the second.
'Memory' in current AI platforms is context retrieval, not a data model — it doesn't define identity, state, permissions, or valid transitions the way enterprise operations require.
Without invariants — guaranteed behaviors that third parties can build on — agent platforms produce consulting practices, not ecosystems.
McKinsey's State of AI research finds that companies generating material enterprise benefits are redesigning workflows, not just adding AI on top of existing ones.

FAQ

Why do enterprise AI deployments still require so much custom work?

Because there is no formal layer that represents organizational reality — identity, state, permissions, constraints, workflows — in a reusable way. Each deployment requires someone to manually translate how the company actually operates into something the AI can work within. That translation is currently done by humans, often the vendor's own engineers.

What's the difference between AI 'memory' and a proper data model?

Memory retrieves context and reconstructs history. A data model defines identity, state, relationships, permissions, constraints, and valid transitions — and creates invariants the system guarantees regardless of usage. Enterprise operations run on structures, not recollections.

What would a formal layer for enterprise AI actually look like?

It would formally represent business objects — customers, contracts, approvals, compliance rules, workflow states — along with permissions, provenance, and outcome tracking. It would create predictable, guaranteed behaviors that third-party developers and integrators could build on, the same way SQL or HTTP do.

Is this a problem with current AI models being too weak?

No. The argument is explicitly that model capability is not the bottleneck. The gap is in formalization — the abstraction layer that makes capability repeatable, governable, and composable at enterprise scale.

What do companies that are getting results from AI actually do differently?

According to McKinsey's State of AI research, companies generating material enterprise benefits are redesigning workflows rather than layering AI onto existing processes. The distinction matters: embedding intelligence in structure produces different outcomes than adding it on top.

Citations

The Real Reason Enterprise AI Is StuckEnterprise AI remains artisanal because the industry builds from metaphors rather than formal abstractions; every prior software revolution formalized its model before producing an ecosystem.
McKinsey State of AIAI usage is widespread but most companies have not embedded it deeply enough into workflows and processes to produce material enterprise-level benefits; companies doing better are redesigning workflows.
Reengineering Work: Don't Automate, Obliterate — Harvard Business ReviewMichael Hammer warned in 1990 that companies use new technology to speed up outdated processes instead of redesigning the work itself — a pattern that applies directly to current AI adoption.
RFC 9110: HTTP SemanticsHTTP is a stateless protocol whose requests can be interpreted independently — a formal invariant that enabled the web to become an industrial platform.