Every platform era looks like a pile of one-off hacks until someone writes the grammar that makes it legible to everyone else.

The Summary

  • Enterprise AI is trapped in the one-off app phase — companies keep asking "which AI tool should we build next?" instead of "what language do we need to build all of them?"
  • The pattern repeats: mainframes got Fortran, systems programming got C, enterprise servers got Java, the internet got HTML/HTTP. Infrastructure first, then the language that makes it productive.
  • We're at the tipping point where the question shifts from "can we build this?" to "can we build this repeatedly, safely, cheaply, and at scale?"

The Signal

The article frames this as a maturity problem, but it's really a composability crisis. Right now, every AI agent deployment is a bespoke integration effort. Companies hire engineers to wire up models, wrap them in interfaces, connect them to internal tools, add guardrails, manage permissions, handle failures. It works. Barely. But it doesn't scale because there's no shared grammar for describing what an agent is, what it can do, or how it fits into the enterprise stack.

The comparison to the early web is sharper than it first appears. The internet existed before the web. You could move packets, resolve names, send email, transfer files. Universities used it. But for ordinary businesses, it was just infrastructure without an interface. Then HTTP, HTML, and URLs arrived. Not because they were technically superior to what came before, but because they created a shared language. A URL was a universal pointer. HTML was a universal document format. HTTP was a universal transport. Suddenly, you didn't need to be a network engineer to build something useful on the internet.

"The real question becomes whether it can be built repeatedly, safely, cheaply, and at scale."

Enterprise AI doesn't have that yet. What it has instead:

  • Proprietary orchestration layers from Anthropic, OpenAI, and a dozen startups
  • Custom tool-calling protocols that don't interoperate
  • Model-specific prompt engineering that breaks when you swap providers
  • One-off security and compliance frameworks built per deployment

This is the hand-assembly phase. It's expensive, brittle, and doesn't compound. Every new agent requires fresh engineering effort. There's no library of composable components. No standard way to describe an agent's capabilities, permissions, or failure modes. No universal protocol for agents to discover and call other agents.

The thesis here is that someone is going to write the language layer. Not a model. Not an application. A protocol, a schema, a set of primitives that let you describe agents the way HTML let you describe documents. When that arrives, the agent economy stops being a services business and becomes a platform business. You'll know it's happening when building a new agent starts to feel less like hiring a custom dev shop and more like deploying a web service.

The Implication

If you're building AI infrastructure right now, the strategic question isn't "what app should we ship next?" It's "are we building toward a composable language, or are we building another walled garden?" The winners in the next 18 months won't be the companies with the most agent apps. They'll be the ones who define the grammar that makes agent-building repeatable. Watch for companies that stop talking about their AI products and start talking about their protocols, schemas, and interoperability layers. That's the signal that the language is forming.

Sources

Fast Company Tech