What is an Agent Operating System, and why do developers need one? 

Give an agent shell access and it may attempt something you did not intend. The questions that follow are operational rather than philosophical: what did it try, what convinced it, what permitted the call, and where is the record. 

Without decision lineage, operators cannot answer any of them. Treating agents as ordinary applications that happen to call APIs is reasonable early on, but it leaves exactly that gap. 

An Agent Operating System (AOS) is a systems software layer that manages the lifecycle, execution, coordination, and governance of goal-directed agents by extending or reinterpreting classical operating system responsibilities, while preserving deterministic behavior at the system boundary. It runs above or alongside an existing operating system, treating every model-generated action as a proposal that must pass policy, capability, validation, sandboxing, and audit controls before execution. 

The name can sound as if someone wants to replace Linux or Windows with a Large Language Model (LLM). That is not what AOS does. 

The underlying operating system still manages processes, memory, files, devices, and hardware access. The AOS adds the missing agent-level context: who the agent is, what goal it is pursuing, which tools it may use, what information influenced it, and why an action was allowed. 

The agent can decide what it wants to try. The AOS decides whether that attempt is permitted. The operating system enforces the final boundary. 

AOS is therefore a control plane, not a new kernel. 

At ASSIST Software, this question is not abstract. Our AI/ML & Data Engineering practice already builds and operates generative AI models and production MLOps pipelines for clients, and an architecture like AOS speaks directly to the governance challenges that come with that work. 

AI agents need more than processes and threads because their work is organized around goals, context, tools, and long-running decisions. A process tells the operating system what is running, but it does not explain what outcome the agent is pursuing or why it selected a specific action.

An agent may wait for a remote service, a human approval, another agent, a rate limit, or a budget reset. The kernel may see an idle process, while the agent's workflow is still active and waiting for a meaningful dependency. 

The AOS does not discard traditional operating system concepts. It gives those concepts enough context to support autonomous, tool-using workloads. 

An AOS separates reasoning, policy, and execution, so a probabilistic model cannot directly create side effects. AOS treats that separation as a core safety property.

Side effects here represent anything that changes the world outside the agent: file writes, process creation, network calls, configuration changes, or any external call that mutates state. 

The reasoning plane performs inference, planning, retrieval, and strategy selection. It may decide that a file should be changed, an Application Programming Interface (API) should be called, or a tool should be used.

That output is still a proposal, not a command. LLMs, retrieval systems, summarizers, and heuristic classifiers are all treated as potentially incorrect or influenced by untrusted input. 

The policy plane evaluates whether the proposal is allowed, denied, or deferred. It checks who is asking, what that agent is permitted to do, and whether risk, budget, and compliance constraints allow it.

The same policy inputs should produce the same result. Each result should also include a reason code that an operator can inspect later. 

The execution plane runs only actions that received an explicit allow decision. It validates the request, applies least privilege, executes the tool in a restricted environment, checks the result, and records what happened.

The model does not enforce its own permissions. Isolation, access control, network policy, and tool mediation remain outside the reasoning component. 

This architecture allows flexible reasoning without giving the reasoning component direct authority over the outside world. 

Developers can build a practical first AOS as a user-space control plane, using existing operating system mechanisms for isolation and enforcement. This is the most direct adoption path, since it avoids immediate kernel changes.

That user-space approach is only one of four integration models. The others vary in where enforcement lives like hooks inside the operating system itself, a distributed control plane governing agents across a cluster, and a long-horizon model in which AOS takes over some of the higher-level scheduling and access-control duties the operating system handles today.

Even in that last model, core kernel responsibilities stay exactly where they are, including memory paging, hardware abstraction, drivers, and filesystems. User-space remains the sensible first target because it asks nothing new of the kernel.

A practical implementation needs several services:

• Agent lifecycle management
• Goal-aware scheduling
• Context and memory management
• A tool and capability registry
• A deterministic policy engine
• Restricted tool executors
• Audit and trace correlation

Not all these need to exist on day one. The components come from the reference design, but the order in which to build them is a practical judgment rather than something AOS prescribes.

The most useful starting point is the tool mediation path: route every tool call through a single sidecar or gateway, run the policy engine behind it as a service, and reuse existing isolation from processes, containers, or virtual machines. Lifecycle management, goal-aware scheduling, and richer context handling can follow once nothing reaches a tool without traversing that path. 

The lifecycle manager tracks a richer set of states than a process does, including phases where the agent is reasoning, waiting for an external event, or suspended. These states describe the agent workflow rather than only the state of one process.

Stopping an agent may require more than killing a process. The system may need to cancel in-flight tool calls and revoke delegated tokens, and for operations that cannot be reversed, define compensating actions. 

The agent scheduler decides when an agent may reason, call a tool, wait for approval, or stop. It schedules goal progress under policy, risk, budget, and fairness constraints.

Its inputs go beyond CPU time to include cost budgets, rate limits, task dependencies, and risk posture.

Reasoning and execution should use separate resource pools. Model inference and context construction consume different resources from network access, filesystem operations, and process execution. 

The context manager treats agent memory as a governed resource with explicit lifetime and provenance. A useful decomposition in AOS is four memory classes:

• Ephemeral context: A bounded working set for one reasoning step
• Durable agent memory: Versioned state that survives across a long-running task
• Retrieved knowledge: External content with provenance, integrity, and classification metadata
• Execution records: Append-only events describing actions, policy decisions, and results

This separation helps developers define sharing, retention, deletion, and audit rules. It also lets operators reconstruct which information was available when an action was proposed. 

Linux already provides much of the low-level control AOS needs: namespaces and containers for isolation, control groups (cgroups) for resource limits, seccomp, SELinux, or AppArmor for access control, and eBPF for trace correlation. Reasoning workers and tool executors should run in separate sandboxes, each with only the access it requires. 

Windows offers a comparable but different set of primitives: job objects, containers, or Hyper-V isolation for resource limits, restricted tokens and access control lists for least-privilege execution, brokered tool processes for controlled side effects, and Event Tracing for Windows (ETW) or Windows Event Log for correlation. The same separation applies between reasoning workers and tool executors.

Linux and Windows share the same semantic gap. Neither operating system natively understands an agent’s goal, goal-scoped delegation, or decision lineage.

The AOS adds those concepts and maps them to security and resource controls already available on each platform. 

An AOS keeps tool use controlled by forcing every side-effecting request through the same deterministic mediation pipeline. The model can propose any action it likes, but it should never be able to bypass validation, policy, sandboxing, or audit.

That word “never” has to be earned. Mediation must be enforced by operating system and network controls rather than by convention, because an agent that can reach a tool or a network route outside the pipeline has bypassed the entire architecture. Controlled egress and restricted sandboxes are what turn the intent into a guarantee. 

A registered tool should define:

• Identity and schema: name, version, input schema, and normalization rules
• Risk and access: side-effect classification, required capabilities, and allowed resource scopes
• Operating limits: parameter bounds, rate limits, and quotas
• Correctness and audit: preconditions, postconditions, and audit requirements

No concrete format is prescribed, but the shape of a registered tool looks something like this: 

Read resource_scopes here as the tool’s own outer bound, with an individual agent’s capability to grant narrower still, which is what the worked example below turns on.

Capabilities are narrower than traditional permissions. A capability can allow one tool on one resource, with specific parameters, for a limited time, and it can require human approval. 

There are four architectural invariants that govern AOS:

1. No side-effecting action executes without a deterministic allow decision.
2. Every allow, deny, or defer result is written to an append-only audit record.
3. Scheduling decisions depend on observable state and budgets, not hidden reasoning tokens.
4. The underlying operating system remains the only mediator of hardware resources. 

The audit record should connect the entire decision chain. It should show what the agent observed, what it proposed, which policy evaluated it, why the decision was made, which tool was executed, and what result followed.

This is called decision lineage. It gives developers and operators more than a process trace because it connects an operating system event to the agent's goal and policy decision that caused it. 

There are several threat categories identified in AOS:

• Prompt and context manipulation
• Tool misuse
• Privilege escalation
• Data exfiltration
• Compromised tools and supply chains
• Audit bypass
• Control-plane compromise

Prompt injection gets specific treatment. The system does not assume that the model can always detect malicious instructions, so it treats model output as untrusted input and restricts what that output can do.

AOS also names compositional attacks as a distinct risk: a sequence of individually permitted actions may gradually weaken configuration, expand access, or leak information. Per-action enforcement does not catch this on its own, so some policies need to weigh action history and cumulative effects, and that kind of behavioral judgment may itself lean on probabilistic classifiers sitting outside the deterministic core.

Routing every side-effecting call through this pipeline costs latency, and AOS treats that cost as something to bound and measure rather than ignore. Bounded performance overhead is one of its evaluation criteria, and mediation latency under tool-heavy workloads is one of its proposed benchmarks.

Whether that cost is worth paying depends on what the agent can reach. For an agent that only reads and summarizes, capability scoping and sandboxed execution earn less of their keep. Output filtering and controlled egress still matter, though, because a read-only agent that can reach the network is exactly the data exfiltration case.

An agent that can delete files, move money, or change production configuration is a different case: the mediation path is the only thing standing between a bad inference and a real consequence, and the latency is trivial against that.

The harder case is the middle, and it is where this architecture will meet the most resistance in practice. A deny-by-default posture that makes an agent safe can also make it obstructive, and the path of least resistance is to widen a capability scope until the work flows again, which quietly returns the system to where it started.

AOS does not solve that pressure. Its answer is that such changes are themselves explicit, recorded, and revocable rather than invisible, which is a genuine improvement without being a fix.

AOS has not been validated through a completed implementation. What exists so far is a reference design, operating system mappings, evaluation criteria, and proposed benchmark scenarios, not measured results. 

A brokered tool call shows how AOS’s architecture translates into a developer’s workflow. The walkthrough below is illustrative, built on the reference design and the fs.delete tool above rather than on a reported production deployment.

Consider an agent whose goal is to free disk space on a build server. It reasons that old logs are the best candidate and proposes deleting everything under /var/log.

• The proposal becomes a tool request: tool fs.delete, parameter path=/var/log/*, plus the intent that justified it.
• Canonicalization normalizes the path, and deterministic validation checks it against the tool’s input schema.
• The policy plane compares the request to the agent’s capability, which grants fs.delete only under /var/log/build/. The wildcard reaches outside that resource scope.
• The decision is deny, carrying a reason code that names the scope violation.
• Nothing is executed. The proposal, the decision, and the reason code are appended to the audit record, and the scheduler decides what the agent may try next.

Had the path fallen inside the granted scope, the same pipeline would have continued into a least-privilege sandbox, run post checks on the result, and appended the outcome to the same audit record. The restricted executor draws on the same Linux and Windows primitives described earlier.

The point is not the specific operating system primitive, but that the agent never receives an unrestricted path from reasoning to execution. 

This pattern predates agents for decades. It is debatable in operating system security terms and does not draw up this comparison, but anyone who has worked on safety-critical software will recognize the shape of it immediately.

Functional safety practice solves a structurally identical problem: a component whose behavior cannot be exhaustively verified sits inside a system capable of causing real harm. The response is never to make the component perfect. It is to constrain what that component is permitted to do, using mechanisms simple enough to be verified independently of it.

The correspondences are close: 

The underlying discipline is the same in both cases: leave the unpredictable part unpredictable, and make the boundary around it deterministic, and inspectable.

This does not make an agent system safety-certifiable, and nothing claims otherwise. The standards governing safety-critical software assume constraints far stronger than any current agent at runtime can offer. The parallel is useful for a different reason: it means the hard problems here are not unprecedented, and a mature vocabulary for reasoning them already exists.

At ASSIST Software, we find AOS’s approach genuinely interesting, since our own MLOps practice already applies to a related discipline, monitoring and governing model behavior, to production AI systems. 

Is an Agent Operating System a replacement for Linux or Windows?

No. An AOS runs above or alongside an existing operating system, while Linux or Windows continues to manage hardware, processes, memory, files, and low-level isolation.

Does an AOS require an LLM inside the kernel?

No. Kernel-level model inference is explicitly not a requirement in AOS, and the reasoning plane may run locally or remotely.

Can developers build an AOS with current operating system features?

Yes. AOS responsibilities map to existing Linux and Windows mechanisms, including namespaces, cgroups, seccomp, restricted tokens, job objects, access control lists, containers, and operating system tracing.

What is the most important security rule in this architecture?

A side-effecting action must never execute without a deterministic allow decision. The request must also pass through mediation and produce an append-only audit record.

What remains an open research problem?

Open problems include goal-progress scheduling, deterministic context construction with provenance, formal verification of enforcement pipelines, cross-system delegation, cascading revocation, and policy arbitration across cooperating agents.

An Agent Operating System is not a new kernel for AI. It is a control layer that gives agents identity, goals, capabilities, memory rules, tool boundaries, and decision lineage while leaving low-level enforcement to Linux or Windows.

For developers, the value is practical: agents can use tools and perform useful work without receiving an uncontrolled path from model output to real-world side effects. AOS offers an architecture for building that boundary, and while its benchmarks and multi-agent problems remain open, the boundary itself is worth designing before it is needed rather than after. 

Ankur Sharma and Deep Shah, Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems. Available on arXiv at arXiv:2606.01508, with a direct PDF version. 

Andrei Diaconu is a Software Development Engineer at ASSIST Software with 8+ years of experience in embedded software for AUTOSAR-based automotive systems, including embedded security (HSM, CryptoDrivers) and secure communication stacks (TCP/IP, TLS).