agentOS

Rivet's open-source WebAssembly-backed runtime for running and orchestrating AI agents with a lightweight in-process VM, a sandboxed filesystem, and deploy routes to local, self-hosted, or Rivet Cloud environments.

What it is

agentOS is Rivet's attempt to move part of the agent runtime below the harness and above raw containers: a portable, WebAssembly-backed environment where agents can execute commands, hold files, enforce permissions, and coordinate workflows without paying the startup and memory cost of a full Linux sandbox. The launch artifact frames v0.2.0 as "faster, lighter, cheaper than a sandbox," with benchmark claims around cold start, memory, and run cost. Treat those as vendor claims until reproduced on Kevin's workloads. Source: X/@rivet_dev and local video review, 2026-07-04

The repo and docs position it as an open-source "OS for AI agents" that can run built-in ACP-style agents such as Pi, Claude Code, and OpenCode, or a bring-your-own agent. The runtime emphasizes near-zero cold starts, deny-by-default permissions, embedding inside a backend process, and deployment to local infrastructure, self-hosted servers, or Rivet Cloud. Source: rivet-dev/agentos README and docs, 2026-07-04

Routing

Use agentOS when existing software needs a shell, paths, process semantics, common commands, Node/Python, mounts, or a persistent virtual filesystem, but the job does not require arbitrary native Linux software. Use named host bindings or Code Mode first for bounded API/data operations; agentOS is the middle OS-interop tier, not the minimum interface for every tool call.

Do not treat it as a replacement for every agent sandbox. Full microVM or container sandboxes still win when the workload needs browser automation, native packages, long-running dev servers, kernel-level isolation, or hostile untrusted code. The useful distinction is:

Need Prefer
Bounded service/API calls, transformations, or named filesystem actions Typed host binding, deterministic CLI, or Code Mode executor
Shell/POSIX compatibility over a controlled command and runtime set agentOS
Arbitrary native binaries/package managers, Docker, browser/GUI, heavy toolchains, GPU/hardware, kernel features, or file watching Vercel Sandbox, E2B Code Sandboxes, Dedalus Machines, or another full worker
Mostly virtual-OS work with one unsupported operation agentOS plus an on-demand mounted sandbox; record the escalation
Provider-agnostic substrate routing ComputeSDK or higher-level product routing

Current source snapshot

As of 2026-08-12, rivet-dev/agentos remains Apache-2.0 and is checked at 44a6c8022f26ef0edd56e3d224f8296ee6387232, with 4,364 stars, 1,048 detected tests, five workflows, and eight skill files. The latest stable release and npm package are v0.2.15 / @rivet-dev/agentos@0.2.15; the current prerelease tag is 0.2.16-rc.2. The repository contains a substantial test surface, but no Kevin-workload benchmark or hostile-workload security reproduction was run in this review. Source: commit-pinned repository receipt and npm snapshot, 2026-08-12

Execution surface and limits

Current source describes a trusted sidecar that owns a per-VM virtual kernel, filesystem, process/socket tables, PTYs, permissions, and DNS. Guest JavaScript runs in V8 isolates; compiled tools run as WebAssembly; host capabilities enter through explicit bindings or mounts. That is a real enforcement design, but the project also states that its security model is beta and under review. Internet- facing hosts still need hardened deployment, scoped permissions, resource limits, authentication, and one-VM-per-risk-unit blast-radius decisions. Source: agentOS Architecture and Security Model, reviewed 2026-08-11

The portability boundary is concrete. The registry supplies cross-compiled software, but arbitrary downloaded native binaries and ordinary Linux package managers are unavailable. Docker, kernel modules/eBPF, inotify/fs.watch, GPUs, USB, and other hardware require a full environment. Sandbox mounting is therefore an intentional escalation route: keep the agent and bindings in the virtual OS, mount a full worker for the unsupported operation, and expose its process surface through named bindings. Source: agentOS Limitations and Sandbox Mounting, reviewed 2026-08-11

Secure Exec relationship

The author thread separates Code Mode/tool calling from OS interop and describes Secure Exec as the pure-JavaScript surface sharing agentOS's core. That distinction is useful; a second independent Kevin-Wiki tool owner is not. At captured commit 4fe4de169e36a724ca2d270c3168fd80e53c4eed, the rivet-dev/secure-exec repository explicitly identifies itself as a generated compatibility mirror: TypeScript packages re-export agentOS runtime packages and Rust crates re-export agentOS crates. secure-exec@0.3.3 remains a published Apache-2.0 API, but route it as a specialized Code Mode/Node package over this owner rather than installing both runtimes or duplicating their architecture. Source: X author thread; frozen Secure Exec repository and npm registry, reviewed 2026-08-11

Code Mode's durable pattern is one isolated execution tool invoking validated, named host bindings. Binding handlers keep credentials and ambient authority on the trusted side and return only structured results. It can reduce schema and round-trip overhead, but every binding still needs per-action policy, input and output limits, audit, and approval semantics. Source: Secure Exec Code Mode, reviewed 2026-08-11

Harness-outside-sandbox integration

The current Flue integration makes the architectural split concrete. Flue owns the agent runtime and session lifecycle; Rivet maps each agent instance and workflow run to a durable actor and SQLite database; agentOS provides a separate isolated VM with a persistent /workspace. Prompts are durably admitted before background execution, and reconnecting to the same context reaches the same VM actor and filesystem. In this arrangement, agentOS is the execution substrate, not the canonical agent history or policy owner. Source: Rivet Flue beta documentation; agentOS Flue documentation, reviewed 2026-08-10

This is useful evidence, not a default install decision. The integration is explicitly beta, currently depends on Rivet preview packages and a Rivet Flue fork while extension APIs are proposed upstream, and does not support Cloudflare Workers. Keep it as a reference implementation for durable admission, actor-owned loop state, and replaceable VM execution until API stability, portability, failure recovery, and latency are reproduced locally.

Why Kevin should care

agentOS is the WebAssembly/in-process counter-position to the Persistent Sandbox Thesis: instead of assuming every useful agent needs a full remote computer, it asks how much work can be moved into a smaller, cheaper, faster resident VM. That does not invalidate the "agents need computers" thesis. It sharpens the routing boundary: some agents need a durable machine; some need a fast, permissioned runtime with enough filesystem and process semantics to behave like one.

The original article's 47× RAM comparison and categorical “virtual OS is more secure” claim remain vendor hypotheses. Memory density depends on workload, isolation granularity, hardware, and reuse strategy; the current documentation itself calls for local measurement and says the security model is still under review. Likewise, its “no special fault tolerance” paragraph is superseded by the later harness-outside-sandbox evidence: durable admission, retries, cancellation, history, approvals, audit, and recovery remain external control-plane responsibilities even when execution is cheap and in-process.


Timeline

  • 2026-08-11 | Deep-reviewed the original virtual-OS article, complete author thread, child artifact, current agentOS/Secure Exec repositories, npm packages, security/limitations docs, and sandbox-mount route. Added the capability → virtual OS → full worker ladder; treated Secure Exec as a compatibility/API surface; and held blanket cost, security, and fault-tolerance claims behind local proof. Source: X 2071672946859688352; frozen primary artifacts
  • 2026-08-10 | Added the current Flue beta as a concrete harness-outside-sandbox reference: Flue owns runtime/session state, Rivet actors own durable admission and SQLite, and agentOS owns the isolated persistent workspace. Held adoption on beta/fork/runtime constraints and local recovery proof. Source: Rivet and agentOS Flue documentation, reviewed 2026-08-10
  • 2026-07-04 | Page created from the Rivet agentOS v0.2 bookmark review. Source snapshot recorded GitHub repo health, release channel, npm versions, and the launch video's benchmark/product-positioning claims. Source: X/@rivet_dev, GitHub, npm, local artifact review, 2026-07-04
  • 2026-06-25 | Rivet launched agentOS v0.2.0, framing it as a lightweight WebAssembly sandbox and orchestration layer for Pi, Claude Code, Codex, OpenCode, bring-your-own agents, multiplayer workflows, and one-prompt deploys. Source: Rivet changelog, 2026-06-25