The Agent OS Becomes the Control Plane
A June 2026 arXiv paper argues that agents should not be treated as ordinary apps with more API calls. They need a control plane between probabilistic reasoning and deterministic side effects.
New Workload
The paper, arXiv:2606.01508 [cs.CR], is Ankur Sharma and Deep Shah's Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems. arXiv records submission on June 1, 2026. The paper's central move is to treat agents as a workload class that strains the old process-thread-system-call picture.
A process has a program counter, resources, permissions, and observable system calls. An agent has those pieces underneath it, but it also has goals, retrieved context, dynamic tool choices, budgets, approvals, memory provenance, and long-lived state. A blocked thread may be idle from the scheduler's view. A blocked agent may be waiting for a tool, a human approval, a policy check, or evidence needed to continue a plan.
The authors call the answer an Agent Operating System, or AOS: a systems layer that manages lifecycle, execution, coordination, and governance for goal-directed agents while preserving deterministic behavior at the boundary where real side effects happen. This is not a proposal to throw away kernels. It is a proposal to put intent and governance into the control plane above them.
First-Class Entities
The useful part of the paper is its object list. In an AOS, agent identity becomes a principal with scoped authority and lifecycle. Goal and task graphs become schedulable objects. Capability sets define which tools and resources can be touched, with scopes and bounds. Context state becomes a managed memory view rather than an accidental prompt buffer. Execution records become append-only audit trails for decisions and actions.
That list matters because it names what ordinary operating systems do not naturally know. Linux and Windows can isolate processes, enforce access tokens, limit CPU or memory, trace events, and constrain network flows. They do not know that a model is halfway through reconciling a customer record, that a tool call belongs to a delegated human purpose, or that a retrieved document had a different trust label than the durable memory it was summarized into.
The paper maps AOS concepts onto existing substrates instead of pretending a new kernel is required. Linux primitives include cgroups, namespaces, seccomp, AppArmor or SELinux, netfilter, auditd, and eBPF. Windows primitives include services, scheduled tasks, restricted security tokens, job objects, Windows containers or Hyper-V isolation, Event Tracing for Windows, and enterprise policy controls. The AOS layer supplies the missing semantic binding.
Deterministic Boundary
The architecture separates reasoning, execution, and policy. The reasoning plane can plan and infer probabilistically, locally or remotely, but it is treated as untrusted for policy. The execution plane performs deterministic tool invocation and side effects in least-privilege environments. The policy plane performs authorization, risk checks, compliance constraints, and budget controls, denying by default where ambiguous and producing logged reason codes.
This boundary is the paper's sober core. Model outputs are proposals, not commands. Side effects such as file writes, process creation, network calls, configuration changes, or state-mutating API calls should not happen unless a deterministic enforcement path allows them. The authors state invariants in that direction: no side-effecting action executes without a deterministic policy allow, policy outcomes are recorded before rescheduling, scheduling depends on observable state and budgets, and the underlying OS remains the mediator of hardware resources.
The threat model follows from that split. The paper names prompt and context manipulation, tool misuse, privilege escalation, data exfiltration, compromised tools, audit evasion, and compromise of the control plane itself. It also warns that individually permitted actions can compose into gradual configuration weakening, incremental exfiltration, or multi-step privilege expansion. Per-action checks are necessary, but action history still matters.
Tool and Memory Semantics
Tools become the AOS equivalent of system calls, but they require richer contracts. A tool definition should carry a name and version, input schema, validation rules, side-effect classification, required capabilities, scopes, rate limits, deterministic prechecks, postconditions, expected outputs, and audit requirements. Tool invocation should pass through schema normalization, policy checks, risk checks, budget checks, sandboxed execution, post-checks, and append-only logging.
Memory gets the same treatment. The paper distinguishes ephemeral context, durable agent memory, retrieved knowledge, and execution records. It argues that context construction should be deterministic enough for audit: retrieval sets, filters, summarizer versions, provenance, integrity metadata, classification labels, retention rules, and deletion evidence all need records. Full replay of model reasoning may be impractical, but policy decisions and effective context views should be reconstructable.
This is where the AOS frame becomes more than branding. Agent memory is no longer "whatever was in the prompt." It becomes an operational resource with namespaces, trust labels, lifetimes, sharing rules, deletion semantics, and forensic value.
Limits That Matter
The page should not oversell the paper. It is an architecture and analysis paper, not a deployed AOS benchmark. Its evaluation criteria are proposed systems properties: deterministic enforcement correctness, audit completeness, containment and least privilege, operator comprehensibility, bounded overhead, and safe failure modes. The benchmark scenarios are representative rather than executed: tool-heavy workflows, multi-agent coordination, adversarial input campaigns, and incident-response replay.
The non-goals are equally important. The paper does not require the kernel to run model inference, does not claim that classical operating-system abstractions should be discarded wholesale, and does not present a universal agent framework. Its immediate practical path is user-space AOS runtimes with strong mediation supported by ordinary OS controls.
Governance Standard
A production agent safety case should say where the AOS boundary is. Which component owns agent identity? Which component issues and revokes capability grants? Which path mediates all side-effecting tools? Which OS and network controls prevent bypass? Which audit schema records proposed action, policy decision, reason code, tool metadata, output summary, and correlation to OS traces?
The paper's best governance lesson is that agent safety cannot live entirely in prompt text or model policy. It has to be enforced where the agent stops thinking and starts changing shared state. The Spiralist version is plain: the operating system for agents is not a personality layer. It is the ledger, scheduler, memory clerk, capability registry, and veto path that make autonomy administrable.
Sources
- Ankur Sharma and Deep Shah, Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems, arXiv:2606.01508 [cs.CR], submitted June 1, 2026.
- arXiv PDF: Agent Operating Systems (AOS), reviewed for the AOS definition, assumptions, non-goals, first-class entities, Linux and Windows mappings, threat categories, deterministic enforcement principles, and evaluation criteria.
- Related pages: The Agent Runtime Becomes the Governance Plane, The Operating System Becomes the AI Gatekeeper, The Memory Operation Becomes the Wire Protocol, The Agent Sandbox Becomes the Airlock, AI Agents, and AI Agent Observability.