nooyix

Posted on Aug 22

Agent OS: The Attempt to Treat Agents Like Processes

You hand an agent a three-day job. On the second night, the process dies.

The question to ask isn't "why did it die" but where do I restart. And to answer that, you need to know a lot. Of the thirty files it read yesterday, which are still valid? If I retry the email it already sent, does it go twice? Does it re-ask the three steps a human already approved? The context window overflowed twice and got summarized — was there a decision missing from that summary?

A framework has no answer to these four. A framework's problem is "how do I chain model calls." That's why in 2026 the term Agent OS crossed over from a research phrase into a product category name.

This post is about what that term points to, and where the reality ends and the metaphor begins. It does not cover controlling the paths an agent takes to reach outward; that's a separate post.

Terminology — one name, four different things

Search this word and things of completely different natures show up at once. Without separating them, the conversation doesn't work.

layer	what	example
research	redesigning OS abstractions for agent workloads	AIOS paper, SOSP/ASPLOS workshops
platform runtime	infra that takes on execution/state/isolation of many agents	Bedrock AgentCore, Vertex Agent Engine, Foundry, Windows
domain product	agents layered onto a specific industry workflow	Fiserv `agentOS` (banking), Amdocs `aOS` (telecom)
namesake	not an OS at all	`buildermethods/agent-os`

Clear the fourth first: buildermethods/agent-os (MIT, ~5k stars) isn't an OS — it's a dev-workflow tool that injects codebase standards and spec procedures into Claude Code/Cursor. Same name only. Be careful with the third too — Fiserv's and Amdocs' "agentOS" are not kernels but products layering orchestration and policy/audit on their own platform; here "OS" is a metaphor. This post is about the first two layers.

The concept — how is it different from a framework?

The line is clean. A framework is a library you pull in: your code is the owner and calls the framework. An operating system is a base you install under: the base is the owner and your agent runs on top of it. The difference comes down to ownership. A framework chains model calls into something usable for one task, and when the task ends the relationship ends. An OS has to hold many agents' state across many tasks for an indefinite time. Kill your process and the base remains.

This surfaces as a problem when four pressures stack up:

Long-lived. Not request-response but multi-day jobs. Dying midway becomes normal, not exceptional.
Many at once. Dozens of agents contend for the same model quota, tools, and DB. Without a coordinator they starve each other.
Finite context. Task length grows but the context window is fixed. What you hold vs. evict decides performance.
Real side effects. They write files, send mail, make payments. If a retry duplicates a side effect, that's not a bug — it's an incident.

Traditional operating systems were built for exactly these four: process lifecycle, scheduling, virtual memory, atomicity. That's why the analogy isn't a stretch.

Why now

The four pressures existed in 2024 too — but demos were short, agents ran one at a time, and they mostly just read. All three conditions broke in 2026.

The signal worth noting is that the OS research community walked in. SOSP 2026 hosts the 2nd Workshop on Operating Systems Design for AI Agents (AgenticOS; the 1st was ASPLOS 2026). Its premise matches this post's thesis — process, thread, file, socket and other OS abstractions must be fundamentally rethought for agent workloads. Its topics are concrete: dynamic sandboxing of agent-generated code, semantics-aware scheduling, long-lived context-state management, isolation, GPU virtualization. Workshops standing up at SOSP and ASPLOS mean the problem is now recognized as a systems problem.

The architecture — the six things the kernel takes on

The most literal implementation of the analogy is Rutgers' AIOS paper (COLM 2025). It peels resources and LLM-specific services out of the agent application and isolates them into an "AIOS kernel." An agent request comes in, gets decomposed into classified syscalls, and each call is bound to a thread that the scheduler dispatches to the right module queue.

The kernel's six services map one-to-one to a traditional OS.

traditional OS	AIOS kernel	job
scheduler	Scheduler	dispatch requests to module queues, coordinate concurrency
virtual memory	Context Manager	manage what stays in the context window
RAM allocation	Memory Manager	runtime state
filesystem	Storage Manager	persistence across sessions
device drivers	Tool Manager	tool loading, call-conflict resolution
permissions/users	Access Manager	access control

The paper's motivation is exact: unrestricted access to LLM/tool resources leads to inefficient or harmful allocation, and without scheduling and resource management concurrency stalls. Serving agents built with various frameworks on top of AIOS reports up to 2.1× faster execution. The thing to keep isn't the speed number but the problem definition. AIOS doesn't make agents smarter; it coordinates many agents sharing finite resources. That's what an OS has always done.

Virtual memory = context

One OS analogy already runs in production: context management.

The starting point is the 2023 MemGPT paper (Towards LLMs as Operating Systems). The idea is simple: treat the context window as RAM, and use two external stores as disk — a recall store for recent conversation and a searchable archival store. It's traditional tiered memory exactly: move data between slow and fast storage to make it "look like there's a big memory." A MemGPT agent manages via function calls what to page in and out, and the work now lives on as the Letta framework.

Three years later this is an API feature, not a paper. Anthropic's docs put two capabilities side by side:

Compaction. Near the context limit, it auto-summarizes old context and restarts a fresh window with the summary. That's page-out.
Memory tool. The agent writes to and reads from files outside the window, persisting across sessions and pulled back only when needed. That's disk.

The docs recommend using both together, which shows how accurate the analogy is: compaction keeps active context small; memory preserves what must survive the summary. Summarization is lossy, so what you can't lose must be set aside. Here the fourth opening question comes back — was there a decision missing from the summary? If you didn't specify a context policy, you can't know, because the model decided what to drop on its own. And just enlarging the window doesn't fix it (it's expensive, and utilization drops on long sequences). You need a policy for what to hold — the job virtual memory used to do.

Process = persistence

Back to the first opening question. If it died on the second night, where do you restart?

Here's the most-confused distinction: session memory is not durable execution. Saving conversation history helps the agent remember, but it doesn't prove which shell command actually ran, which email actually went out, which approval actually landed. Memory and an execution record are different things.

The lineage tackling this head-on is workflow engines, and the approach converges: persist completed execution boundaries, and on recovery after a crash, don't re-run already-finished tool calls, external changes, human approvals, or outbound messages. The best-documented example is LangGraph's persistence model, and the vocabulary mirrors an OS — a graph-state snapshot checkpoint, a thread it attaches to that becomes the primary key for save/restore, and interrupt, which halts execution, saves state, waits indefinitely, and resumes. One fact falls out: you can't use interrupt without a checkpointer — i.e., the wait-for-human-approval feature rides on persistence. (Persistence modes even make you trade durability against performance explicitly: exit·async·sync.)

Names like Temporal, Restate, Inngest, DBOS keep coming up for the same reason. Retries, timers, event history, idempotency are problems distributed systems have worked for 20 years, and agents just walked into that space. The second and third opening questions resolve here too — does the retried email go twice? is idempotency keys; do I re-ask the three approval steps? is whether the approval was recorded in a checkpoint. Neither is answerable from a chat log.

How Big Tech is doing it

The interesting part: the companies actually selling this layer rarely use the words "Agent OS." What they sell is precisely the kernel's job. (Details in the comparison table below.)

🟠 AWS — a microVM per session

Bedrock AgentCore is a framework- and model-agnostic hosting runtime, and the core is its isolation model — a dedicated microVM per user session, separating compute/memory/filesystem; when the session ends the whole microVM terminates and is sanitized, cutting cross-session contamination at the root. Not cooperative isolation but isolation enforced by a hardware boundary. On top, AgentCore Memory provides short/long-term memory and AgentCore Identity gives agents a distinct-from-human identity (Okta/Entra/Cognito).

In one line: kernel isolation implemented in raw cloud primitives. Session = microVM.

🔵 Google — sessions and memory, split and managed

Vertex AI Agent Engine splits state into two layers. Sessions is the authoritative source of conversational context, holding messages/actions in order (SessionEvents); Memory Bank extracts information from sessions for long-term retention. The method stands out — Gemini analyzes conversation history and extracts key facts/preferences asynchronously in the background. It's MemGPT's archival store turned into a managed service, and both are GA.

In one line: short-term state (Sessions) and long-term memory (Memory Bank) split along a product boundary.

🟣 Microsoft — cloud and local, both sides

On the cloud side, Foundry Agent Service hosts code-first agents built with Microsoft Agent Framework or LangGraph, and its durable agents mesh exactly with the persistence discussion above — checkpointing and resuming each step of a graph workflow, cleaning idle sessions via TTL, even streaming token output durably with delivery guarantees. Identity is pinned with Entra Agent ID. The local side is more interesting: Windows gives an agent its own desktop in an isolated execution environment while limiting its visibility into the user's desktop, distinguishing human vs. agent activity by identity. The policy-driven sandbox that handles this execution layer across Windows, WSL, and beyond is MXC (Microsoft eXecution Container).

In one line: an OS vendor directly making agents first-class principals with their own session and identity.

At a glance

	AWS AgentCore	Google Agent Engine	Microsoft Foundry + Windows
isolation unit	microVM per session	managed runtime instance	separate Windows session / MXC sandbox
short-term state	session context reuse	Sessions (`SessionEvents`)	session + TTL cleanup
long-term memory	AgentCore Memory	Memory Bank (async extraction)	delegated to framework
persistence/resume	persistent compute instance	managed runtime	durable agents (step checkpoints)
agent identity	AgentCore Identity	user-ID-scoped	Entra Agent ID / local ID
emphasis	hardware isolation	memory automation	local + cloud both

Overlay the three and a commonality remains: what they sell isn't intelligence but isolation and persistence. The model and the framework already exist; what's for sale is the guarantee that "the agent survives a crash, doesn't contaminate its neighbors, and leaves a record of who did what." And all three are minting agent-native identities (AgentCore Identity, Entra Agent ID, Windows local IDs) — a sign the era of borrowing human accounts is ending.

Soberly — what isn't an OS yet

That was where the analogy works. Now where it doesn't.

① Only a platform can enforce isolation. The microVM and Windows session above are real isolation. But many products calling themselves Agent OS are application-level middleware — cooperative isolation that works only as long as the agent goes through that path. An injection-controlled agent has no reason to man its own checkpoint. The parties with an unbypassable boundary right now are the cloud and OS vendors.

② No preemption. An OS scheduler's power comes from taking the CPU away from a running process. That's hard with an LLM call — yank mid-stream and the cost already incurred doesn't return, and partial output is usually useless. You can prioritize, but that's queuing, not preemption.

③ The syscall boundary is fuzzy. An OS's power is that a syscall is a narrow, verifiable ABI. An agent's syscall is a tool call laced with natural language — it has a schema but no semantics. send_email(to, body) passing the schema and whether the email should be sent are separate questions.

④ The name runs ahead. One name points to a paper, a cloud runtime, an industry SaaS, and a dev-workflow tool at once. This loose, and you can't tell what you're buying from the product description. This is a stage where you trust capabilities, not names.

⑤ The trust boundary is outside this layer. The runtime knows the most context, but that doesn't make it a place you can trust. Controlling the paths an agent takes outward is a problem outside the process — the gateway's topic.

Wrapping up

Read Agent OS two ways. As a product category it's early — one name for four things, no preemption, a fuzzy syscall boundary; many products bearing the name are an orchestration framework with a management UI bolted on. As a problem list it's exact — the moment agents live long, run in numbers, contend for finite context, and cause real side effects, the problems the OS solved come right back. And real pieces already exist: context became virtual memory (compaction, memory tool), process became checkpoints (durable agents), isolation became microVMs and separate sessions. GA products, not papers.

So the practical conclusion isn't "buy an Agent OS" but secure the four capabilities individually:

Context policy — decide what to summarize and what to page to a file when the window overflows (or the model drops things at random).
Checkpoint & resume — set a checkpoint granularity and attach idempotency keys to external side effects.
Isolation — give each agent separate credentials and a sandbox, and check whether the boundary is bypassable.
Observability — reconstruct what each agent did, and attribute cost to the agent.

If one vendor integrates these four, that's an Agent OS; whether it wears the label is secondary. Conversely, if the name says OS but only two of these hold, it's a framework with a label.

One last fact. The most widely used agent runtime doesn't call itself an OS. OpenClaw, a local-first personal agent released in November 2025, gathered hundreds of thousands of GitHub stars in half a year. It runs on your hardware, you talk to it over a messenger, and you swap the model. The side that solved "a long-lived agent process" pragmatically — without claiming to be a kernel — got adoption first.