Why 'Operating System' Is the Right Metaphor for Agentic Stacks

There is a recurring objection in our editorial inbox to the use of “operating system” as a description of the agentic infrastructure layer. The objection comes from two directions. From the systems side, it comes from people who built actual operating systems and who, reasonably, do not want the word weakened. From the AI side, it comes from people who think any analogy to traditional computing is misleading because the underlying primitives are different. Both objections are serious. We have considered both and we still believe the operating-system metaphor is the right one to keep.

This piece is an argument for the metaphor, not a defense of any particular product that uses it. We think the label is overclaimed in the market. We also think the underlying intuition — that there should be a layer of agentic software that does for agents what an OS does for processes — is correct, and that abandoning the metaphor would cost the field more than tolerating its misuse.

Why the analogy is not a stretch

A traditional operating system does four things for processes. It schedules them, mediates their access to shared resources, identifies and authorizes them, and persists state across power cycles. The previous piece in this series argued that an agentic OS would have to do the same four things for agents. The translations are direct enough that the metaphor is not a stretch.

What is being abstracted is, in both cases, the same thing: a substrate that lets multiple independent units of computation operate against shared resources without each one having to re-implement the substrate. Processes do not know about each other on a healthy operating system; they ask the kernel for memory, for files, for network sockets, and the kernel keeps them honest. Agents should not know about each other on a healthy agentic OS; they should ask the platform for context, for tools, for memory, for permissions, and the platform should keep them honest.

The thing the metaphor preserves, and the reason it is worth keeping, is the relationship between the layer and the things that run on it. A framework is something developers use. A library is something developers import. An operating system is something developers target. The word “target” carries weight. Targeting a platform implies that the platform’s behavior is stable enough to plan against, that the platform’s failures are diagnosable, and that the platform’s primitives are general enough to compose into things the platform’s designers did not anticipate.

We use the word “operating system” because we want the agentic layer to deserve that posture. The market has not yet shipped a product that fully deserves it. The metaphor is, in part, a forcing function.

The objection from the systems side

The strongest version of the systems-side objection runs like this: a real operating system manages physical resources. It schedules a CPU. It allocates memory. It writes to disk. An agentic platform manages logical resources — context windows, tool budgets, credit allowances — and there is no real hardware involved. Calling it an OS confuses people about what the layer is actually doing.

The objection is fair on its face and we think it is wrong on inspection. The reason the OS abstraction works is not that it manages physical resources. It is that it abstracts over scarce, shared, contended resources. A context window is exactly this. A model’s tool budget is exactly this. A user’s credit allowance is exactly this. Scarcity, sharing, and contention are the conditions that make the OS abstraction useful, and they are present in the agentic layer in the same way they are present in classical computing.

There is a secondary version of the objection: an OS provides isolation between processes, and agentic systems do not isolate agents in the same way. This is closer to a real concern. The traditional OS model of process isolation — virtual memory, address spaces, capability lists — does not have a clean analog in current agentic systems. Agents share context, share memory, share tools. The isolation problem is genuinely unsolved.

We grant the point but draw a different conclusion. The fact that the agentic OS does not yet have process isolation in any deep sense is not a reason to abandon the metaphor; it is a reason for the metaphor to push the field toward solving the problem. Isolation is the next interesting architectural question in agentic systems. Calling the layer an operating system is what makes the question hard to ignore.

The objection from the AI side

The AI-side objection runs differently. It says the analogy to operating systems is misleading because agents are non-deterministic in ways processes are not. A process either runs or it does not. An agent runs and may produce a different answer each time. The kinds of guarantees an OS provides — that a file system call returns the bytes you wrote, that a network call either succeeds or fails, that a system call has a well-defined contract — do not survive the move to agentic primitives.

This objection is also serious and also, we think, wrong. The OS does not provide guarantees because the underlying primitives are deterministic. It provides guarantees because it imposes a contract on top of primitives that may or may not be deterministic. A network call is not deterministic. A disk read can return a checksum failure. The OS handles those by retrying, by surfacing typed errors, by enforcing isolation between the caller and the failure mode. The job of the OS is to translate unreliable primitives into a substrate that callers can plan against.

This is exactly the job an agentic OS has to do. The primitives — model calls, tool calls, memory operations — are unreliable. The platform’s job is to translate them into something the operator can plan against. That is the OS contract. The fact that the primitives are LLMs rather than CPUs makes the contract harder to enforce, not less applicable.

What the metaphor demands

If we accept the metaphor, it demands specific things from products that use the label. We have written about the four-question test before; here we want to spell out what the metaphor commits a product to that is harder than the test suggests.

It commits a product to a stable contract. An OS that changes its system-call surface every release is not an OS, it is a moving target. Products that use the agentic-OS label are committing themselves to a stable enough surface that other developers can plan against it. Almost none of the current products have this property. Most are still iterating their primitives every quarter. The marketing has run ahead of the engineering.

It commits a product to a third-party developer story. An OS that no one else targets is a vertical application with a wide footprint. Products that use the label are, implicitly, committing to letting other developers build on top of them — to publishing SDKs, supporting third-party agents, hosting an ecosystem. Most products are not there yet. A handful, including Web4OS, are signaling that they intend to be.

It commits a product to running other vendors’ agents. This is the hardest one and the one most products will not survive. A real OS runs software the OS vendor did not write. A real agentic OS will eventually run agents from other vendors — agents the OS vendor did not train, did not align, and does not endorse. The trust and isolation work this requires is the work the field has not yet done.

It commits a product to lasting. Operating systems are infrastructure. Infrastructure is a durability bet. A platform that uses the OS label is, implicitly, telling its customers it will be around in ten years. Most products will not be. The label, used honestly, is a kind of promise.

Why we keep the metaphor anyway

The temptation, given the misuse, is to retire the word. We have considered it. We do not recommend it.

The reason is that the alternative labels are worse. “Agentic platform” is too generic; every vendor uses it. “Agentic runtime” is too narrow; it suggests the layer is just an executor. “Agentic infrastructure” is closer, but it loses the specific architectural shape — the four responsibilities — that “operating system” carries. The OS metaphor is the only label in circulation that names the right thing.

The misuse of the label is a cost. The clarity it provides, when used correctly, is worth the cost. The field will sort it out the same way it sorted out “cloud” — by a few years of confusion followed by the term settling into its load-bearing meaning. The work in the meantime is to use the word carefully, to write down what it implies, and to be patient with the products that are growing into the label.

We will keep doing that. The next piece in this series will look at the history of how the operating-system metaphor moved from mainframes to personal computers to mobile to cloud, and what each transition tells us about how the agentic OS will eventually stabilize. For now, the working argument is simple: the metaphor is exactly the right one. The field’s job is to build products that deserve it. Read about Web4OS, which is one of the products that has accepted the obligations the label implies.

The agentic operating system is not a marketing category. It is an architectural commitment. The products that survive the next five years will be the ones that took the commitment seriously.