Skip to content
Ryan de Melo
Go back

The Enterprise AI OS: My Thesis for the Next Five Years

Three model swaps in, and a serious enterprise deployment is still running on the same layer underneath every one of them. That is why I can call the model a commodity out loud now, two years into building a venture on the opposite of that fear.

Frontier labs will keep trading the lead every few months, the price of a token keeps falling, and a capability that was a moat in spring is table stakes by autumn. If your company’s entire AI strategy is “we picked the best model,” you have built your house on something that is, by design, trying to make itself cheap. The interesting question stopped being which model and became a harder one: what is the layer that does not get commoditized away, the one a company leans on after the model underneath has been swapped out yet again.

My answer, and the bet I left a director seat to make, is that the durable layer is an operating system. I do not mean that as a loose metaphor. I mean it the way an OS is actually defined: a layer that sits between programs and hardware and gives every program an identity, a permission boundary, a way to call out to devices, a memory it can trust, and a log of what happened. Swap the model for the CPU and the enterprise’s systems for the hardware, and you are describing exactly what an agent needs and almost no one is selling.

Why the incumbents miss it

Go look at what the big players are actually shipping. One camp sells models: bigger context, better reasoning, a price cut on Tuesday. The other camp sells apps: a copilot bolted onto the product you already pay them for, a chat box in the corner of the CRM. Both are real businesses, and neither of them is the operating system.

They miss it for the same reason most companies miss the layer they are not structured to sell. A model lab is organized to make a model. Its whole apparatus, the researchers, the eval suites, the compute budget, points at one number going up. The connective tissue between that model and a company’s twenty years of accumulated systems is, to a model lab, somebody else’s integration problem. The app vendor sells you a feature inside their own walls, with no incentive to build the connector that lets an agent reach across into a competitor’s system too. So the OS belongs to nobody’s roadmap, because it is nobody’s product. (This is usually where the durable businesses hide, in the boring middle everyone assumes someone else will handle.)

The hard problem in enterprise AI in 2026 is not reasoning, since the models reason fine. What breaks is everything around it: a reasoning engine, on its own, has no identity you can hold accountable, no permissions you can scope, no memory you can audit, and no record of what it touched. You have let a brilliant contractor into the building with no badge, no access list, and no security camera. Nobody sane runs a company that way, which is exactly why the impressive demos keep dying on the threshold of production.

The layers

What does this OS actually contain? Five layers, and they are not equally hard.

The enterprise AI OS sits between the models and the company's existing systems, with five layers: identity and permissions, tools and MCP, memory, orchestration, and an audit trail spanning all of them

You inherit the systems, you swap the model, and the OS in the middle is what you actually own.

Identity and permissions comes first because nothing above it is safe without it. An agent is neither a user nor a service account, and pretending it is either gets you breached. It needs its own identity, scoped to act on behalf of a specific person, within that person’s rights and not one permission wider. When the finance agent asks the ledger a question, the ledger needs to know whose authority it is borrowing.

Tools is the layer that has matured most, and we have the Model Context Protocol to thank for it. MCP is about a year and a half old now, and it did the unglamorous work that actually mattered: it standardized how an agent discovers and calls a tool, so you stop writing a bespoke adapter for every system and every model pairing. It is the USB-C of this stack, and I have written before about why I bet on it early. The protocol is not the moat; it is what makes the moat buildable.

Memory is where most teams are still naive. A context window is not memory; memory is what an agent knows about your business across sessions, the durable, queryable, permission-aware store of state that lets the second conversation be smarter than the first. Get this wrong and every agent interaction starts from zero, which users experience as an assistant with amnesia and a confident voice.

Orchestration is the routing layer: which agent, which tool, which model, in what order, with what fallback when a step fails. Necessary and increasingly well understood, though not, in my opinion, what decides who wins.

The hard, valuable part

What decides who wins is the one I drew cutting across all the others, because it is not a layer you can add at the end: the transaction fabric, agents that can act, not just answer, and do it safely and auditably over real systems that move real money and real records.

Reading is easy: an agent that summarizes your invoices is a parlor trick, and the bar for it is low, because the worst case is a wrong sentence a human catches. An agent that posts a journal entry, releases a payment, or amends a customer record lives in a different universe of risk, and that universe is where the value actually is. Nobody pays enterprise money for a chatbot that talks about the work; they pay for the work to get done.

I learned the weight of this building a reconciliation platform over institutional finance, before I ever called any of it an operating system. The agentic part, the narration of a cash-flow anomaly, was a few weeks of work. The fabric underneath, the machinery that let an agent touch a ledger while staying fully explainable, scoped, reversible, and logged down to the action, took most of the year. Every irreversible action gates behind a human who is shown the consequence, not the prompt, and every action an agent takes writes to a record a regulator could read cold. That audit trail is not a feature you sprinkle on top; it is the floor everything else stands on, which is why I drew it spanning the full width rather than sitting in a box.

That inversion sits at the center of my thesis. The scarce, defensible capability is not autonomy; letting an agent do more on its own is the easy direction, and mostly the wrong one. What is scarce is letting an agent act while remaining something a company can trust, govern, and answer for. Trust is the product. The model is just the engine you bolted into the chassis, and you will replace it long before you replace the chassis.

Five years out, I expect the model question to look the way “which database” looks today: a genuine decision, made once a quarter, by people who are not in the room for the conversation that outranks it. That conversation is about the layer in the middle, the one no incumbent is built to sell.

I am building it, and if this thesis is wrong, I am wrong about the most expensive question in the industry. I would rather learn that with my own years on the line than from a director’s seat. My money is on the chassis outlasting the engine, swap after swap, and on the layer in the middle being what an enterprise still pays for once the model has become an afterthought.


Share this post:

Previous Post
Resolving Stuck Receivables With RAG and Agents
Next Post
Multi-Agent Systems: When One Agent Isn't Enough