For the past two years, companies have been asking the same question in slightly different forms: which AI application should we build next?
A customer service agent? A sales copilot? A procurement assistant? A coding agent? A research assistant? A workflow automation layer? A chatbot connected to internal data? A model wrapped in a user interface and connected to tools?
All of that makes sense. It is how every new computing era begins. First, people try to build applications directly on top of the new substrate. They use whatever tools already exist, wrap the new capability in familiar interfaces, and assemble the missing pieces by hand.
But there is a moment in every major computing cycle when that approach reaches its limit. The problem is no longer whether something can be built. It can. Given enough talented engineers, almost anything can be assembled.
The real question becomes whether it can be built repeatedly, safely, cheaply, and at scale. That is when the language appears. And enterprise AI may now be reaching exactly that point.
The substrate is already here
The history of computing contains a recurring pattern: the infrastructure arrives first, and the language that makes it productive arrives later.
The mainframe existed before Fortran gave scientific computing a usable high-level language. Systems programming existed before C made it possible to write portable, powerful software close to the machine. Corporate servers existed before Java became the default grammar of enterprise applications.
The most revealing example is the web. The internet worked before the World Wide Web. TCP/IP moved packets. DNS resolved names. Email connected institutions. FTP moved files. Servers existed. Universities, laboratories, and technically sophisticated organizations could use the network.
But for ordinary organizations, the internet was not yet a business environment. It was infrastructure.
Then came a thin, almost deceptively simple layer: URLs, HTTP, HTML, browsers, and servers. CERN’s history of the web explains that Tim Berners-Lee invented the World Wide Web at CERN in 1989 and that its basic idea was to merge computers, data networks, and hypertext into a global information system. The W3C’s architecture of the web later described the web as an information space in which resources are identified by URIs. RFC 9110, in turn, defines HTTP as a stateless application-level protocol for distributed hypertext information systems.
None of that invented networking. It made networking legible. The web did not create the internet. It collapsed the cost of using it.
That is where enterprise AI is today.
We are programming the Intelligent Cloud by hand
The substrate for enterprise AI is already remarkably complete. Frontier models are available as managed services. GPU compute is elastic. Vector databases are mature. Storage is abundant. Retrieval, orchestration, evaluation, security, and reinforcement learning infrastructure all exist in some form.
And yet, most enterprise AI still feels artisanal. Why? Because the new substrate is being programmed by hand.
A modern AI application is often a pile of glue code: Python scripts, framework wrappers, custom state management, hand-built memory, separate observability, separate permissions, separate orchestration, separate durability, separate sandboxes, separate guardrails.
Every team rebuilds the same missing properties. Persistent state. Durable execution. Memory. Observability. Security. Auditability. Learning. Governance. Feedback. Context management.
The evidence is visible in the market itself. Durable execution has become a category, with companies such as Temporal offering infrastructure for workflows that can run for days, weeks, or even years despite failures. Agent memory and persistent state are becoming categories too: Letta’s documentation describes stateful agents as persistent AI identities with their own memory, tools, model configuration, and message history, while Zep positions itself explicitly around agent memory. Observability has its own ecosystem, with projects such as OpenTelemetry standardizing how software emits traces, metrics, and logs.
These are useful technologies. But their proliferation also tells us something important: the properties that intelligent applications need are not yet native to the layer where they are being built. Every missing primitive becomes a product category.
That is not necessarily an ecosystem. Sometimes, it is an invoice for a missing language.
The problem is not possibility. It is cost
The usual response to this argument is predictable: Everything can already be built with today’s tools. That is true. It is also beside the point.
Before high-level languages, everything could be built in assembly. Before the web, networked applications could be built with custom protocols. Before ERP, companies could build bespoke systems with consultants. Before cloud platforms, infrastructure could be provisioned manually.
The question was never whether something was possible. The question was how expensive, fragile, slow, and non-repeatable it was.
Languages matter because they change the cost structure. They take properties that previously required custom engineering and make them native. They turn repeated effort into grammar.
A language does not necessarily make new things possible in the theoretical sense. Turing completeness already does that. What it does is make the expensive cheap, the bespoke repeatable, and the fragile durable. At certain cost levels, that is indistinguishable from creation.
This is why the language question is not an academic concern. It is an economic one. The winning layer in computing is often not the deepest infrastructure, but the abstraction that makes the infrastructure productive.
The internet was not enough. The web was the multiplier.
Models are not the language
For the last two years, the AI industry has treated models as the center of gravity: Which model reasons better? Which model writes better code? Which one has the largest context window? Which one wins the latest benchmark? Which one is cheapest? Which one is fastest?
These questions matter. But they are becoming less decisive. As models improve and become more widely available, intelligence starts to look less like the scarce resource and more like infrastructure. That does not make models unimportant. Electricity did not become unimportant when it became infrastructure. Computing did not become unimportant when it became infrastructure. Networking did not become unimportant when it became infrastructure.
But the business value moved upward. Companies do not buy ERP because they admire databases. They do not buy Salesforce because they admire SQL. They do not build on the web because they enjoy thinking about HTTP semantics.
They build on the layer that turns the substrate into something organizationally usable. AI is moving in the same direction. The model generates. But the enterprise needs to persist, coordinate, constrain, audit, measure, and learn.
Those are not model capabilities in the narrow sense. They are system properties.
Metaphors do not industrialize
One reason enterprise AI remains stuck is that the industry keeps reaching for human metaphors.
Agents have memory. They plan. They reflect. They use tools. They delegate. They dream. They need supervision. They have roles. They behave like employees.
The metaphors are helpful. They make unfamiliar systems easier to discuss. They give executives a way to imagine what is happening. They give product teams a vocabulary.
But metaphors do not industrialize. A memory is not a data model. A prompt is not a constraint. A conversation history is not a persistent operational state. A tool call is not a workflow. A log is not a journal. A human in the loop is not governance. A chatbot connected to enterprise data is not an enterprise architecture.
Software becomes industrial when it becomes formal. Relational databases became industrial when tables, keys, transactions, and constraints gave developers shared invariants. The web became industrial when resources, URIs, HTTP methods, and document formats created a common grammar. ERP became industrial when business objects, processes, transactions, and master data gave companies a repeatable representation of operations.
Enterprise AI still lacks that equivalent. It has extraordinary capabilities. It has impressive demos. It has frameworks, APIs, copilots, agents, and orchestration tools. But it does not yet have the formal language in which intelligent enterprise operations are naturally expressed.
The next breakthrough may look boring
This is why the next major enterprise AI breakthrough may not look dramatic at first. It may not be a model that writes better poetry, produces better video, solves harder math problems, or beats another benchmark. It may look like something much less glamorous: a language decision.
A language in which agents are persistent by default. A language in which execution is durable by default. A language in which every meaningful state change becomes part of the system’s biography. A language in which permissions, constraints, and auditability are not external layers, but structural properties. A language in which business outcomes are not dashboard metrics inspected after the fact, but reward signals that systems can learn from.
Most importantly, a language in which the learning loop is native.
That is the real prize. Enterprise AI becomes transformative not when it answers more questions, but when it can observe, act, measure, learn, and improve against business outcomes. Today, that loop is usually engineered application by application. It is assembled with tools, workflows, evaluation scripts, data pipelines, and human review.
The moment that loop becomes part of the language, the economics of the category change. That is what languages do: they compress complexity. They make ecosystems possible. They allow ordinary developers and ordinary organizations to build things that previously required specialists. They turn custom engineering into repeatable architecture.
Where is enterprise AI’s web?
The Intelligent Cloud is already here. The models are real. The infrastructure is real. The capabilities are real. The demonstrations are impressive. But the layer that makes all of this programmable at the right level of abstraction is still missing.
That is why enterprise AI today often feels simultaneously revolutionary and incomplete. The raw power is there, but too much of the work still consists of reconstructing the missing grammar: state, context, identity, permissions, durability, observability, feedback, learning, and governance.
The question, then, is not whether companies need another AI app: they need the language that makes such apps cheap enough, safe enough, repeatable enough, and adaptive enough to matter.
When that language appears, much of today’s enterprise AI landscape will look like the internet before the web: powerful, real, technically impressive, and waiting for the abstraction that finally makes it usable.