Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents Yingqi Zhang
arXiv:2606.03895v1 [cs.OS] 2 Jun 2026
Department of Computer Science and Technology, Tsinghua University [email protected]
Abstract Large language model (LLM) agents are evolving from request-response assistants into long-running software actors: they maintain state across model calls, fork subtasks, wait for external events, request human authority, generate tools, and perform side effects that must be resumed and audited. Existing frameworks typically implement these behaviors as a chat loop plus a model-facing tool registry. This abstraction is convenient, but it often conflates action visibility with resource authority: a tool schema visible to the model may be backed by a wrapper that directly touches the host filesystem, terminal, network, shell, or credentials. This paper presents Agent libOS, a library-OS-inspired runtime substrate for LLM agents. Agent libOS runs above a conventional host operating system; it does not implement hardware drivers, kernel-mode isolation, or a POSIX-compatible operating system. Instead, it treats an agent as an AgentProcess: a schedulable execution subject with process identity, parent-child lineage, lifecycle state, a tool table derived from an AgentImage, typed Object Memory, explicit capabilities, human queues, checkpoints, events, and audit records. Its central design rule is tools are libc-like wrappers; runtime primitives are the authority boundary. Filesystem access, object access, sleeps, human approval, JIT tool registration, and external side effects are checked at primitive boundaries under explicit capabilities and policy. We describe the design, threat model, Python prototype, and safety-oriented evaluation. The current prototype implements async scheduling, namespace-local Object Memory, runtime-integrated human approval, one-shot permission grants, per-process working directories, shell and image-registration primitives, Deno/TypeScript JIT tools over a libOS syscall broker, filesystem/object bridge tools, an injectable Resource Provider Substrate, deterministic demos, real-model smoke scripts, and 123 regression tests at the time of writing. Rather than improving planner accuracy, Agent libOS demonstrates a runtime substrate in which long-running LLM agents can be scheduled, authorized, resumed, and audited without treating tool dispatch as the trust boundary.
1
Introduction
LLM agents increasingly behave like software actors rather than conversational assistants. A coding agent may inspect a repository, spawn a worker to parse logs, maintain a plan over many model calls, sleep while tests run, request permission before writing a patch, resume after human approval, create a specialized parser, and later explain which authority allowed each irreversible side effect. These requirements are not merely prompt-engineering issues; they are systems issues: identity, scheduling, resource authority, interrupts, isolation, recovery, and audit. The dominant engineering abstraction remains a chat loop. A framework constructs messages, asks a model for a tool call, dispatches a Python function, appends the result, and repeats. This pattern underlies important tool-use and agent systems such as ReAct [36], Toolformer [26], HuggingGPT [29], Reflexion [30], Generative Agents [22], AutoGen [33], and MetaGPT [10]. 1
The pattern is productive because it makes action exposure simple. It is also too small for agents that persist, wait, fork, acquire and lose authority, and produce side effects over time. The core problem is that the model-facing action surface often doubles as the path to host resources. In many stacks, “the model can call write_file” and “the runtime has authority to write this path” are separated only by wrapper convention. Confirmation prompts may surround a wrapper, but the primitive that touches the host resource is rarely the policy boundary. This is fragile under indirect prompt injection [7], tool-output injection, confused-deputy behavior, and long-lived agents whose authority should change over time. Agent libOS asks what agent infrastructure looks like if the operating-system analogy is applied at the runtime boundary. Processes give identity, lifecycle, parent-child relations, and signalability. Capability systems give least authority without ambient authority by name [4, 19, 8, 27]. Blocking devices such as terminals and clocks suspend one process without stopping the whole system. Checkpoints and audit records separate reconstructable state from irreversible external effects. Recent LLM systems have rediscovered parts of this vocabulary: MemGPT frames context management as virtual memory [21]; AIOS studies OS support for agent scheduling and resource management [17]; Voyager accumulates executable skills over time [31]; and MCP standardizes model-context and tool connectivity [2]. Agent libOS focuses on a narrower boundary: where a model-facing action becomes an authorized, auditable runtime operation. Scope and naming. Agent libOS is not a replacement for Linux, macOS, containers, hypervisors, or hardware-facing library OSes. The term libOS is used as a design metaphor and system name: as a library OS moves selected operating-system abstractions into an application-specific layer above a protected lower interface, Agent libOS moves agent-level execution abstractions into a runtime layer above a conventional host OS. The protected resources in this paper are agent-native resources such as object memory, tool tables, workspace paths, human approvals, checkpoints, and external side effects, not CPU cores, device drivers, or disk blocks. This paper makes four contributions. 1. It defines an agent-native, library-OS-inspired runtime model centered on AgentProcess, AgentImage, process-private Object Memory namespaces, capabilities, human queues, tool tables, events, checkpoints, and audit records. 2. It formulates the “tools as libc, primitives as runtime authority boundary” design rule: model-facing tool visibility is neither object, namespace, filesystem, shell, image-registry, nor human authority. 3. It describes a runnable Python prototype with async scheduling, resumable human and child waits, per-process working directories, namespace-local Object Memory, Deno/TypeScript JIT tools over a libOS syscall broker, shell and image-registration primitives, and an injectable Resource Provider Substrate. 4. It evaluates executable runtime properties through a deterministic demo, real-model smoke scripts, and a 123-test regression suite covering containment, revocation, fork/spawn attenuation, exec non-escalation, namespace authority, tool-table denial, JIT syscall isolation, shell policy matching, image registration authority, human-queue resumption, and wrapper purity. The claim is architectural rather than benchmark-driven. Agent libOS does not claim improved task success on SWE-bench [11], WebShop [35], or other planner benchmarks; nor does it claim formal verification or production-grade sandboxing. It instead demonstrates an executable substrate in which long-running agents are scheduled, authorized, resumed, and audited by runtime mechanisms rather than by ad hoc tool wrappers.
2
2
Related Work
Tool-using agent systems established the control loop in which a language model reasons, selects an action, observes the result, and continues. ReAct [36] makes this loop explicit; Toolformer [26], ToolLLM [24], and surveys of tool learning [23] study tool invocation and API grounding; and HuggingGPT [29] uses an LLM to orchestrate specialist models. Multi-agent and workflow frameworks such as CAMEL [15], AgentScope [6], the OpenAI Agents SDK [20], and LangGraph [14] further expose conversations, roles, handoffs, persistence, tracing, and human review as application-building abstractions. Agent libOS is complementary to these systems: it does not propose a new planner, role protocol, or tool-selection method, but specifies the runtime boundary below them. A role-based, graph-based, or ACI-style agent can run above Agent libOS while primitive managers enforce capability checks, blocking semantics, and audit. Several lines of work motivate persistent agent state and agent-specific interfaces. Reflexion [30], Generative Agents [22], MemGPT [21], and Voyager [31] show that agents benefit from memory, reflection, context paging, and accumulated skills. SWE-agent argues that languagemodel agents are a new class of computer users and that custom agent-computer interfaces improve repository navigation, editing, and test execution [34]. MCP standardizes how AI applications connect to external tools, data sources, and prompts [2]. These efforts improve what agents can remember, call, or manipulate. Agent libOS addresses a different question: when a model-facing action attempts to access an object, path, human, clock, or tool registry, which runtime subject is authorized, how that authority is attenuated across fork or delegation, and what record remains afterward. OS-inspired LLM infrastructure is closest to our framing. MemGPT uses virtual-memory terminology for context management [21]; AIOS and AOS propose an agent operating system with scheduling, context, memory, storage, and access-control services [17, 28]; and recent Agent-OS blueprints similarly argue for OS-like services for secure and interoperable agents [13]. Classical systems work also provides useful analogies: exokernels separate protection from application-level resource management [5], unikernels package applications with a specialized library OS [16], and capability systems such as KeyKOS, EROS, seL4, object-capability languages, and Capsicum motivate least authority, attenuation, and the separation of names from authority [4, 8, 27, 12, 19, 32]. Agent libOS adapts this vocabulary to stochastic, prompt-sensitive agents: the protected resources are objects, tools, filesystem paths, humans, clocks, checkpoints, and external effects, and the stable authority boundary is the primitive manager rather than the model-visible tool wrapper. Finally, prompt-injection and tool-risk studies show why wrapper-level safety is insufficient. Indirect prompt injection can make untrusted tool outputs steer LLM-integrated applications toward unintended actions [7]; InjecAgent, ToolEmu, and AgentDojo provide benchmarks and environments for tool-integrated agent risk and prompt-injection robustness [37, 25, 3]; and surveys synthesize privacy, memory, tool, and multi-agent threats [9]. Containers and microVMs such as Docker and Firecracker help protect the host from untrusted execution [18, 1], but they do not by themselves decide which in-sandbox action is authorized on behalf of a user. Agent libOS therefore does not claim to solve semantic prompt injection; a model may still be deceived about what to request. Its claim is that the requested side effects remain subject to revocation, attenuation, human approval, path/object containment, and audit at primitive boundaries.
3
Problem Statement and Design Requirements
3.1
Visibility, Authority, and Execution
A conventional tool registry answers the question, “what action schemas may the model request?” In practice it often also answers, “what host resource will be touched if the call occurs?” Agent libOS separates three decisions. 3
1. Visibility. Can this process see the model-facing tool schema? This is governed by the process tool table. 2. Invocation. May the process submit this tool call? This is checked by the ToolBroker. 3. Authority. May this operation touch a protected object, human, path, clock, or tool registry? This is checked by the primitive manager under capabilities and policy. This separation yields the main invariant: tool visibility does not imply resource authority. A process may see write_text_file and still lack write authority to any path. Conversely, a process may hold an object handle without seeing a tool that can materialize it into prompt context. The model can request actions, but authority is exercised only by runtime primitives.
3.2
Requirements for Long-Running Agents
A long-running agent runtime should provide six properties. Identity.
An agent instance must have a durable execution identity distinct from a single model call or transcript.
Lifecycle.
The runtime must represent states such as runnable, waiting on a human, waiting on a tool, paused, exited, failed, and killed.
Attenuation.
Fork, exec, and tool registration must not implicitly expand authority; child processes and generated tools should receive reduced or explicitly scoped authority.
Object memory. Intermediate state should be structured as typed, provenance-bearing objects rather than raw prompt text. Human blocking. Approval and questions should be first-class blocking operations whose resumption is handled by the scheduler, not by demo-specific callbacks. Auditable effects. External reads, writes, approvals, denials, grants, revocations, and lifecycle transitions should produce audit records with process, primitive, resource, authority, and time.
3.3
Threat Model and Non-Goals
The prototype targets threats common in agent applications: prompt injection that induces highrisk tools; tool-output injection that changes later decisions; path escape outside a workspace; unauthorized access to files, objects, or humans; capability leakage through fork; generated tools that import dangerous APIs; insufficient approval context; and confusion between tool-table membership and external-resource authority. The prototype does not solve semantic prompt injection: a malicious document may still persuade the model to request a dangerous action. The runtime claim is that such a request still encounters primitive-level capability checks, policy, human approval when required, and audit. It also does not claim kernel-grade isolation, distributed scheduling, verified access control, or transactional rollback.
4
Architecture
Agent libOS is organized as the layered stack in fig. 1. The model-facing Skills/Tools layer is allowed to evolve rapidly for usability. The libOS runtime layer is the stable authority boundary. The Resource Provider Substrate separates agent-level primitive semantics from host-backed implementations of files, clocks, subprocesses, and future resource providers. 4
Agent personality / application: domain role, system instruction, task policy, planner behavior. Skills/Tools layer: LLM-facing schemas and wrappers; libc-like surface, not the trust boundary. Agent libOS runtime: processes, Object Memory namespaces, capabilities, human queues, syscall broker, events, checkpoints, audit, filesystem, shell, image, clock, and process primitives. Resource Provider Substrate: injectable providers for filesystem, clock/sleep, shell subprocesses, and future host services. Host runtime / provider backends: model API, SQLite metadata, local workspace, host clock, Deno runtime, subprocess backend, terminal I/O. Figure 1: Agent libOS separates model-facing action schemas from primitive-level authority checks. Tools are typed wrappers; primitive managers enforce capabilities, policy, suspension, and audit.
4.1
Processes and Images
The central execution subject is AgentProcess. A process has a process id, parent id, image id, lifecycle status, goal object, memory view, capabilities, tool table, checkpoint head, resource budget, workspace-relative working directory, and status message. It is created from an AgentImage, which fixes default tools, system prompt, context policy, safety profile, and required capabilities. Current images include base, coding, review, and toolmaker agents. The virtual process model supports agent-level spawn, fork, exec, wait, signal, pause, resume, and exit. spawn creates a fresh child with its own process namespace and a goal-only memory view rather than a copy of the parent transcript. fork attenuates memory view and budget and, in the prototype, does not inherit parent filesystem-write authority unless authority is explicitly granted. wait is a resumable blocking action: the parent enters a waiting state, the child exit event wakes it, and the original wait action can resume without requiring the model to issue a second wait call. exec preserves the process id while replacing the image and tool table; it does not automatically grant the target image’s required capabilities and therefore cannot escalate authority. exit releases volatile scratch objects unless an explicit result is retained. Each process also has a working directory analogous to a conventional process cwd. Filesystemrelative paths and shell subprocess cwd are resolved against this workspace-relative field; the host Python process does not chdir into the workspace. The same field is manipulated by CLI built-ins and by process.cwd/process.chdir syscalls, so model-facing convenience commands and JIT tools observe the same process-local path state. Images are not special trusted backdoors. An image registry primitive manages registration and lookup, and registration requires image:<image_id> or image:* write authority. Loading an image from YAML first requires filesystem read authority for the manifest and then passes the parsed manifest through the image registry primitive. Thus dynamically loaded images are governed by the same capability and audit machinery as other runtime resources.
4.2
Object Memory
Object Memory is a typed, capability-protected object graph. Objects represent goals, plans, messages, tool results, observations, error traces, patches, summaries, skills, artifacts, and
5
external references. Each object has an object id, namespace-local name, type, payload, metadata, provenance, version, immutability flag, creator, and timestamps. Names are not capabilities. A process may know the string name of an object and still fail to read it unless it holds the appropriate namespace and object capabilities or an object handle. This follows the object-capability tradition [19]: discovery and authority are distinct. Regression tests cover both direct name lookup and query-by-name to ensure that name knowledge does not bypass object-read rights. Object names are local to namespaces. If a process omits the namespace argument, the runtime resolves the name in the process-private namespace process:<pid>. Explicit namespaces form directory-like scopes for shared or phase-specific memory. Namespace capabilities gate listing, lookup, and creation, while object capabilities still gate reading, writing, linking, materialization, deletion, and grant. Thus a qualified name is discoverable only with namespace authority and usable only with object authority. This makes Object Memory closer to per-process virtual address spaces than to a single global object-name table. The prototype stores payloads in volatile runtime memory rather than in SQLite. SQLite stores directory metadata and a marker indicating that the payload is present in the runtime heap. This preserves the distinction between runtime memory and durable storage: short-lived process scratch state should not automatically become a database record. Process-owned payloads are released on exit, while explicit result objects can be retained. Before each model call, a materializer converts the process memory view into bounded textual context; the model never receives direct store access. This resembles MemGPT’s virtualmemory framing [21], but the paging unit is a typed object with provenance and rights. The filesystem/object bridge can copy file contents through object handles without materializing payloads into the prompt. In the current prototype, each process’s LLM context is itself represented as a mutable Object Memory object, allowing runtime facts, events, capability snapshots, and object summaries to be appended in a controlled form rather than accumulated as an unstructured hidden transcript.
4.3
Capabilities, Policies, and Human Approval
A capability binds a subject, resource, rights, constraints, issuer, lifetime, and revocation status. Resources include object ids, Object Memory namespaces, workspace filesystem paths, humans, permission-policy entries, shell policies, image-registry entries, and tool-table entries. Primitive methods call the capability manager at point of use. Therefore revocation takes effect on the next primitive call, and a wrapper-level call cannot bypass primitive-level authority. Filesystem writes support always_allow, always_deny, ask_each_time, and allow_once policies. Under ask_each_time, the primitive creates a blocking human approval request. Approval grants a one-shot capability consumed by a single successful primitive call. Rejection resumes the process with a structured failed tool result so the agent can report the denial and continue or exit cleanly. Human approval requests include process id, primitive, path, absolute path, grant scope, overwrite prediction, byte count, content SHA-256, target state, requested one-shot capability, and a repr-escaped preview. Escaping is a security decision: raw untrusted content should not be able to insert terminal lines that appear to be trusted approval instructions. Shell execution is also mediated as a primitive rather than delegated to an arbitrary wrapper. The shell interface accepts an argv array, not a command string, and the provider executes it without shell expansion. Process-scoped shell policy supports always_deny, allowlist_auto_else_ask, blocklist_ask_else_auto, and the high-risk always_allow. Matching is over tokenized argv rather than substrings, globs, or shell syntax; blocklist checks also inspect nested executablelooking tokens such as interpreter chains. Timeouts and stdout/stderr truncation are enforced inside the primitive so that LLM-facing tools and JIT syscalls share the same boundary.
6
4.4
Humans, Scheduling, and Events
Humans are modeled as runtime objects connected to queues. A process may output a message, ask a question, request permission, or receive an interrupt. When a primitive requires human input, the process enters WAITING_HUMAN; the LLM executor records the pending action without returning a spurious tool failure. The high-level supervisor drains the human queue, applies the decision, wakes the process if appropriate, and resumes the pending action. This is analogous to a blocking system call on a terminal device, but implemented at the agent-runtime layer. A process waiting on terminal input does not stall the whole host OS or runtime; it is suspended until the device event arrives. Agent libOS uses the same structure for human approvals and questions. Likewise, sleep calls an async clock primitive, so one sleeping process does not block siblings. The public high-level API advances the runtime until no runnable or resumable work remains: results = await runtime.arun_until_idle()
Tests can disable queue draining to inspect intermediate WAITING_HUMAN states. This separates “run until idle” from “take one inspectable scheduler step.”
4.5
Tools, JIT Extension, Checkpoints, and Audit
Built-in tools are small model-facing wrappers for memory creation, file bridges, time, sleep, text-file I/O, shell execution, permission requests, human output, human questions, pytest-log parsing, process lifecycle operations, image loading, and echo. Source-level tests check that built-ins do not directly call host filesystem, terminal, network, shell, database, or secret APIs; they call runtime primitives instead. The JIT path lets a process propose a TypeScript tool candidate with schema, source code, and tests. Valid candidates are executed as Deno modules that export run(args, libos). We use Deno for JIT tools because it natively executes TypeScript while providing a deny-by-default permission model: untrusted modules run without disk, network, environment, subprocess, or FFI authority unless explicit –allow-* permissions are granted, and –no-prompt prevents runtime permission escalation through interactive prompts. The libos object exposes only syscall(name, args); it does not expose Python runtime objects or the model-facing tool registry. The Python runtime and the Deno process communicate over an NDJSON protocol on stdin/stdout. Deno is launched with –no-prompt and no host read, write, network, environment, run, or FFI permissions. Static imports are restricted to a configured jsr: allowlist, while npm:, node:, http(s):, file:, dynamic import, Deno, eval, Function, Worker, and WebAssembly entry points are rejected during validation.
4.6
JIT Syscalls
A Deno tool does not call runtime.tools and does not gain authority from its tool-table entry. Its only runtime entry point is a LibOSSyscallSession, which binds the Deno RPC session to a process id and dispatches named syscalls through primitive managers. The syscall surface covers filesystem operations, Object Memory namespace and object operations, human interaction, clock/sleep, process lifecycle operations, shell execution, and image-registry operations. Each syscall is checked under the caller process’s primitive capabilities, policy state, human-approval rules, and audit hooks. The TypeScript side observes only a final success payload or a final syscall error. Human approval inside a syscall is awaitable runtime behavior: the JIT tool is not exposed to pendingrequest protocols, retry tokens, or direct grant/revoke operations. Lifecycle syscalls such as process.exit and process.exec are ordinary syscalls; the runtime applies the resulting lifecycle state after the Deno tool returns a normal result frame. On a result frame the runtime cleans
7
up the Deno subprocess; timeouts, protocol violations, and abnormal exits are reported as failed tool invocations. Checkpoints snapshot reconstructable runtime state: process metadata, object-directory state, capability metadata, and checkpoint heads. They do not claim to roll back irreversible external effects. Such effects must be represented as audit events and, when needed, compensated explicitly. Audit records are emitted at authority-changing and side-effecting boundaries and should answer which process acted, which primitive was invoked, which resource was affected, which authority or policy allowed or denied the operation, and which human decision was involved.
5
Implementation
The prototype is a Python package named agent_libos. It uses typed tool schemas, SQLite metadata storage, an OpenAI-compatible model client, namespace-local Object Memory, a Deno/TypeScript JIT validator and runner, primitive-level filesystem, shell, image, process, human, and clock managers, and an injectable Resource Provider Substrate for host-backed services. agent_libos/ capability/ capability grant, revoke, check, object handles config/ default budgets, limits, sandbox, shell, and launcher policy external/ filesystem, shell, clock/sleep, and provider substrate human/ approval, question, output, interrupt queues images/ built-in images, registry primitive, YAML loader llm/ prompt, model client, executor, tool protocol memory/ object Memory, namespaces, handles, views, materialization runtime/ runtime, scheduler, process manager, syscalls, events, audit storage/ SQLite metadata store tools/ toolBroker, tool base classes, Deno JIT, built-ins
Table 1 summarizes implemented components and remaining engineering work. The deterministic demo, invoked by uv run agent-libos demo, exercises the main execution path without a real model. It spawns a coding-agent process, creates a synthetic pytest failure log, forks a worker, uses a parser tool, creates a checkpoint, attempts a filesystem write that is denied for missing authority, routes a human approval, writes a patch-preview file after approval, creates a final report object, exits, and returns a JSON summary. The demo is covered by a contract test. Smoke scripts additionally cover authorized model writes, summary generation with permission requests, file copy through named Object Memory without content-returning tool results, and two-process async sleep interleaving. The command-line interface provides reproducible entry points for process-local cd, YAML-image exec, explicit exit, and a coding-agent launcher that mounts an arbitrary workspace through LocalResourceProviderSubstrate without changing the host process cwd. Launcher presets expose coarse workspace permissions such as readonly, edit, and full, and shell-policy presets ranging from no shell access to explicit high-risk always-allow mode.
8
Component
Role
Prototype status
Process lifecycle
Identity, status, spawn/fork/exec/wait/signals
Per-process cwd
Workspace-relative path state for filesystem and shell Typed graph, namespaces, handles, materialization Primitive-level authority and policy
Implemented in ProcessManager, including resumable child waits. Implemented for CLI built-ins and process syscalls. Volatile payload heap with SQLite metadata. Implemented for objects, namespaces, filesystem, humans, shell, images, and tools. Integrated into runtime supervisor. Implemented with Deno permission denial and import/API checks. Implemented through the provider substrate. Implemented as a primitive rather than a backdoor. Implemented; broader provider families are future work. Implemented; external compensation is future work. Future work.
Object Memory Capabilities
Human queue
Approval, output, question, interrupt TypeScript proposal, validation, syscall-only runtime access
Deno JIT tools
Shell primitive
Argv execution under process-scoped shell policy Capability-checked image registration and YAML loading Injectable filesystem, clock/sleep, and shell providers
Image registry Provider substrate
Checkpoints Distributed runtime
Snapshot reconstructable runtime state Durable multi-worker scheduling
Table 1: Prototype coverage of the Agent libOS design.
6
Evaluation
Agent libOS is evaluated as a systems artifact. The evaluation asks whether the prototype enforces the execution and safety properties required by the architecture, not whether a particular planner solves more end tasks. Table 2 shows some of the current 123-test regression suite. Several tests encode chat-loop failure modes: approval cannot bypass tool-table isolation; human approval inside a primitive is resumed by the runtime supervisor, not a script-specific loop; and approval previews use repr-escaped content so untrusted newlines cannot masquerade as trusted terminal instructions. The artifact can be reproduced locally with uv sync, followed by uv run agent-libos demo for the deterministic scenario and uv run python -m unittest discover -s tests -v for the safety-test bundle. Additional smoke scripts cover async-clock interleaving, objectmemory file copy, permission-mediated model writes, and coding-agent launcher behavior. The deterministic demo requires no real model. Real-model scripts require an OpenAI-compatible endpoint configured in .env; TypeScript JIT tests require Deno but fail with an explicit validation error if it is unavailable. The evaluation does not yet measure task success, latency, cost, or human workload. A stronger empirical paper should wrap an existing coding or web agent inside the runtime, quantify overhead from primitive checks and audit, and run red-team prompt-injection scenarios against object, human, and filesystem boundaries. The present evaluation supports runtime semantics, not end-to-end agent superiority.
9
Property
Regression evidence
Status
Tool visibility is not authority
Visible write_text_file without write capability is denied; absent tool-table entry is denied without human escalation. Paths escaping the workspace root are rejected by the filesystem primitive. Forked children do not inherit parent filesystem write authority; spawned children start with fresh process namespaces and goal-only memory views. Same local object names in different process namespaces resolve independently. Process exit releases owned scratch objects while retaining explicit results. ask_each_time blocks inside the primitive, grants once, consumes the grant, and prompts again on the next use. Human approvals and child waits resume pending runtime actions rather than returning spurious tool failures. Two processes alternate clock output while sleeping cooperatively. TypeScript tools can call libos.syscall but cannot bypass primitive capabilities or human approval. YAML loading and image registration require filesystem and image-registry capabilities. Filesystem, clock/sleep, and shell providers are injectable without changing tool schemas. Built-in LLM-facing tools do not directly call host-boundary APIs.
Pass
Workspace containment Fork/spawn attenuation
Namespace isolation Memory cleanup Per-use approval
Human and wait resumption
Async sleep Deno JIT syscall isolation
Image registration authority Resource Provider Substrate Wrapper purity
Pass Pass
Pass Pass Pass
Pass
Pass Pass
Pass Pass Pass
Table 2: Safety and execution properties encoded in the 123-test regression suite.
7
Discussion and Limitations
Several agent-runtime problems become clearer in OS terms. Process identity makes pause, resume, fork, and wait natural. Capabilities make “why was this allowed?” a query over runtime state rather than prompt history. Object Memory forces a materializer, not the model, to decide what enters context. A human approval queue behaves like a runtime device. The tools-as-libc split lets the model-facing surface evolve without moving the authority boundary. The analogy has limits. Classical processes are deterministic instruction streams; LLM processes are stochastic and prompt-sensitive. OS memory can be byte addressed; agent memory must be selected, summarized, and materialized. Traditional kernel system calls have compact arguments; agent-level primitive calls may include natural language whose interpretation is unstable. Human approval is slower and more ambiguous than a hardware interrupt. These differences make the libOS model useful, but not sufficient by itself. The prototype has several limitations. The Deno/TypeScript JIT path avoids default host filesystem, network, environment, subprocess, and FFI permissions, but it is not a formal production sandbox; stronger deployments may still need Docker, WASM, Firecracker-style microVMs, or remote sandboxes [18, 1]. The policy engine is deliberately small: capability constraints, human permission policies, shell policy lists, and image/namespace rights cover the prototype, while richer policy languages, risk scoring, quotas, role-based human authority, and sensitivity labels remain future work. Checkpoints cannot roll back external effects. Context management is still preliminary: tool-result compaction, long-document paging, duplicate-action
10
suppression, and retrieval policy are not fully developed. Finally, the audit log is currently a record stream; future work should provide indexed queries by process, capability, primitive, resource, human request, and time range. Future work should formalize the relation among tool tables, syscalls, capabilities, policies, and fork/exec; study humans as slow, high-authority devices; harden JIT tools with stronger static analysis, resource accounting, permission-profile hardening, signed registries, and provenanceaware revocation; and build runtime benchmarks for denial correctness, unauthorized side effects, audit completeness, scheduling fairness, context growth, and memory-release correctness. The current prototype already separates primitive semantics from provider backends for filesystem, clock/sleep, and shell. Broader provider families remain future work: network, browser, database, remote execution, container-backed execution, WASM providers, servicebacked filesystems, provider-level resource accounting, and audit correlation across providers.
8
Conclusion
Long-running LLM agents need mechanisms that operating systems have long provided: identity, isolation, authority, blocking events, recovery, and audit. Current agent frameworks often encode these mechanisms weakly on top of a chat loop and thereby treat tool dispatch as the effective security boundary. Agent libOS demonstrates a different substrate. An AgentProcess is the unit of execution; namespace-local Object Memory replaces unstructured scratch transcripts; capabilities and humans are explicit sources of authority; and model-facing tools and JITgenerated TypeScript tools enter protected resources through primitive managers and syscall sessions rather than through ambient host APIs. The prototype remains a research artifact, but its safety claims are executable tests rather than slogans. The broader lesson is that agent systems should separate the interface a model can request from the authority a runtime can exercise. Artifact. The implementation, tests, and demo are available at github.com/yingqi-z20/AgentlibOS. Run uv sync && uv run agent-libos demo for the deterministic local scenario, or uv run python -m unittest discover -s tests -v for the safety-test bundle. Reproducible CLI paths include process-local cd, YAML-image exec, explicit process exit, and the codingagent launcher with workspace and shell-policy presets. Use of generative AI. The author used generative AI tools to assist with coding and language polishing. The author reviewed and revised the manuscript, verified the technical claims, references, implementation, and experiments, and takes full responsibility for the content.
11
References [1] Alexandru Agache, Marc Brooker, Andreea Florescu, Alexandra Iordache, Anthony Liguori, Rolf Neugebauer, Phil Piwonka, and Diana-Maria Popa. Firecracker: Lightweight virtualization for serverless applications. In 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20), pages 419–434. USENIX Association, 2020. [2] Anthropic. Introducing the Model Context Protocol. Anthropic News, November 2024. Accessed: 2026-05-28. [3] Edoardo Debenedetti, Jie Zhang, Mislav Balunovic, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. In The Thirty-eighth Annual Conference on Neural Information Processing Systems Datasets and Benchmarks Track, 2024. [4] Jack B. Dennis and Earl C. Van Horn. Programming semantics for multiprogrammed computations. Communications of the ACM, 9(3):143–155, March 1966. [5] D. R. Engler, M. F. Kaashoek, and J. O’Toole. Exokernel: an operating system architecture for application-level resource management. volume 29, pages 251—-266, New York, NY, USA, December 1995. Association for Computing Machinery. [6] Dawei Gao, Zitao Li, Xuchen Pan, Weirui Kuang, Zhijian Ma, Bingchen Qian, Fei Wei, Wenhao Zhang, Yuexiang Xie, Daoyuan Chen, Liuyi Yao, Hongyi Peng, Zeyu Zhang, Lin Zhu, Chen Cheng, Hongzhu Shi, Yaliang Li, Bolin Ding, and Jingren Zhou. AgentScope: A flexible yet robust multi-agent platform, 2024. [7] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, pages 79–90. Association for Computing Machinery, 2023. [8] Norman Hardy. KeyKOS architecture. ACM SIGOPS Operating Systems Review, 19(4):8–25, October 1985. [9] Feng He, Tianqing Zhu, Dayong Ye, Bo Liu, Wanlei Zhou, and Philip S. Yu. The emerged security and privacy of llm agent: A survey with case studies. ACM Comput. Surv., 58(6), December 2025. [10] Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. MetaGPT: Meta programming for a multi-agent collaborative framework. In The Twelfth International Conference on Learning Representations, 2024. [11] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R. Narasimhan. SWE-bench: Can language models resolve real-world GitHub issues? In The Twelfth International Conference on Learning Representations, 2024. [12] Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish, Thomas Sewell, Harvey Tuch, and Simon Winwood. seL4: Formal verification of an OS kernel. In Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles, pages 207–220. Association for Computing Machinery, 2009.
12
[13] Anis Koubaa. Agent operating systems (Agent-OS): A blueprint architecture for real-time, secure, and scalable AI agents. TechRxiv preprint, September 2025. Preprint. [14] LangChain. LangGraph overview. Online documentation, 2026. Accessed: 2026-05-28. [15] Guohao Li, Hasan Abed Al Kader Hammoud, Hani Itani, Dmitrii Khizbullin, and Bernard Ghanem. CAMEL: Communicative agents for “mind” exploration of large language model society. In Advances in Neural Information Processing Systems, volume 36, pages 51991– 52008, 2023. [16] Anil Madhavapeddy, Richard Mortier, Charalampos Rotsos, David Scott, Balraj Singh, Thomas Gazagnaire, Steven Smith, Steven Hand, and Jon Crowcroft. Unikernels: Library operating systems for the cloud. In Proceedings of the 18th International Conference on Architectural Support for Programming Languages and Operating Systems, pages 461–472. Association for Computing Machinery, 2013. [17] Kai Mei, Xi Zhu, Wujiang Xu, Mingyu Jin, Wenyue Hua, Zelong Li, Shuyuan Xu, Ruosong Ye, Yingqiang Ge, and Yongfeng Zhang. AIOS: LLM agent operating system. In Second Conference on Language Modeling, 2025. [18] Dirk Merkel. Docker: Lightweight Linux containers for consistent development and deployment. Linux Journal, 2014(239):2, March 2014. [19] Mark Samuel Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD thesis, Johns Hopkins University, Baltimore, Maryland, USA, May 2006. [20] OpenAI. New tools for building agents. OpenAI News, March 2025. Accessed: 2026-05-28. [21] Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. MemGPT: Towards LLMs as operating systems, 2023. [22] Joon Sung Park, Joseph C. O’Brien, Carrie J. Cai, Meredith Ringel Morris, Percy Liang, and Michael S. Bernstein. Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology, pages 1–22. Association for Computing Machinery, 2023. [23] Yujia Qin, Shengding Hu, Yankai Lin, Weize Chen, Ning Ding, Ganqu Cui, Zheni Zeng, Xuanhe Zhou, Yufei Huang, Chaojun Xiao, Chi Han, Yi Ren Fung, Yusheng Su, Huadong Wang, Cheng Qian, Runchu Tian, Kunlun Zhu, Shihao Liang, Xingyu Shen, Bokai Xu, Zhen Zhang, Yining Ye, Bowen Li, Ziwei Tang, Jing Yi, Yuzhang Zhu, Zhenning Dai, Lan Yan, Xin Cong, Yaxi Lu, Weilin Zhao, Yuxiang Huang, Junxi Yan, Xu Han, Xian Sun, Dahai Li, Jason Phang, Cheng Yang, Tongshuang Wu, Heng Ji, Guoliang Li, Zhiyuan Liu, and Maosong Sun. Tool learning with foundation models. ACM Computing Surveys, 57(4):1–40, December 2024. [24] Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun. ToolLLM: Facilitating large language models to master 16000+ real-world APIs. In The Twelfth International Conference on Learning Representations, 2024. [25] Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. Identifying the risks of LM agents with an LM-emulated sandbox. In The Twelfth International Conference on Learning Representations, 2024. 13
[26] Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. In Advances in Neural Information Processing Systems, volume 36, 2023. [27] Jonathan S. Shapiro, Jonathan M. Smith, and David J. Farber. EROS: A fast capability system. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 170–185. Association for Computing Machinery, 1999. [28] Ankur Sharma and Deep Shah. Agent operating systems (AOS): Integrating agentic control planes into, and beyond, traditional operating systems, 2026. [29] Yongliang Shen, Kaitao Song, Xu Tan, Dongsheng Li, Weiming Lu, and Yueting Zhuang. HuggingGPT: Solving AI tasks with ChatGPT and its friends in Hugging Face. In Advances in Neural Information Processing Systems, volume 36, 2023. [30] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: language agents with verbal reinforcement learning. In A. Oh, T. Naumann, A. Globerson, K. Saenko, M. Hardt, and S. Levine, editors, Advances in Neural Information Processing Systems, volume 36, pages 8634–8652. Curran Associates, Inc., 2023. [31] Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. Voyager: An open-ended embodied agent with large language models. Transactions on Machine Learning Research, 2024. [32] Robert N. M. Watson, Jonathan Anderson, Ben Laurie, and Kris Kennaway. Capsicum: Practical capabilities for UNIX. In 19th USENIX Security Symposium (USENIX Security 10), Washington, DC, USA, August 2010. USENIX Association. [33] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W. White, Doug Burger, and Chi Wang. AutoGen: Enabling next-gen LLM applications via multi-agent conversations. In First Conference on Language Modeling, 2024. [34] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik R. Narasimhan, and Ofir Press. SWE-agent: Agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems, volume 37, 2024. [35] Shunyu Yao, Howard Chen, John Yang, and Karthik R. Narasimhan. WebShop: Towards scalable real-world web interaction with grounded language agents. In Advances in Neural Information Processing Systems, volume 35, pages 20744–20757, 2022. [36] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R. Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. In The Eleventh International Conference on Learning Representations, 2023. [37] Qiusi Zhan, Zhixiang Liang, Zifan Ying, and Daniel Kang. InjecAgent: Benchmarking indirect prompt injections in tool-integrated large language model agents. In Findings of the Association for Computational Linguistics: ACL 2024, pages 10471–10506, Bangkok, Thailand, August 2024. Association for Computational Linguistics.
14