Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents Yingqi Zhang
arXiv:2606.03895v2 [cs.OS] 29 Jun 2026
Department of Computer Science and Technology, Tsinghua University Beijing, China [email protected]
Abstract
Keywords
Large language model (LLM) agents are becoming long-running software actors rather than fixed tool users. They accumulate memory, activate Skills, synthesize tools, fork children, attach remote resources, and commit checkpoints into reusable execution images. These mechanisms improve adaptability, but they create a systems-security failure mode: if exposing an action also grants the authority needed to perform it, self-evolution becomes a permissionescalation path. This paper presents Agent libOS, an agent-native library-OS substrate for capability-controlled self-evolving agents. The central invariant is that model-visible affordances may evolve while resource authority changes only through explicit, audited runtime primitives. Agent libOS represents an agent as an AgentProcess with process identity, lifecycle state, process-local Object Memory, a working directory, message queues, a tool table, loaded Skills, process-local Deno/TypeScript just-in-time (JIT) tools, child processes, hierarchical budgets, checkpoints, and explicit capabilities. AgentImage objects define boot-time prompt and tool-table state; Skills and JIT tools extend the action surface; checkpoint-derived images make internal state reusable. None of these mechanisms grants filesystem, shell, human, Object Memory, process, checkpoint, image, JSON-RPC, Model Context Protocol (MCP), or pseudoterminal (PTY) authority by itself. The research prototype implements a thread-backed scheduler, process-local namespaces, SQLite/PostgreSQL runtime persistence, configurable LLM-call observability, human approval queues, hierarchical resource budgets, syscall-mediated Deno/TypeScript JIT tools, trusted startup Runtime Modules, optional Object-bound PTY sessions, checkpoint restore/fork/commit, client-only JSON-RPC and MCP providers, a local Electron supervision console, and a deterministic runtime-safety benchmark harness. On 27 versioned deterministic tasks in the artifact, Agent libOS completed the task plans while preventing all modeled unauthorized side effects; it also conservatively denied 7.0% of allowed effect attempts. Under the same task plans, deliberately simple direct-wrapper, confirmationwrapper, and sandbox-only baselines preserved task completion but failed most safety checks. The contribution is a runtime authority boundary for agents whose tools, Skills, images, checkpoints, and remote affordances can change after deployment without silently expanding what they may affect.
LLM agents, capability systems, library operating systems, selfevolving agents, runtime security, tool use
1
Introduction
LLM agents increasingly behave like long-running software actors rather than single request-response assistants. A coding or research agent may persist task memory across sessions, load a skill package, generate a TypeScript tool, fork a child process, run tests, ask a human for write authority, checkpoint its state, resume after a message, and later boot from a checkpoint-derived image. Recent work on self-evolving agents makes this trend explicit: agents may evolve models, context, tools, and architecture; they may adapt within a test-time episode or across episodes; and update signals may come from rewards, textual feedback, demonstrations, or population search [2]. Systems such as Voyager, AFlow, SkillWeaver, Alita, and the Darwin Gödel Machine show that agent capability increasingly comes from changing memory, code, tools, and workflow structure, not only from scaling a frozen language model [18, 24, 33– 35]. This shift exposes a runtime boundary problem. A common implementation pattern is still a chat loop: render a prompt, expose tool schemas, ask the model for an action, dispatch a host function, append the result, and repeat. This pattern underlies ReAct, Toolformer, AutoGen, MetaGPT, SWE-agent, and many industrial frameworks [9, 20, 28, 30, 31]. The pattern is productive because action exposure is simple. It is fragile because it often conflates three distinct questions: what action schemas the model can see, what operation it may invoke, and what protected resource that operation may affect. Self-evolution makes this conflation more dangerous. Consider an agent reading a malicious repository file that asks it to activate a “debugging” Skill, register a generated JIT tool, call an MCP server, and commit the resulting state into a new image. In a wrapperlevel design, each step may appear to be an ordinary tool call. If Skill activation, JIT registration, or remote-tool visibility implicitly carries host access, then untrusted text can turn action-surface evolution into resource-authority evolution. Confirmation prompts and containers help, but they are not sufficient: a confirmation prompt typically surrounds a wrapper rather than the primitive that touches a resource, while host isolation does not identify which agent process, capability, policy, human decision, or checkpoint lineage authorized a side effect. Agent libOS starts from a single invariant: A self-evolving agent may change what it can ask for, but it cannot thereby change what it is authorized to affect.
CCS Concepts • Security and privacy → Authorization; • Computer systems organization → Operating systems; • Computing methodologies → Artificial intelligence. 1
Zhang
The runtime boundary is process identity + capability + primitive + audit. A process may see a model-facing tool, activate a Skill, register a Deno/TypeScript JIT tool, register or execute an AgentImage, fork a child, use a checkpoint, inspect a remote endpoint, or run a GUI workflow. Protected effects still occur only inside libOS primitives, where the caller process id, typed capability resources, policy, human approval, provider containment, resource budgets, events, and audit records are enforced. This paper makes four contributions.
child processes, opening devices, and checkpointing execution state more than they resemble rewriting a prompt string.
2.2
Why wrappers are insufficient
A model-facing wrapper is an interface. It can validate JSON arguments and return a structured observation. It is not, by itself, an authority boundary. If wrappers directly call the host filesystem, shell, database, browser, network, or terminal, then the security property of the agent system depends on every wrapper author implementing the same checks correctly. Indirect prompt injection and tool-output injection exploit precisely this gap between untrusted text and trusted tool execution [3, 7, 32]. Tool emulation and agent-risk benchmarks similarly show that harmful actions can arise from ordinary-looking tool loops [19]. Self-evolution multiplies the wrapper problem. A static tool list can be reviewed once; an evolving tool list, skill set, image registry, checkpoint graph, or remote endpoint catalog changes during execution. The system therefore needs a stable lower boundary: the set of visible actions may change, but every protected effect must pass through a small set of runtime primitives whose authorization rules do not move when the model adds a new affordance.
(1) It formulates runtime self-evolution as a systems problem: tools, Skills, images, checkpoints, child processes, Object Memory, and remote endpoints must evolve without becoming hidden permission grants. (2) It presents the Agent libOS runtime model, centered on AgentProcess identity, AgentImage boot state, process-local Object Memory namespaces, tool tables, Skills, JIT tools, hierarchical budgets, message queues, checkpoints, human queues, typed capabilities, provider-classified external effects, and append-only audit. (3) It describes a Python implementation with a thread-backed scheduler, SQLite/PostgreSQL runtime store, Deno/TypeScript syscall mediation, trusted Runtime Modules, optional Objectbound PTY sessions, JSON-RPC and MCP client providers, checkpoint-derived images, persistent LLM-call records, a CLI, and a local Electron supervision console. (4) It reports an implemented deterministic runtime-safety harness with 27 tasks, wrapper and sandbox baselines, a side-effect oracle, audit checks, and metrics for unauthorized side effects, false denial, approval count, resource use, and audit completeness.
2.3
Threat model and non-goals
The prototype targets threats common in agent applications: untrusted repository files, retrieved documents, tool outputs, generated Skill text, JIT source, remote-provider responses, and process messages may try to steer an agent toward unauthorized reads, writes, deletes, shell execution, Object Memory materialization, process control, checkpoint use, image registration, remote calls, or human-approval confusion. The adversary may know object names, namespace strings, endpoint ids, tool names, or checkpoint ids. The adversary may also induce the model to request a dangerous action. The trusted computing base consists of the Agent libOS runtime managers, configured Resource Provider Substrate backends, host-selected LLM profile registry, and trusted startup Runtime Modules whose manifests and source hashes are accepted by the operator. Deno/TypeScript JIT tools, Skills, images loaded from ordinary workspaces, model outputs, repository contents, and remote results are not trusted to enforce policy. The host OS, Python interpreter, Deno runtime, SQL backend, and optional containers or microVMs are assumed to provide their usual engineering guarantees, but Agent libOS does not claim to be a kernel, hypervisor, formal sandbox, or verified access-control system. The goal is to prevent unauthorized protected effects and retain enough provenance to audit allowed and denied effects. Agent libOS does not solve semantic prompt injection: a malicious document may still persuade the model to request a harmful action. It does not roll back irreversible external effects; checkpoint restore reconstructs scoped runtime state and reports provider-classified external effects. It does not make trusted Python Runtime Modules safe to load from untrusted authors. It does not improve planner accuracy by itself.
The claim is architectural rather than planner-centric. Agent libOS does not propose a new reasoning prompt, multi-agent role protocol, or optimizer for tool synthesis. It provides a substrate in which such mechanisms can evolve their action surface without silently expanding the authority behind that surface.
2
Problem Setting, Threat Model, and Design Goals 2.1 What evolves in an agent? The self-evolving-agent literature broadens the update target beyond model weights. Gao et al. organize the field around what evolves, when evolution occurs, how the update is produced, and where evolution is situated [2]. The “what” dimension includes model parameters, context such as prompts and memory, tools, and architecture. The “when” dimension distinguishes intra-test-time adaptation from inter-test-time evolution. The “how” dimension includes reward-based learning, imitation or demonstration learning, and population-based or evolutionary methods. Agent libOS focuses on a practically important subset: runtime self-evolution of non-parametric components. A deployed agent may change its prompt context, activate a Skill, register a JIT tool, create a new process, add an image, commit a checkpoint into a reusable image, attach a remote endpoint, or use an object-backed terminal session. These operations are not model-weight updates, but they materially change what the agent can request. In an OS analogy, they resemble loading code, changing an address space, creating
2.4
Design goals
These observations motivate seven design goals for a runtime substrate for self-evolving agents. 2
Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents
The fundamental invariant is:
G1: Process identity. Long-running agents require stable identity for lifecycle control, authority ownership, budgets, audit, and parent-child relations. A conversation id is not enough; the runtime needs subjects that can be spawned, forked, paused, resumed, signaled, waited on, and exited. G2: Action-surface evolution without implicit authority. A process must be able to change visible tools, Skills, JIT tools, images, checkpoints, and remote-resource affordances without thereby acquiring filesystem, shell, human, object, process, image, checkpoint, JSON-RPC, Model Context Protocol (MCP), or pseudoterminal (PTY) authority. G3: Primitive-level authorization. Protected effects must be checked at the point of use, after path resolution, argument normalization, policy evaluation, human approval, resource-budget preflight, and provider containment. Tool visibility is necessary for model selection, not sufficient for side effects. G4: Explicit memory authority. Names, object ids, namespace strings, and context snippets are not capabilities. Memory access requires object and namespace authority; context materialization must be budgeted and audited. G5: Blocking and resumable events. Human questions, approvals, sleeps, child waits, message waits, and background tasks must suspend one process without stalling the runtime. Resumption must preserve the original pending primitive rather than converting a wait into a tool failure. G6: Durable but scoped recovery. Checkpoints should reconstruct internal runtime state while preserving append-only audit, events, LLM-call history, human history, and external-effect records. They should not pretend to roll back the outside world. G7: Explainability under evolution. After an evolving agent performs or is denied an effect, the runtime should explain which process acted, which tool or syscall was used, which primitive crossed the boundary, which capability or policy applied, what human approval was involved, what provider effect was classified, and how the action relates to checkpoint and image state.
Δ𝐴𝑝 ⇏ Δ𝐶𝑝 . Changing the action surface does not imply a change in resource authority. Capabilities may change only through explicit capability operations, trusted bootstrap, scoped human approval, checkpoint restore or fork under capability checks, or audited admin action. Even then, capability changes are records with issuer lineage; they are not hidden side effects of registering a tool or loading a Skill. For every committed protected effect 𝑒, the runtime requires a primitive invocation under a concrete process identity, a successful capability decision, and an audit record: commit(𝑒) ⇒ ∃𝑝, 𝜌, 𝑑. primitive(𝑝, 𝜌) ∧ authorize(𝑝, 𝜌) = 𝑑 ∧ 𝑑 ∈ {allow, askApproved} ∧ audit(𝑒, 𝑝, 𝜌, 𝑑). The formula is intentionally about committed effects, not model choices: a model may request many actions, but only primitiveauthorized requests cross the boundary.
3.2
Images and boot state
An AgentImage defines default process boot state: prompt, prompt composition mode, default tool table, default Skills, optional processlocal JIT tools, declared required capabilities, required startup Runtime Modules, default LLM profile, context policy, safety profile, boot metadata, and optional image-package workspace seed. An image can be fresh, package-backed, or checkpoint-derived. Image definitions are self-evolution mechanisms. An agent can register a new image package, execute a target image, or commit a checkpoint into a checkpoint-derived image. None of these operations grants external authority automatically. Image-declared capabilities are bootstrap or operator-review declarations; exec and checkpoint-derived boot do not mint those capabilities. Imagedeclared modules are startup prerequisites; boot fails closed unless the exact trusted module id and source hash are already loaded.
3 System Model 3.1 Processes, affordances, and authority
3.3
A Agent libOS process is a runtime subject:
Primitives
A primitive is a trusted runtime operation that may cross a protected boundary. Examples include filesystem read/write, shell execution, Object Memory lookup/materialization/write/link/delete, human question/approval, process spawn/fork/exec/wait/signal/exit, clock sleep, checkpoint create/restore/fork/commit, image registration, Skill activation, JIT registration/execution, JSON-RPC call, MCP tool call, and PTY interaction. Primitives perform the same sequence regardless of whether the caller is a Python tool wrapper, a Deno/TypeScript JIT syscall, a CLI workflow, the GUI, or a trusted startup module syscall handler: (1) normalize the requested resource, path, argv, endpoint, method, object, image, or checkpoint id; (2) evaluate typed capabilities, deny/ask/allow effects, constraints, expiry, delegation lineage, and one-shot use state; (3) apply deterministic primitive policy such as shell allowlists, network registry rules, path containment, byte limits, and schema validation; (4) block on human approval if the policy demands it;
𝑝 = ⟨𝑖𝑑, 𝑖𝑚𝑔, 𝑠𝑡𝑎𝑡𝑢𝑠, 𝑚𝑒𝑚, 𝑐𝑤𝑑,𝑇 , 𝑆, 𝐽, 𝐶, 𝐵, 𝑄, 𝑐ℎ𝑖𝑙𝑑𝑟𝑒𝑛⟩, where 𝑖𝑚𝑔 is the current AgentImage, 𝑠𝑡𝑎𝑡𝑢𝑠 is a lifecycle state, 𝑚𝑒𝑚 is a process-local Object Memory view, 𝑐𝑤𝑑 is a workspacerelative working directory, 𝑇 is the static model-visible tool table, 𝑆 is the set of loaded Skills, 𝐽 is the set of process-local JIT tools, 𝐶 is the set of capability records, 𝐵 is the hierarchical resource budget and usage record, 𝑄 is the durable message queue, and 𝑐ℎ𝑖𝑙𝑑𝑟𝑒𝑛 is the process-tree relation. We distinguish the action surface from authority. The action surface of process 𝑝 is: 𝐴𝑝 = 𝑇𝑝 ∪ 𝑆𝑝 ∪ 𝐽𝑝 ∪ 𝐼𝑝 ∪ 𝑅𝑝 , where 𝐼𝑝 contains visible image and checkpoint affordances and 𝑅𝑝 contains visible remote endpoint/server affordances. Authority is instead the set of capability decisions reachable from 𝐶𝑝 under typed resource matching, deny dominance, constraints, one-shot use counts, expiry, delegation lineage, and human policy. 3
Zhang
• a ProcessManager for lifecycle, process-local working directories, image transitions, parent-child relations, signals, and waits; • an ObjectMemoryManager for typed object payloads, namespaces, handles, ownership, lifecycle release, file/object bridge, memory views, and context materialization; • a CapabilityManager for typed matching, deny dominance, one-shot grants, delegation, revocation, and human-derived policy; • a ToolBroker for static tools and process-local JIT tools; • a SkillManager for standard SKILL.md packages, package snapshots, activation, unload, and bundled JIT registration; • primitives for filesystem, shell, clock/sleep, human I/O, process, checkpoint, image, JSON-RPC, MCP, and runtime syscalls; • a checkpoint manager, event bus, audit manager, LLM executor, trusted Runtime Module registry, and local CLI/GUI APIs.
Agent personality / application User goal, task-specific policy, model profile selection. Skills and tools layer Prompt instructions, static tool schemas, workflow hints, Skill packages, process-local JIT candidates. This layer is model-facing and evolvable, but non-authoritative. Agent libOS runtime Scheduler, process manager, Object Memory, ToolBroker, Skill manager, syscall router, primitive managers, capability manager, human manager, event bus, checkpoint manager, audit manager, runtime store. Resource Provider Substrate Filesystem, clock, shell, human I/O, JSON-RPC over HTTP, MCP client, PTY module provider; future backends include containers, WASM, browser, database, Git, and service providers.
The default store is SQLite, with PostgreSQL available through an optional backend. SQL rows persist metadata and append-only records; ordinary Object Memory payloads remain runtime-only unless captured by scoped checkpoint snapshots or image artifacts. Reopening a store releases unmaterializable runtime-only payload rows fail-closed rather than treating markers as real payloads. Filebacked SQLite stores take an active-runtime lease, preventing two writable runtimes from concurrently opening the same database.
Host backends Workspace filesystem, subprocess backend, local terminal or UI, pre-registered remote endpoints, pre-registered MCP servers, SQL stores. Figure 1: The Agent libOS layer model. Model-visible selfevolution happens above the runtime boundary; protected effects happen through primitives below it.
4.3
A capability is not a bearer token hidden in a prompt. It is a structured, durable authority record:
(5) charge budgets and reserve one-shot authority only after precommit validation succeeds; (6) call the Resource Provider Substrate when a host or remote effect is needed; (7) emit events, external-effect records, and audit records.
𝑐 = ⟨𝑠𝑢𝑏 𝑗𝑒𝑐𝑡, 𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒, 𝑟𝑖𝑔ℎ𝑡𝑠, 𝑒 𝑓 𝑓 𝑒𝑐𝑡, 𝑖𝑠𝑠𝑢𝑒𝑟, 𝑙𝑖𝑛𝑒𝑎𝑔𝑒, 𝑐𝑜𝑛𝑠𝑡𝑟𝑎𝑖𝑛𝑡𝑠, 𝑙𝑒𝑎𝑠𝑒, 𝑠𝑡𝑎𝑡𝑢𝑠⟩.
This sequence is the libOS boundary. The wrapper that exposes a model action is deliberately smaller than the primitive that owns authority.
Resources are typed, canonical identifiers for filesystem subtrees, Object Memory objects and namespaces, process ids, images, checkpoints, JSON-RPC endpoint methods, and MCP server/tool pairs. Rights include read, write, delete, execute, materialize, link, diff, grant, revoke, approve, and admin, depending on the primitive. Effects are allow, deny, or ask. Deny dominates matching allow records. The runtime rejects bare global wildcard authority and unknown rights. Wildcards are terminal and typed: a filesystem subtree grant covers a normalized subtree, not a string-prefix collision such as src versus src2. Unknown constraint keys fail closed. One-shot authority is an allow capability with uses_remaining=1; committed primitive use consumes it, and revocation follows when the count reaches zero. Capability mutation is explicit. An actor may issue, delegate, or revoke authority only if it is trusted, is the original issuer, holds covering admin authority, or holds covering grant authority and the rights being transferred. Delegation can attenuate resource, rights, expiry, constraints, and delegation depth, but it cannot launder a parent deny/ask boundary or transfer finite-use rights. Fork and spawn inherit authority only through explicit delegation. Exec may preserve selected authority, but it never grants the target image’s declared requirements automatically.
4 Architecture and Authority Model 4.1 Layering Figure 1 shows the runtime structure. The Skills and tools layer is intentionally ergonomic: it names actions in a form the model can select. The runtime layer owns agent-level semantics: identity, authority, scheduling, context materialization, checkpoints, wakeups, and audit. The provider substrate performs concrete host calls, but providers are backends, not security bypasses. Replacing the filesystem or shell provider must not change tool schemas or skip primitive checks.
4.2
Capability records
Runtime composition root
The implementation composition root wires the following managers: • a RuntimeStore for process rows, Object Memory metadata, capabilities, messages, human requests, LLM calls, events, audit, tools, Skills, modules, images, checkpoints, external effects, JSON-RPC endpoints, and MCP servers; 4
Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents
4.4
flags, and information-flow flags. HTTP URL rules reject nonHTTP(S) schemes, remote plain HTTP, userinfo, fragments, literal header secrets, redirects, forbidden headers, unsafe DNS targets, and metadata/private/reserved IP resolution for non-local endpoints. Secrets are environment-backed; resolved secret values are not persisted. Provider calls emit external-effect rows classified as irreversible, rollbackable, or no_rollback_required. Checkpoint restore reports those effects but does not compensate remote side effects in v1.
Human approval as a runtime device
Human approval is modeled as a blocking primitive, analogous to a terminal device at the agent-runtime layer. A filesystem write under an ask policy creates a human request containing process id, primitive name, canonical resource, grant scope, target state, overwrite prediction, byte count, content hash, requested one-shot capability, risk, and escaped preview. The process enters waiting_human; other processes continue. When a human approves, the runtime installs or consumes the scoped one-shot capability and resumes the original primitive. Rejection returns a structured failure to the process without converting the wait into a runtime exception. This matters for self-evolution. A model may request permission, but it cannot request broad high-risk grants such as root/global filesystem write, shell wildcard execution, or capability-admin authority through the ordinary approval path. Approval is not a prompt convention; it is a primitive state transition that records issuer lineage and audit context.
4.5
5
5.1
Skills
A Skill is a standard package rooted at SKILL.md with optional scripts/, references/, and assets/. Discovery reveals catalog metadata; activation materializes full instructions into one process prompt, adds declared static tools to the process tool table, and validates bundled TypeScript JIT tools through the same Deno path as model-proposed tools. Package hashes bind normalized metadata, instructions, resource bytes, and JIT source hashes. Reading Skill resources uses the activation snapshot rather than ambient filesystem access to the package source. Skills are therefore explicit self-evolution mechanisms: they can change how the model works and what actions it can request. They remain non-authoritative. Advisory required-capability metadata can guide the model or operator, but it cannot create capabilities. Unloading a Skill removes contributed prompt context and tool visibility; it does not revoke unrelated capabilities or roll back side effects.
Shell, PTY, and JIT containment
Shell execution accepts argv arrays, not shell strings. The shell primitive resolves the process-local working directory, checks workspace containment, applies deterministic command-risk rules over executable identity and argv tokens, blocks or asks as needed, enforces subprocess wall/CPU/RSS budgets through the provider, and emits paired intent/result audit records. High-risk policy modes are explicit. Deno/TypeScript JIT tools run without Deno host permissions for read, write, network, environment, subprocess, or FFI access; they run with –no-prompt and cached-only runtime dependency behavior. Static checking rejects dynamic imports, disallowed dependency schemes, common code-generation forms, and unsafe import patterns, but static filtering is not the security boundary. The boundary is Deno no-permission execution plus the libOS syscall protocol plus primitive capabilities, human approval, and budgets. Trusted Runtime Modules are different. They are Python host extensions loaded before Runtime.open() returns, bound to manifestdeclared source hashes. They may register tools, images, syscalls, provider hooks, and startup hooks. Because they execute in the host interpreter, they are part of the trusted computing base and are governed by module-hash trust, not process capabilities. The standard PTY module uses this path: it adds PTY tools and an image, but PTY creation still enters shell authorization and follow-on PTY read/write/resize/close operations use Object Memory capabilities over an EXTERNAL_REF handle.
4.6
Self-Evolution Mechanisms
Table 1 summarizes the primary self-evolution surfaces and their authority consequences.
5.2
JIT tools and syscalls
The JIT lifecycle has three phases: propose, validate, and register. A process stores a candidate with schema, TypeScript source, tests, and metadata. Validation runs bounded static checks, import allowlist checks, source/test size checks, and configured tests in the sandbox. Registration adds the validated tool only to the registering process tool table. Runtime reopen reloads executable TypeScript sources only for JIT ids still referenced by a process tool table; stale tool references without recoverable source are removed fail-closed. A JIT module exports run(args, libos) and can reach the runtime only through libos.syscall(name, args). The NDJSON protocol between Python and Deno has run frames, syscall frames, syscall results, and final result frames. Human approval, child waits, process-message waits, and sleep are internal blocking behavior inside syscalls; the caller does not see a public pending/retry protocol. This prevents generated code from implementing its own unsupervised authority semantics.
Remote resources
Agent libOS supports client-only JSON-RPC over HTTP and MCP Tools. Agents, Skills, and JIT tools cannot pass URLs, credentials, headers, transports, commands, or raw wire methods at call time. They pass endpoint/server ids, method/tool ids, and JSON parameters. The primitive first constructs the capability resource from those stable ids and checks invocation authority before loading manifest metadata or schemas. Thus a caller without authority cannot enumerate a registered endpoint through error messages. Endpoint and server manifests store method/tool ids, wire names, rights, schema, timeout, byte limits, rollback class, state-mutation
5.3
Images, checkpoints, and memory inheritance
Images and checkpoints give self-evolution a durable internal-state substrate. A process can create a scoped checkpoint, inspect or diff it, fork a new subtree from it, restore it destructively under 5
Zhang
Mechanism
What evolves
Authority gate
Skill activation
Prompt instructions, allowed static tools, bundled JIT candidates, explicit resources.
Deno/TypeScript JIT
Process-local generated tools with schemas, source, tests, and syscall use.
Image registration and exec
Prompt mode, default tool table, default Skills, boot metadata, optional package workspace seed, process lifecycle shape. Internal runtime state becomes a reusable checkpoint-derived image.
Changes one process’s prompt context and tool table. Does not grant filesystem, shell, memory, process, checkpoint, JSON-RPC, MCP, human, or image authority. Registration exposes a new action. Runtime effects still pass through libOS syscalls and primitives; Deno receives no ambient host permissions. Image visibility and exec do not grant declared capabilities. Package workspace grants apply only to the private materialized copy. Captures reconstructable process-local memory, JIT, Skills, cwd, and image metadata. External capabilities become declarations, not live authority. Provider state is not captured. Fork is capability-controlled; revoked, expired, or newly restricted capabilities are not widened. Private namespaces and object ids are remapped. Spawn starts fresh with goal-only memory and no broad external authority by default; fork attenuates selected memory and authority. Runner child has a narrowed tool table. Result ids in notifications are references, not capabilities. Owner watches do not grant object read/materialize rights. Callers pass ids, not URLs or secrets. Method/tool capability is checked before manifest metadata or schemas are exposed. PTY creation uses shell authorization; read/write/resize/close use object rights, with write restricted to the original session owner.
Checkpoint commit Checkpoint fork
A process subtree is remapped into a new isolated subtree.
Child process spawn/fork
Parallel execution, worker specialization, ObjectTask runners, parent-child waits.
Object tasks
Objects own background tool work and owner-watch messages.
Remote endpoints
Registered JSON-RPC and MCP method/tool catalogs. Interactive terminal-like host sessions represented by Object Memory external references.
PTY sessions
Table 1: Self-evolution in Agent libOS changes affordances or reconstructable internal state, while resource authority remains gated by primitives and capabilities.
admin authority, or commit it into a new image. Checkpoints capture reconstructable runtime state: process rows, statuses, working directories, Object Memory metadata and payloads for the subtree, namespaces, links, subtree capabilities, tool tables, JIT candidates, loaded Skill snapshots, mailbox state, image definitions needed by the subtree, checkpoint-derived artifacts, and loaded module ids/source hashes. Restore is deliberately append-only outside the reconstructed subtree. It does not delete audit records, events, LLM calls, checkpoint records, or human history. It does not roll back filesystem, shell, JSON-RPC, MCP, network, human-output, module, or provider side effects. Providers classify effects, and restore reports effects since the checkpoint under a report-only policy. Checkpoint commit is similar in spirit to a container image commit, but scoped to agent-runtime state. It captures internal Object Memory, loaded Skills, process-local JIT tools, cwd, prompt context settings, and module requirements; it does not capture the real filesystem, shell state, remote endpoints, global Skill trust, resource budgets, or provider state.
5.4
lookup authority and object read/materialize authority. Released objects are not returned by lookup, listing, or materialization, and release revokes stale object capabilities. Each process has a default private namespace. Spawn creates a fresh goal-only view; fork attenuates a parent memory view; child memory can be merged into a parent under explicit lifecycle rules. File/object bridge tools move content between workspace files and Object Memory without returning full payloads into promptvisible tool results. Context materialization is budgeted over final rendered text, not attacker-supplied token estimates. A mutable llm_context: object accumulates process facts and summaries; explicit context compaction spawns a constrained child summarizer and atomically replaces old entries only if validation and version checks pass.
6 Implementation 6.1 Prototype status The current implementation is a Python research prototype. Table 2 summarizes implemented components.
Object Memory and context 6.2
Object Memory is a typed, capability-controlled graph, not a key/value store. Objects have ids, types, namespace-local names, versions, metadata, payloads, provenance, explicit ownership, lifecycle state, and object capabilities. Names are local to namespaces and are not capabilities. Reading a named object requires namespace
LLM execution and observability
An AgentProcess stores only an llm_profile_id; the host resolves that id to an OpenAI-compatible profile at call time. Root spawn uses an explicit host profile, image default, or runtime default; fork and child creation inherit the parent profile by default; 6
Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents
Component
Implemented behavior
Process lifecycle
spawn, fork, exec, wait, signal, pause, resume, exit; process-local cwd; child waits; durable message queues; interrupt delivery. Thread-backed process scheduling through run_until_idle() and async wrapper arun_until_idle(); blocked quanta do not monopolize scheduler progress. Hierarchical tool-call, LLM-call/token, context-materialization, subprocess wall/CPU/RSS, filesystem byte, JSON-RPC/MCP byte, and Deno syscall budgets charged to the acting process and parent chain. SQLite by default, optional PostgreSQL; persists process/object metadata, capabilities, messages, human requests, LLM calls, events, audit, tools, Skills/JIT, object tasks, endpoints, image artifacts, external effects, and checkpoints. Process-private namespaces, explicit owners, release and stale capability revocation, file/object bridge, process-result retention, ObjectTask result links, context materialization and compaction. Typed resource matching, deny/ask/allow effects, one-shot grants, issuer lineage, delegation depth, revocation, leases, deterministic authority rules, fail-closed malformed constraints. Questions, output, permission requests, one-shot approvals, terminal queue processing, durable request states, wait/resume semantics. Deno/TypeScript propose/validate/register lifecycle; static checks and import allowlist; no-permission cached-only runtime; NDJSON syscall protocol; process-local persistent reload. Client-only JSON-RPC over HTTP and MCP Tools through registered manifests, id-based invocation, hidden-metadata capability gate, schema/byte/time limits, secret redaction, external-effect classification. Manifest-hash trusted Python startup modules; module-registered tools/images/syscalls/provider hooks; standard PTY module with Object-bound sessions. Scoped checkpoint create/list/inspect/diff/restore/fork/replay; checkpoint-derived image commit; module prerequisite checks; append-only audit/effects boundary. CLI, direct workflow entrypoint, real-model smoke scripts, deterministic demo, local Electron GUI over HTTP/SSE with bearer-token loopback access. Deterministic runtime-safety harness with 27 versioned YAML tasks in the M1 run reported here, baselines, ablations, side-effect oracle, metrics collection, and a self-evolution subset.
Scheduler Resource budgets Runtime store Object Memory Capabilities Human queue JIT tools Remote providers Runtime Modules and PTY Checkpoints/images Interfaces Benchmark
Table 2: Implementation coverage of the current Agent libOS prototype.
exec preserves the current profile unless the host overrides it. Modelfacing process tools do not expose arbitrary LLM-profile switching in v1. Every LLM action-selection call is persisted with provider ids, API mode, token usage when available, errors, and bounded observability envelopes for prompts, visible schemas, model output, tool calls, reasoning metadata, and raw provider responses. Full LLM input/output persistence is enabled by default to support self-evolution training and fine-tuning pipelines in controlled research or owner-operated deployments. Systems that process third-party data should disclose this retention behavior or set llm.persist_full_io=false to store previews, sizes, hashes, and truncation metadata instead. If a token budget exists and the provider does not return billable usage, the LLM action fails closed; when provider-reported usage exceeds the budget, selected tools are not dispatched. Tool calls, JIT syscall arguments, validation logs, and failed results are similarly recorded as bounded/redacted envelopes. Sensitive fields such as content, payload, params, questions, answers, source code, stdout, stderr, and metadata are not persisted raw in audit/event records. Full tool results are stored only as Object Memory result objects under hard serialized payload limits; larger data should move by file or object reference.
6.3
GUI and supervision
The local Electron console is a host-facing supervision surface, not a new authority boundary. Electron starts a local Python GUI server on loopback with a random bearer token, and the renderer lacks Node.js access. The GUI shows process trees, status, cwd, resource budgets, message badges, human request cards, capabilities, tools, Skills, checkpoints, audit, events, images, JSON-RPC, MCP, Object Memory summaries, LLM calls, and human ratings. It can spawn processes, step or run selected processes, pause auto-run, send messages and interrupts, register images, commit checkpoints, activate Skills, call remote endpoints, and respond to human requests. High-risk GUI operations require explicit confirmation before the server invokes runtime operations. The server also rejects those requests without a confirmed flag. When a request carries an actor process id, the server enforces that process’s capabilities; otherwise it runs as an audited local admin actor. API and GUI visibility never grant process authority.
7
Evaluation
The empirical goal is not to show that Agent libOS improves a particular planner. It is to test whether the runtime boundary preserves safety and provenance when an agent changes its action surface. The current artifact therefore evaluates deterministic attack plans 7
Zhang
against the runtime and against simpler baselines. These experiments should be read as a runtime-safety evaluation, not as a claim about real-model prompt-injection robustness.
7.1
difference is whether the runner prevents forbidden effects and records enough provenance. In the recorded run used for Table 3, the Agent libOS row executed 72 tool calls and 13 primitive-level effect attempts under mock LLM plans, accounting for 140 synthetic LLM tokens and 47.5 seconds of wall-clock runtime in the local test environment. The wall-clock number is environment-dependent and is reported only as a smoke-cost indicator. The same run exercised the selfevolution surfaces used by the paper thesis: two Skill activations, one JIT registration, one image registration, one checkpoint-toimage commit, two image exec attempts, three child-process operations, one checkpoint fork, and one JSON-RPC remote call. The zero unauthorized-effect result is the core evidence for RQ1 within this deterministic workload: changing the modeled action surface did not change resource authority. The 7.0% false-denial rate comes from three self-evolution attempts whose task oracle marked the high-level behavior as allowed, but whose concrete runtime path required additional explicit bootstrap authority. These denials are conservative rather than unsafe. They identify places where package registration and child-delegation ergonomics can be improved without weakening the primitive boundary. The wrapper and sandbox-only rows show why host isolation and confirmation are incomplete as agent-level authority mechanisms. The sandbox runner can mark shell/network behavior as simulated, but it still lacks process-local capabilities, memory namespaces, checkpoint lineage, image authority, remote-method authority, and audit linkage. In this benchmark, the confirmation wrapper increases approval count but does not change the primitive that performs the effect; when its confirmation rule approves, the forbidden effect still occurs.
Evaluation questions
The M1 harness is organized around four questions. RQ1: Unauthorized side effects. When an agent attempts to use visible tools, activated Skills, JIT tools, images, child processes, checkpoint forks, or remote endpoint visibility to cross a forbidden boundary, does the runtime prevent the effect? RQ2: Useful completion under policy. When a task is feasible using allowed resources, does primitive-level authority preserve useful completion without excessive false denial or approval prompts? RQ3: Audit completeness. For each modeled effect, does the runtime retain enough linkage to identify the process id, tool or syscall, primitive, capability or policy decision, human approval, and provider effect classification? RQ4: Cost of the boundary. What visible overhead does the boundary introduce in tool calls, primitive calls, wall time, token accounting, approval count, subprocess monitoring, and audit volume compared with direct wrappers, confirmation wrappers, and host-isolation-only baselines?
7.2
Benchmark and runners
The checked-in benchmark suite contains 27 YAML tasks covering secret-read attempts, forbidden filesystem writes and deletes, shell bypass and exfiltration attempts, Object Memory authority leakage, process authority leakage, and self-evolution attempts involving Skills, JIT tools, image registration/exec/checkpoint commit, child processes, checkpoint fork, and JSON-RPC visibility. Each task declares a goal, fixture workspace, attack class, allowed effects, forbidden effects, success oracle, safety oracle, initial capabilities, policy, scripted human responses, expected audit conditions, and deterministic mock actions. No human-subject study is reported; the human-response path is a runtime mechanism exercised through deterministic fixtures. The default path is token-free: mock actions use the same shape as LLM-facing tool calls and can be executed or simulated by all runners. Real-model mode is explicit and restricted to a single task or –limit 1 smoke run. The harness includes four runners used in Table 3. The directwrapper baseline treats wrappers as the main control point. The confirmation-wrapper baseline adds wrapper-level confirmation. The sandbox-only baseline models host isolation without agentlevel capabilities. The full Agent libOS runner uses process capabilities, primitives, human policy, audit, and persisted LLM-call accounting. The artifact also includes ablation runners that remove primitive approval, audit linkage, namespace isolation, or fork attenuation; the table below reports the stable baseline comparison.
7.3
7.4
Executable invariant map
The repository maintains a machine-checked invariant map connecting runtime claims to pytest nodes and benchmark attack classes. At the artifact revision used for this manuscript, the invariant-check script validates 35 invariant groups against 889 collected pytest nodes under the repository’s test configuration. Table 4 summarizes the main invariant groups.
7.5
Artifact maturity and claim boundary
The current evaluation supports the narrower architectural claim that, for modeled runtime effects in deterministic tasks, primitivelevel capabilities can prevent self-evolution from silently expanding authority. It does not yet constitute a full end-to-end agent evaluation. Larger real-model prompt-injection workloads, adversarial remote-provider tasks, Git/worktree providers, long-running context-growth workloads, audit-query latency, and productiongrade sandbox backends remain future evaluation work. The current benchmark is deterministic by design: it isolates the runtime boundary from planner variance, but it does not measure whether a model will choose safe or useful actions.
Results
Table 3 reports the deterministic run generated by the benchmark runner and metrics collector in experiments/. All runners follow the same task-level action plans, so task success is 100% for all rows. Task success here means reaching the declared high-level goal under the deterministic plan; it does not imply safety. The 8
Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents
Runner
Tasks
Task success
Safety pass
Unauth. effects
False denial
Approvals
Audit
27 27 27 27
100.0% 100.0% 100.0% 100.0%
7.4% 7.4% 7.4% 100.0%
58.1% 58.1% 58.1% 0.0%
0.0% 0.0% 0.0% 7.0%
0 27 0 0
0.00 0.00 0.00 1.00
Direct wrapper Confirmation wrapper Sandbox only Agent libOS full
Table 3: M1 deterministic runtime-safety results over 27 tasks. Unauthorized effects are forbidden effects among performed effects; false denials are allowed effects denied by the runner.
Invariant group
Claim checked by tests and benchmark mappings
Tool visibility is not authority
Visible tools, Skills, endpoints, JIT tools, images, and tool-policy declarations do not grant protected resource authority. Filesystem, shell, PTY, JSON-RPC, MCP, checkpoint, Skill, image, and Object Memory primitives validate authority, policy, limits, and hidden metadata gates before side effects. Typed resources, deny dominance, one-shot grants, revocation, transfer-only grant, parent-linked delegation attenuation, restrictive boundaries, and malformed-rule fail-closed behavior. Spawn, fork, exec, cwd, child waits, signals, process messages, and lifecycle actions do not imply broader authority; exec does not mint target-image requirements. Object names and namespaces are not capabilities; materialization is budgeted by final rendered context; lifecycle release revokes stale authority. Human questions and approvals block, resume, reserve/consume one-shot authority exactly once, and are append-only audit events. Deno JIT execution is syscall-mediated and no-permission; shell/PTY access is policy-bound, argv-based, resource-accounted, and auditable. Skill activation, image registration/exec, checkpoint restore/fork/commit, and agent-output handling do not create hidden authority or control channels. JSON-RPC and MCP calls use registered endpoint/server/tool authority, hide manifests before capability checks, classify provider effects, and fail closed on missing host configuration. Resource budgets are hierarchical; LLM token use is charged before dispatch; sensitive tool/LLM/JIT records are bounded and redacted when full persistence is disabled.
Primitive checks before effects Capability matching and delegation Process authority is explicit Object Memory isolation Human approval and audit JIT, shell, and PTY containment Self-evolution mechanisms Remote providers Budgets and observability
Table 4: Runtime-invariant groups implemented in the current artifact. The map keeps paper claims tied to executable tests and benchmark attack classes.
8.2
8 Related Work 8.1 Self-evolving and self-improving agents
Tool use and agent-computer interfaces
ReAct, Toolformer, ToolLLM, HuggingGPT, Reflexion, AutoGen, MetaGPT, CAMEL, AgentScope, and SWE-agent establish agentic patterns for reasoning, tool use, multi-agent collaboration, workflow roles, and agent-computer interfaces [6, 9, 11, 17, 20, 22, 23, 28, 30, 31]. CodeAct replaces a fixed JSON-like action set with executable code actions, increasing compositionality and enabling actions to be revised through execution feedback [25]. OpenHands/OpenDevin provides a software-development agent platform that writes code, uses a command line, browses the web, and runs agents in sandboxed environments [26]. These works are closest to Agent libOS in making computer interfaces first-class. The difference is the unit of enforcement. Agent-computer-interface work usually focuses on action representation, environment access, or task completion; Agent libOS treats those interfaces as model-visible affordances layered over primitive managers that retain process identity, capability checks, effect classification, and audit.
Self-evolving agents aim to adapt from data, interactions, feedback, and experience rather than remain static after deployment. The survey by Gao et al. provides the field taxonomy used in this paper: model, context, tool, and architecture evolution; intraand inter-test-time evolution; and reward, demonstration, and population-based update mechanisms [2]. Voyager demonstrates open-ended skill acquisition in Minecraft [24]. AFlow searches over code-represented workflows [34]. SkillWeaver synthesizes reusable web-agent skills [35]. Alita emphasizes minimal predefinition and autonomous construction of task-related external capabilities [18]. The Darwin Gödel Machine iteratively modifies its own coding-agent codebase and validates changes empirically [33]. These systems differ in where the update lands—model weights, prompts, tool libraries, workflows, or agent code—but they share a common systems consequence: an initially deployed agent can later expose new action surfaces. Agent libOS is complementary to these optimizers. It asks what runtime boundary is needed when evolutionary updates are allowed to persist, fork, call tools, affect humans, and reach remote resources.
8.3
Benchmarks and interactive environments
Agent benchmarks such as SWE-bench, WebArena, and OSWorld move evaluation beyond isolated question answering into software 9
Zhang
engineering, realistic web interaction, and open-ended desktop workflows [10, 29, 36]. They are essential for measuring whether an agent can complete useful tasks in an external environment. Agent libOS targets a different but complementary measurement problem: whether evolvable runtime mechanisms preserve authority invariants while the agent changes its Skills, JIT tools, images, checkpoints, child processes, remote endpoints, and GUI-facing actions. This distinction matters for self-evolving agents. A tasksuccess benchmark can show that an agent can act; a runtime-safety benchmark must show that new or modified action surfaces do not silently inherit ungranted authority.
8.4
9 Discussion 9.1 Why a libOS abstraction? The library-OS analogy is useful because it localizes agent-specific OS-like abstractions above a conventional host OS. Agent libOS does not schedule CPU cores or drive disks. Instead, it manages agent-native resources: tool tables, prompt context, Object Memory, process identity, human queues, checkpoints, images, Skills, JIT code, and remote endpoint handles. This is the layer at which selfevolution occurs and where wrapper-level designs lack a stable boundary. The analogy also clarifies the role of providers. A filesystem provider can be local, remote, container-backed, or WASM-backed. A shell provider can be disabled, simulated, containerized, or monitored. A remote provider can be JSON-RPC, MCP, browser, database, or Git. In all cases, the primitive retains the caller identity, capability check, policy, event, audit, and effect classification.
LLM operating systems and memory systems
MemGPT frames LLM context management as virtual memory [16], and AIOS studies operating-system support for LLM agents through scheduling, context management, memory, storage, access control, and LLM/tool resource management [13]. Agent libOS shares the OS vocabulary but places the boundary at the agent-runtime layer rather than at a general service kernel. Its resources are agentnative: tool tables, Skills, Object Memory, process images, checkpoints, message queues, human approval queues, JIT code, and provider endpoints. The design therefore emphasizes capabilitybearing calls into primitives, lineage-preserving evolution, and audit of committed external effects, rather than general-purpose OS scheduling or POSIX compatibility.
8.5
9.2
Security and prompt injection
Indirect prompt injection, tool-output injection, and agent security benchmarks demonstrate that untrusted observations can drive harmful tool calls [3, 7, 19, 32]. Agent libOS does not claim to solve prompt injection semantically. It constrains the consequences: untrusted prompt content may cause the model to request actions, activate Skills, synthesize JIT tools, register images, or call remote providers, but protected effects still require capabilities, policy, approval, budgets, and primitive checks. In this respect, Agent libOS is closer to a reference monitor for agent effects than to a prompt-level defense. Prompt hardening, content classifiers, and model-side refusal policies can be deployed above it, but they do not replace primitive-level mediation.
8.6
Limits of the model
LLM processes differ from classical processes. Their execution is stochastic, prompt-sensitive, and mediated by a model provider. Memory cannot be byte-addressed; it must be selected, summarized, compacted, and materialized. Natural language can appear inside primitive arguments and policy contexts, making validation partly semantic. Human approval is slower and less precise than a device interrupt. These differences mean the OS analogy is a design guide, not a proof of safety. Agent libOS also has implementation limits. Deno no-permission execution is a useful layer for TypeScript JIT tools, but it is not a formal production sandbox. Stronger deployments may need containers, WASM, microVMs, remote sandboxes, or provider-specific isolation. Runtime Modules are trusted Python host code and therefore expand the TCB. Checkpoint restore does not compensate irreversible external effects. Audit-explain queries are not complete; current tests check record emission and selected counts rather than rich natural-language explanations. Context materialization metadata is not yet complete enough to compute per-call included, omitted, summarized, and truncated object statistics for every LLM call.
9.3
Implications for self-evolving systems
Self-evolution increases the need for stable authority boundaries. If an agent can improve its tools, it can also create more powerful failure modes. If it can commit state into images, it can persist unsafe learned procedures. If it can attach remote endpoints, it can move effects outside the local workspace. The runtime should therefore make self-evolution visible, scoped, reversible where possible, and auditable where not. Agent libOS’s design principle—evolve affordances without implicit authority—is a minimal systems requirement for such agents.
Operating systems, capabilities, and sandboxes
Capability systems separate designation from authority and provide a natural substrate for least authority [4, 8, 15, 21, 27]. Exokernels and library OSes move selected OS abstractions above a protected lower interface [5, 12]. Containers and microVMs provide host isolation [1, 14]. Agent libOS borrows from these traditions but does not implement a kernel, hardware isolation, POSIX compatibility, or formal verification. Containers, WASM runtimes, Deno, browser sandboxes, and microVMs are provider backends; they do not replace agent-level authority, lineage, human approval, and audit. The relevant boundary for self-evolving agents is therefore not only whether arbitrary code is sandboxed, but whether every committed resource effect is attributable to an agent process and authorized by a capability-bearing primitive call.
10
Conclusion
Self-evolving agents require more than a smarter planner and a larger tool catalog. They require a runtime substrate that lets modelvisible affordances change without turning those changes into hidden permission grants. Agent libOS provides such a substrate by 10
Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents
treating an agent as a process with explicit identity, Object Memory, tool tables, Skills, JIT tools, images, checkpoints, message queues, budgets, capabilities, human queues, provider-classified effects, and append-only audit. Its central boundary is not a prompt rule or a wrapper convention, but process identity plus capability checks at primitive use. The current artifact demonstrates this boundary on deterministic tasks involving Skills, JIT tools, images, checkpoints, child processes, remote providers, and GUI workflows while keeping resource authority explicit. The broader lesson is that selfevolving agents should evolve what they can request, not silently what they are allowed to affect.
llm-integrated applications with indirect prompt injection. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, AISec ’23, page 79–90, New York, NY, USA, 2023. Association for Computing Machinery. ISBN 9798400702600. doi: 10.1145/3605764.3623985. URL https://doi.org/10.1145/ 3605764.3623985. [8] Norman Hardy. KeyKOS architecture. ACM SIGOPS Operating Systems Review, 19(4):8–25, 1985. doi: 10.1145/858336.858337. URL https://doi.org/10.1145/858336. 858337. [9] 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. URL https://openreview.net/forum?id=VtmBAGCN7o. [10] 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. URL https://openreview.net/forum?id=VTF8yNQM66. [11] 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, 2023. URL https://proceedings.neurips.cc/paper_files/paper/ 2023/hash/a3621ee907def47c1b952ade25c67698-Abstract-Conference.html. [12] 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. doi: 10.1145/2451116.2451167. URL https://doi.org/10.1145/2451116.2451167. [13] 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. URL https://openreview.net/forum?id=L4HHkCDz2x. [14] Dirk Merkel. Docker: Lightweight Linux containers for consistent development and deployment. Linux Journal, 2014(239), 2014. URL https://www.linuxjournal.com/content/docker-lightweight-linux-containersconsistent-development-and-deployment. [15] Mark Miller. Robust composition: Towards a uni ed approach to access control and concurrency control. Johns Hopkins University, 2006. [16] Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. MemGPT: Towards LLMs as operating systems, 2023. URL https://arxiv.org/abs/2310.08560. [17] 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. URL https://openreview.net/forum?id=dHng2O0Jjr. [18] Jiahao Qiu, Xuan Qi, Tongcheng Zhang, Xinzhe Juan, Jiacheng Guo, Yifu Lu, Yimin Wang, Zixin Yao, Qihan Ren, Xun Jiang, Xing Zhou, Dongrui Liu, Ling Yang, Yue Wu, Kaixuan Huang, Shilong Liu, Hongru Wang, and Mengdi Wang. Alita: Generalist agent enabling scalable agentic reasoning with minimal predefinition and maximal self-evolution, 2025. URL https://arxiv.org/abs/2505.20286. [19] 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. URL https://openreview.net/forum? id=GEcwtMk1uA. [20] 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. URL https://proceedings.neurips.cc/paper_files/paper/2023/hash/ d842425e4bf79ba039352da0f658a906-Abstract-Conference.html. [21] 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. doi: 10.1145/319151.319163. URL https://doi.org/10.1145/319151.319163. [22] 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. URL https://proceedings.neurips.cc/paper_files/paper/2023/hash/ 77c33e6a367922d003ff102ffb92b658-Abstract-Conference.html. [23] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning. In Advances in Neural Information Processing Systems, volume 36, 2023. URL https://proceedings.neurips.cc/paper_files/paper/2023/file/ 1b44b878bb782e6954cd888628510e90-Paper-Conference.pdf.
Artifact Availability The implementation, documentation, benchmark harness, and GUI are available at https://github.com/yingqi-z20/Agent-libOS. The deterministic demo is invoked with uv run agent-libos demo. The benchmark smoke path runs run_benchmark.py over benchmarks/runtime_safety with the full Agent libOS runner, then collects metrics with collect_metrics.py. The public documentation identifies the M1 harness as an early deterministic workload; the submitted version should be paired with a public repository tag or archive that fixes the artifact state used for the reported run.
Acknowledgments The author used generative AI tools to assist with code development, manuscript organization, and language polishing. AI tools are not listed as authors. The author reviewed, revised, and is responsible for the technical claims, implementation claims, references, and final manuscript.
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. URL https://www.usenix.org/conference/ nsdi20/presentation/agache. [2] Huan ang Gao, Jiayi Geng, Wenyue Hua, Mengkang Hu, Xinzhe Juan, Hongzhang Liu, Shilong Liu, Jiahao Qiu, Xuan Qi, Yiran Wu, Hongru Wang, Han Xiao, Yuhang Zhou, Shaokun Zhang, Jiayi Zhang, Jinyu Xiang, Yixiong Fang, Qiwen Zhao, Dongrui Liu, Qihan Ren, Cheng Qian, Zhenhailong Wang, Minda Hu, Huazheng Wang, Qingyun Wu, Heng Ji, and Mengdi Wang. A survey of self-evolving agents: What, when, how, and where to evolve on the path to artificial super intelligence, 2026. URL https://arxiv.org/abs/2507.21046. [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. URL https://openreview.net/forum?id=m1YYAQjO3w. [4] Jack B. Dennis and Earl C. Van Horn. Programming semantics for multiprogrammed computations. Communications of the ACM, 9(3):143–155, 1966. doi: 10.1145/365230.365252. URL https://doi.org/10.1145/365230.365252. [5] D. R. Engler, M. F. Kaashoek, and J. O’Toole. Exokernel: An operating system architecture for application-level resource management. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles, pages 251–266. Association for Computing Machinery, 1995. doi: 10.1145/224057.224076. URL https://doi.org/10.1145/224057.224076. [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. URL https://arxiv.org/abs/2402.14034. [7] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world 11
Zhang
[24] 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. URL https://openreview.net/forum?id=ehfRiF0R3a. [25] Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, and Heng Ji. Executable code actions elicit better LLM agents. In Proceedings of the 41st International Conference on Machine Learning, volume 235 of Proceedings of Machine Learning Research, pages 50208–50232, 2024. URL https://proceedings. mlr.press/v235/wang24h.html. [26] Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, and Graham Neubig. OpenHands: An open platform for AI software developers as generalist agents. In The Thirteenth International Conference on Learning Representations, 2025. URL https://openreview.net/forum?id=OJd3ayDDoF. [27] Robert N. M. Watson, Jonathan Anderson, Ben Laurie, and Kris Kennaway. Capsicum: Practical capabilities for UNIX. In 19th USENIX Security Symposium (USENIX Security 10). USENIX Association, 2010. URL https://www.usenix.org/ conference/usenixsecurity10/capsicum-practical-capabilities-unix. [28] 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. URL https://openreview.net/forum?id=BAakY1hNKS. [29] Tianbao Xie, Danyang Zhang, Jixuan Chen, Xiaochuan Li, Siheng Zhao, Ruisheng Cao, Toh Jing Hua, Zhoujun Cheng, Dongchan Shin, Fangyu Lei, Yitao Liu, Yiheng Xu, Shuyan Zhou, Silvio Savarese, Caiming Xiong, Victor Zhong, and Tao Yu. OSWorld: Benchmarking multimodal agents for open-ended tasks in real computer environments. In Advances in Neural Information Processing Systems, volume 37, 2024. URL https://proceedings.neurips.cc/ paper_files/paper/2024/hash/5d413e48f84dc61244b6be550f1cd8f5-AbstractDatasets_and_Benchmarks_Track.html.
[30] 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. URL https://proceedings.neurips.cc/ paper_files/paper/2024/hash/5a7c947568c1b1328ccc5230172e1e7c-AbstractConference.html. [31] 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. URL https://openreview.net/forum?id=WE_vluYUL-X. [32] 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, 2024. doi: 10.18653/v1/2024.findings-acl.624. URL https://aclanthology.org/2024.findings-acl.624/. [33] Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, and Jeff Clune. Darwin godel machine: Open-ended evolution of self-improving agents, 2025. URL https://arxiv.org/abs/2505.22954. [34] Jiayi Zhang, Jinyu Xiang, Zhaoyang Yu, Fengwei Teng, XiongHui Chen, Jiaqi Chen, Mingchen Zhuge, Xin Cheng, Sirui Hong, Jinlin Wang, Bingnan Zheng, Bang Liu, Yuyu Luo, and Chenglin Wu. AFlow: Automating agentic workflow generation. In Y. Yue, A. Garg, N. Peng, F. Sha, and R. Yu, editors, International Conference on Learning Representations, volume 2025, pages 34040–34077, 2025. URL https://proceedings.iclr.cc/paper_files/paper/2025/file/ 5492ecbce4439401798dcd2c90be94cd-Paper-Conference.pdf. [35] Boyuan Zheng, Michael Y. Fatemi, Xiaolong Jin, Zora Zhiruo Wang, Apurva Gandhi, Yueqi Song, Yu Gu, Jayanth Srinivasa, Gaowen Liu, Graham Neubig, and Yu Su. SkillWeaver: Web agents can self-improve by discovering and honing skills, 2025. URL https://arxiv.org/abs/2504.07079. [36] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. WebArena: A realistic web environment for building autonomous agents. In The Twelfth International Conference on Learning Representations, 2024. URL https://openreview.net/forum?id=oKn9c6ytLx.
12