Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents

Original Author/Maintainer: arXiv Author Team Source Platform: arXiv Original Title: Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents Original Link: http://arxiv.org/abs/2606.03895v1 Publication Date: June 2, 2026

Core Viewpoint: Agent libOS draws on the design philosophy of library operating systems to provide a runtime substrate for LLM agents. It treats tool calls as libc-style encapsulations, enforces permission boundaries at the runtime primitive level, and supports agent scheduling, authorization, recovery, and auditing.

Large language model agents are evolving from simple request-response assistants to long-running software participants. They need to maintain cross-call states, fork subtasks, wait for external events, request human authorization, generate tools, and perform side-effect operations—all of which need to be recoverable and auditable. This evolution brings system-level challenges: the traditional tool call model treats agents as stateless function callers, but long-running agents require OS-like abstractions (process identity, lifecycle management, resource isolation, permission control, audit logs).

Design Philosophy: Drawing on the library OS philosophy, it provides a runtime substrate for LLM agents, running on top of the host OS without implementing hardware drivers. It treats agents as AgentProcesses (schedulable entities containing identity, lineage, state, tool tables, object memory, capabilities, human queues, checkpoints, events, and audit records). Core principle: Tools are libc-style encapsulations, and runtime primitives are permission boundaries. Key Abstractions and Mechanisms:

• AgentProcess: Agent process with full lifecycle management;
• AgentImage: Initial state (tool table, initial capabilities);
• Object Memory: Typed object storage with namespace isolation support;
• Capability Control System: Explicit authorization, which can be inherited or obtained explicitly;
• Human Queue: Pauses when human judgment is needed, resumes after receiving a response;
• Checkpoint and Recovery: Supports persistence and cross-host recovery for fault tolerance and load balancing.

The paper describes a Python prototype implementation, including: asynchronous scheduling, namespace-local object memory, runtime-integrated human approval, one-time permission grants, per-process working directories, shell and image registration primitives, Deno/TypeScript-based JIT tools (via libOS system call proxy), file system/object bridging tools, injectable resource provision substrates, deterministic demonstrations, real-model smoke test scripts, and 123 regression tests.

Comparison with Existing Methods: The goal is not to improve planner accuracy, but to provide a runtime substrate that enables long-running LLM agents to be scheduled, authorized, recovered, and audited—without treating tool calls as trust boundaries. Unlike most frameworks that focus on prompt engineering, tool definition, or planning algorithms, it is an "operating system" for agents rather than an "application framework." Technical Significance: It represents an important evolution in LLM agent system architecture, providing system-level support for complex long-running agents. Its design principles and implementation experience can guide future agent infrastructure construction.

Future work directions:

• Expand to more programming languages;
• Deeply integrate with container technologies;
• Support distributed agent collaboration;
• Provide richer auditing and analysis tools;
• Explore the possibility of formal verification for capability models.