Author(s): Gaurav Yadav

Originally published on Towards AI.

You’re Not Building an Agent. You’re Writing an Operating System.

A Cursor session running Claude Opus 4.6 took nine seconds to delete the PocketOS production database earlier this month. The agent wasn’t asked to. It was working on something unrelated, noticed an API token sitting inside a file it had read for context, decided the token was relevant to the task it had invented for itself, and used it. The Railway volume holding the database also held the backups. They went too.

Read the post-mortem and there are three reasonable fixes. Rotate the token. Isolate the backups on a different volume. Narrow the credential’s scope so it can’t drop tables in the first place. Each of those is correct, and each of them is also a one-off. The same shape of failure is going to land at a different shop next month with a different credential, a different tool, a different blast radius. Patching one incident at a time runs forever. At some point you stop patching and ask the structural question: what kind of system were they actually building, such that this was a coherent failure mode at all?

The answer is that they were building an operating system without admitting it. So is everyone else shipping agents into production right now.

Once you see the shape, this month’s vendor pile-up (Microsoft RAMPART, GitHub Agentic Workflows with OpenTelemetry tracing, Cloudflare’s enterprise MCP reference architecture, Oracle Deep Data Security 26ai, Anthropic’s self-hosted Managed Agents tunnels, Microsoft’s Agent Governance Toolkit) stops looking like five unrelated launches in a week. They are five different vendors each shipping a piece of the same operating system, with no one shipping the whole thing. The interesting question isn’t which of them is best. It’s which subsystems your team has to own because no vendor is going to.

Mine was the afternoon I traced one external MCP call all the way through our stack. It came in as an OAuth-scoped tool invocation from a partner. It triggered a managed agent running inside our network. That agent decided, on its own, to call three of our backend APIs. Each of those services authenticated using its own service account. By the time the work hit Postgres, four different principals had touched the request and none of them was the partner who had actually authorized it. I had been telling people we had auth. We had four kinds of auth and a wishbone.

The agent kernel, named subsystem by subsystem

Take PocketOS apart slowly and you can already see the missing kernel pieces. There was no boundary that distinguished “tokens this agent should be able to find” from “tokens it shouldn’t.” Call that an authorization subsystem. The file the agent was reading for context and the credentials sitting inside it shared a single trust domain, which is what OS people mean when they talk about process isolation. Nobody could grab the run in second seven and pause it. That’s a supervisor problem. And the only audit trail afterward was “the agent issued DROP, then issued another one,” which is to say observability didn’t really exist. Each of those gaps has a name in operating systems. Most of them have working answers that are forty years old.

Walk a real production agent the same way and you find roughly eleven categories where this pattern repeats. Some are places you’ve quietly reinvented something the OS people solved. Others are places you haven’t reinvented it yet, and the consequences are queued. The categories aren’t arbitrary. They are what shows up on the whiteboard once the agent is real enough to need an on-call rotation.

Identity and principals. Get this one wrong and every other subsystem inherits the bug. Who the agent is. Who it’s acting on behalf of. Which subset of the user’s authority it inherited, which subset got stripped off at the boundary. Those four questions need single, defensible answers before any other layer can do useful work. Multi-tenant systems learned the hard way that the service identity and the end-user identity have to be separable. Oracle 26ai’s Deep Data Security is the first mainstream database to enforce this for agents: the session knows the human’s identity even when the agent is the one holding the wheel. Most Postgres apps haven’t done it yet.

Authorization. Once you know the principal, what is it allowed to do. Files had rwx. Modern systems have capabilities, scopes, policies, and ACLs. GitHub Agentic Workflows v0.75.4's per-tool auditable permission modes are a small, modern instance of this: each tool the agent can reach has an explicit grant, separately auditable. Microsoft's Agent Governance Toolkit is the same idea aimed at policy enforcement and zero-trust identity for agents as a category.

Action perimeter and sandbox. Four vendors are betting on this same boundary right now: Anthropic’s self-hosted Managed Agents sandboxes, Cloudflare’s enterprise MCP reference architecture (OAuth 2.1 in front of MCP, with DLP and a portal), the indie Node9 Proxy (in-path audit and undo), and NVIDIA’s OpenShell (kernel isolation at the syscall layer). They disagree about where the wall should sit. They agree that there has to be a wall. The classical version of this rule is that userspace can’t touch the disk controller without going through the kernel. Whatever an agent reaches for, something below it should be in a position to refuse.

State, durability, and supervision. A long agent run is a long-running process, and long-running processes crash. You need checkpoints, resumable execution, idempotent steps, and a supervisor that knows what to do when one of the steps dies in flight. Statewright is the visual state-machine project that picked up traction on HN in May. humanlayer’s 12-factor-agents project (22K+ stars) is trying to codify the broader durable-execution pattern. Both are early-stage. The heavier industrial play is Temporal-class workflow engines retrofitted for agents. Every Unix derivative ended up with an init/systemd-class supervisor that restarts dead processes and gives you a single place to ask “what’s running and why.” Agent supervision is still at the shell-script stage. Nobody owns either half of this category yet.

Memory. This is the subsystem where the OS analogy buys you the least. Pageable memory was a scarcity solution: how to pretend the box had more RAM than it physically did. Agent memory is a different problem, mostly about which experiences survive the session, and in what shape. Anthropic Dreaming (scheduled background consolidation, reportedly 6x lift on Harvey’s task-completion rate) is the first-party bet. Mem0, with its twenty-one framework integrations, is the cross-framework one. There’s no neat Unix precedent for either of them. The closest equivalent problem in classical computing was solved by databases rather than kernels, and even that mapping is rough.

Knowledge and context. The kernel has a filesystem; the agent has the world. Code-graph indexers like codegraph and Understand-Anything (both crossed 20K stars in the last two weeks) are doing for source repos what find and locate did for filesystems: pre-compute the structure so the agent doesn't waste tokens rediscovering it. Skill packs (Anthropic's plugins repo, the 754-skill cybersecurity pack) are the package manager.

Observability. This used to be strace and dtrace. Today it's OpenTelemetry stretched across an agent's tool calls, which is exactly what GitHub shipped in v0.75.4 of Agentic Workflows. Distributed tracing for agents finally got first-class vendor blessing this month.

Evaluation and safety. Every OS that survived adoption had an assertion subsystem and a test fleet. The agent equivalent is CI-runnable adversarial evals. Microsoft RAMPART (built on top of PyRIT, with probabilistic verification across N runs rather than single-shot pass/fail) is the first hyperscaler entry. Cross-framework adapters like Custom Evals are the universal-syscall version.

Human-in-the-loop. A signal-based interrupt is just a structured way of saying “stop, let the human decide.” Plan-mode in Grok Build, the editable plan in Claude Code, the approval prompts in any serious agent runner: these are the agent equivalents of SIGSTOP plus a debugger attach. They're more important here than in a real OS, because the userspace program in question is non-deterministic.

Resource accounting and economics. No vendor has shipped the agent-cost equivalent of cgroups, which is a strange gap given the stakes. The cost spread between an unbounded retry loop and a cheap path runs to two orders of magnitude, a wildly different scale from anything Linux ever had to govern at the kernel level. The 5–25× West-vs-East inference price spread Epoch AI documented adds another lever on top. Someone will own this category within twelve months. Right now nobody does.

Supply chain and provenance. In April, an RCE in the official MCP SDK hit 7,000+ public servers and 150M+ package downloads, and a STDIO command-injection variant alongside it lets prompt injection register sibling malicious MCP servers inside Windsurf, Claude Code, Cursor, Gemini CLI, and Copilot. As of May 26, there is no canonical tool to audit your installed MCP servers against either disclosure. Every package manager that ever mattered eventually grew a signing apparatus, usually after exactly this kind of incident. MCP is at the stage where the incident has happened and the apparatus has not.

Eleven subsystems. Most teams have shipped opinionated versions of two or three. The rest are either delegated to a vendor that mostly owns the category, or, more often, not present at all. The consequences accrue as latent debt.

What the OS analogy buys you

Two things, and they are both unfashionable to say out loud.

The boundary you’re defending is not your app. It is the kernel API of the agent stack, wherever you happen to have drawn it. If a constraint is not enforced at the syscall layer, the agent will route around it. You can put a check in your TypeScript wrapper around the Postgres client; the agent can also write its own client. You can ask the agent nicely not to call the destructive tool. The agent will sometimes decide the destructive tool is the only path to the user’s stated goal. The classical OS insight here is that protection has to live below the program. If your perimeter lives in the same address space as the agent’s reasoning, you don’t have a perimeter. You have a suggestion.

You will not buy this OS from one vendor. The reason every vendor shipped a perimeter piece this month rather than waiting for an industry standard is that each one is trying to own a single subsystem and become the de-facto kernel call for it. Cloudflare wants the network stack. Microsoft wants the identity and policy layer. Oracle wants the storage layer. Anthropic wants the runtime. GitHub wants the tracing and tool-permission catalog. None of them will own all of it. The team holding out for one vendor to ship the entire stack is still going to be holding out in 2028, and the work falls to everyone else to put the pieces together themselves.

Two of eleven

If the metaphor were perfect this would be a much shorter piece. It isn’t perfect, and the places it cracks tell you which subsystems get harder under agents than they were under processes.

The first crack: the agent is not a deterministic program. A process, under the old model, has a fixed code path and a known set of syscalls it might issue. You can sandbox it because you can enumerate its behavior. An agent issues syscalls it invents at runtime, in response to inputs it has never seen. Sandboxing helps, but it doesn’t have the same closure property. The probabilistic-verification posture of RAMPART (safety asserted across N runs, not single attempts) is the honest response to this: you can’t prove the program is safe, only get its failure rate low enough.

The second crack: there is no MMU between the agent and the credential. In a real OS the hardware enforces that one process cannot reach into another process’s memory. In an agent system, the model and the tool-calling layer share a single trust domain. Whatever the agent can read, it can act on. PocketOS, the now-canonical incident in which Cursor running Claude Opus 4.6 deleted a Railway production database in nine seconds using a token it discovered in an unrelated file, is what happens when the kernel boundary is rhetorical rather than mechanical. The token was on the same volume as the code. The code-running agent read both. The kernel had no way to say no.

The third crack, which doesn’t get discussed enough: the principal is non-deterministic. Two invocations of the same agent on the same input may take different actions. This is fine for chat. It is unworkable for an audit story. You can’t reproduce a session in a courtroom the way you might reproduce a transaction log. Whatever observability and replay you build has to capture not just inputs and outputs but the model’s actual sampled tokens, so that “the agent did this” is reconstructible at all.

These cracks are why the OS analogy is useful without being sufficient. They are also why the wiring around the model matters more in 2026 than the model itself.

There’s a sharper version of the skeptic’s complaint, though, and it’s worth saying out loud: operating systems are mature because the problem is bounded, and agents keep changing the problem. The OS analogy is comforting because Unix worked. It may also be premature because we may be solving a subset of the wrong shape. The honest answer is that OS principles can stabilize the current mess, but only a fraction of them have actually been ported. Look at the design ideas that made operating systems work in the first place. Least privilege. A small trusted computing base. Mechanism cleanly separated from policy. Hardware-enforced isolation. Mandatory access control. Atomic state transitions at the kernel boundary. Formal verification of the most critical paths. Of that list, the agent stack has imported maybe two cleanly. Per-tool authorization is least-privilege in new clothes. Identity propagation is principal mapping. The rest are unbuilt.

Notice what’s missing in particular. There is no reference monitor. No small, audited piece of code that every agent action has to flow through, the way every Unix syscall flows through the kernel. There’s no real mechanism-versus-policy separation either: policy and enforcement still live inside the same vendor SDK, often the same process. There is no mandatory access control layer that the agent can’t route around by writing different code. The mapping is real, and the mapping is also two of eleven. The work in front of us is finishing the mapping, not declaring it done.

What to do this quarter

The temptation, when you see a list of eleven subsystems and realize you’ve shipped two, is to try to build everything. Don’t.

Pick three to own. The ones that should be yours are the ones that touch your schema and your customers’ identity, since the vendor doesn’t know your tables and no off-the-shelf identity model fits your domain. For most Postgres-on-Node teams that means: an identity-propagation layer that puts the calling user into every database session, a data-side perimeter (RLS, per-agent roles, query-cost ceilings, fork-for-destructive-work), and a state and audit store you can replay from. Those three you assemble yourself this quarter.

Pick five to delegate. Sandbox (Anthropic Managed Agents, NVIDIA OpenShell, or Node9 depending on your shape). Eval suite (RAMPART or a Custom Evals adapter). MCP edge perimeter (Cloudflare Access). Policy and identity for the broader workflow (Microsoft Agent Governance Toolkit). Observability (GitHub OTel tracing if you’re on Actions, vendor-neutral OTel otherwise). The vendor will be wrong sometimes. The vendor will also be roughly three years ahead of where your bespoke version would land, which is the right trade for a non-core subsystem.

The remaining three (memory portability, economics and routing, supply-chain provenance for MCP) are open gaps with no good answer. Track them, don’t build them, and refuse to lock in any single vendor on memory until an export story exists.

Models change every six weeks or so, and the new one is usually better than the last. That side of the work mostly takes care of itself. The win goes to the teams who notice, early, that they’re doing systems engineering rather than feature engineering, and treat the kernel they’re building with the same care as the rest of the operating system underneath it.

Most of those boxes are probably already on a whiteboard inside your team. The hard part this quarter isn’t drawing more boxes. It’s deciding which ones you’re willing to own, which ones you trust a vendor to ship for you, and which ones you can defensibly wait out for another six months.

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI