In the series of articles I’ve been writing for Fast Company devoted to what I believe corporate AI should be, I’ve been touching on a very provocative idea: Perhaps the biggest problem of corporate AI as we know it so far is not intelligence, but the level at which we are programming it.
As we speak, frontier models, elastic cloud infrastructure, vector databases, managed APIs, and large amounts of computation are available to basically any serious company. As a substrate, this is extraordinarily powerful. However, in order to put AI systems into production, we still require engineers who hand-assemble fundamental things such as persistence, memory, permissions, tracing, retries, orchestration, durable execution, tool access, context management, and evaluation. As we said before, this is like the internet in 1991, before the web was invented.
Today, high-level languages—programming languages that use strong abstraction from the computer’s hardware details so that it’s easier for humans to read and write—are normal. However, decades ago, developers had to fight the machine directly, in machine or assembly language, something that John Backus described as “a hand-to-hand combat with the machine.” In IBM’s history of Fortran, the company explains there were tasks requiring up to a thousand machine instructions that could be easily expressed in just 47 Fortran statements, while at the same time detaching programs from specific hardware. It is not that Fortran made computation possible, but it definitely made it economically expressible at a higher level.
We saw the same pattern with C, Java, or the web. Dennis Ritchie explains how C allowed Unix itself to be rewritten in a largely portable language, making it easier to move across machines. Later, Java made the JVM plus standard libraries into an explicit platform, starting the “write once, run anywhere” movement. Then the web transformed an already functional but complex internet by introducing a simple shared grammar (HTML, HTTP, and URLs) on top of the network substrate. In all these cases, the infrastructure existed beforehand, but the abstraction made it easily programmable and manageable.
Today’s agentic stack looks a lot like another pre-language period: We use Python plus frameworks and services to program intelligent applications, with each piece managing fundamental characteristics separately. None of these products is unnecessary—quite the opposite—but their proliferation is also evidence that an underlying abstraction may still be missing. What happens when an ecosystem grows around individually supplying properties the substrate does not naturally provide? Quite simply, the ecosystem can start to be read as a sort of itemized invoice for a missing layer.
Who’s validating the runtime problem? The market out there
Think about LangChain, for instance: It explicitly distinguishes the harness around an agent from the runtime underneath it. They say production agents have requirements such as durable execution, memory, multi-tenancy, human-in-the-loop, observability, sandboxes, integrations, and scheduling. And they themselves explain that “to build a good agent, you need a good harness; and to deploy that agent, you need a good runtime.” Does this give you a clue?
One more example, Temporal, gives us another clear signal: They raised $300 million in February at a $5 billion valuation, selling the idea that long-running, stateful AI applications need a durable execution layer, which is true. But in their reference architecture, LLM calls and external side effects need to be wrapped carefully so that workflow state remains replayable and recoverable. That’s sophisticated, for sure, but also proof that we are still manually assembling primitives that a future AI-native runtime might (reasonably) make intrinsic.
How about LangGraph, or even Anthropic? They tell the same story from different angles. As we can see, the current stack can build almost anything . . . but at a significant cost. And the cost, as it happened a long time ago with assembly, is extraordinary complexity. You could do incredible software with assembly, sure, but the engineering cost, fragility, and lack of a reusable abstraction forced us to essentially reinvent the wheel. Every. Single. Time. Nowadays, with Python + databases + queues + orchestration + tracing + memory stores, we can absolutely produce excellent AI systems . . . but every team has to solve the same problems over and over again.
As I said before, metaphors do not industrialize. In order to make software truly industrial, we need to follow capability with formalization. Examples? Codd’s relational model appeared before the database ecosystem. Web standards preceded the web economy. And ERP created the shared enterprise abstractions we still use. Formalization has to reach the runtime itself at some point. Things as important as memory, state, permissions, workflows, journaled execution, and learning need to become primitives, instead of libraries glued together afterward.
The really important distinction is between an agent framework and an AI-native runtime.
What properties should be guaranteed by construction? When writing conventional software, developers don’t have to implement things manually such as virtual memory, process scheduling, or file system semantics for every single application. When a substrate becomes mature, it becomes able to provide them with such properties automatically. But for some reason, when we are struggling to develop enterprise AI, we still end up treating things as important as persistent agent identity, governed access, structured histories, and learning signals as one-of-a-kind problems to be solved each time on a case-by-case basis. This makes no sense at all: All these things should be properties of the runtime, not external products that we have to manually assemble each time as if we were artisans.
This becomes pretty obvious when you check where startups are appearing: Look how things such as memory, durable execution, observability, sandboxing, guardrails, agent identity, and orchestration are all becoming categories of their own, with companies that pop up like mushrooms and raise interesting amounts of money. That’s essentially good for entrepreneurs and for the ecosystem, I guess, but historically, it is an early sign that precedes abstraction. Will all these layers be permanently independent, or are we watching an industry temporarily sell separately the pieces that a future runtime will eventually absorb and fuse all together?
Things will (eventually) change
Do you know what’s extraordinary about the current corporate AI era? That we have already built the equivalent of the mainframe, the network, and the computing cloud, but we are still programming most of the intelligent layer purely by hand, line after line, with blood, sweat, and tears. When developers look at today’s intricate Python wrappers, checkpoint databases, queues, tracing systems, memory stores, and orchestration graphs in the future, they will see them in the same way we see early assembly listings now: amazing, laborious, impressive for their time, and astonishing because all that complexity was at some point in time considered necessary.
Think about it with a historical perspective: If every major computing substrate eventually ended up acquiring a language and a runtime expressing its native abstractions, why should artificial intelligence be different?
You can think of it as a thought experiment, or a wild desire: What would such a runtime actually have to make native to become the platform of your dreams, the one that would make your corporate AI implementations much easier? For now, that is the interesting question. But eventually, it may become more than just a thought experiment.