Introducing agentOS

Unix gave humans a common language to control machines. Today we're releasing agentOS to give agents the same power.

agentOS is a lightweight VM powered by WebAssembly and V8 isolates. Each agent gets its own POSIX-compliant filesystem, processes, and networking. The same isolation technology trusted by every Chrome tab on the planet, now purpose-built for AI agents. Fully open-source under Apache 2.0.

• Lightweight VMs: every agent runs in its own V8 isolate with a virtual POSIX kernel. No shared state, no cross-contamination. ~6 ms cold start compared to seconds for traditional sandboxes.
• 32x cheaper than sandboxes: the VM runs inside your Node.js process. No container overhead, no vendor account, no infrastructure to provision. Just npm install.
• Works with any agent: run PI today, with Claude Code, Codex, Amp, and OpenCode coming soon. Swap agents without changing your code.
• Host tools: expose your backend functions to agents as CLI commands inside the VM. Direct binding with near-zero latency. Automatic code mode for up to 80% token reduction.
• Mount anything as a filesystem: S3, Google Drive, host directories, or the default persistent filesystem. Up to 10 GB per agent, survives sleep/wake automatically.
• Multiplayer: multiple clients connect to the same agent in realtime. Stream session events, process output, and shell data to every observer.
• Hybrid sandboxes: agents run in the lightweight VM by default and can spin up a full sandbox on demand. The sandbox is mounted into the VM as a native filesystem directory, like mounting a hard drive. Use the VM for most work, the sandbox for browsers, native compilation, and desktop automation.
• Orchestration: workflows, queues, cron jobs, and multi-agent coordination. Schedule agents, chain them together, and build durable pipelines.

Show Me The Code

Boot a VM, create an agent session, and interact with the agent's filesystem.

const vm = agentOs({ options: { software: [common, pi] }, });

export const registry = setup({ use: { vm } }); registry.start();

```ts @nocheck client.ts
import { createClient } from "rivetkit/client";
import type { registry } from "./server";

const client = createClient<typeof registry>("http://localhost:6420");
const agent = client.vm.getOrCreate(["my-agent"]);

// Stream events as they arrive
agent.on("sessionEvent", (data) => {
  console.log(data.event);
});

// Create a session and send a prompt
const session = await agent.createSession("pi", {
  env: { ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY! },
});
const response = await agent.sendPrompt(
  session.sessionId,
  "Write a hello world script to /home/user/hello.js",
);
console.log(response);

// Read the file the agent created
const content = await agent.readFile("/home/user/hello.js");
console.log(new TextDecoder().decode(content));

Why Not Just Use a Sandbox?

Traditional sandboxes spin up a full Linux container for each agent. That means seconds of cold start, gigabytes of memory, and a network hop back to your backend for every tool call.

agentOS takes a different approach. The VM runs inside your Node.js process using V8 isolates and WebAssembly. Agents get a full POSIX environment without the overhead of a container. Your backend functions are exposed directly as CLI commands inside the VM, so there's no network round-trip, no API keys to inject, and no auth to configure.

When you need a real Linux kernel for browsers, compilation, or desktop automation, agentOS can spin up a full sandbox on demand and mount it into the VM as a native filesystem directory. The agent reads and writes sandbox files the same way it reads local files.

Host Tools

Host tools let you expose your backend directly to agents. Define a JavaScript function with a Zod schema, and it becomes a CLI command the agent can call from inside the VM.

import { agentOs, hostToolkit } from "rivetkit/agent-os";
import { setup } from "rivetkit";
import common from "@rivet-dev/agent-os-common";
import pi from "@rivet-dev/agent-os-pi";
import { z } from "zod";

const tools = hostToolkit("project", {
  listIssues: {
    description: "List open issues from the project tracker",
    args: z.object({
      status: z.enum(["open", "closed", "all"]).default("open"),
    }),
    handler: async (c, args) => {
      const issues = await fetchIssues(args.status);
      return issues.map((i) => `#${i.id}: ${i.title}`).join("\n");
    },
  },
  createPr: {
    description: "Create a pull request",
    args: z.object({
      title: z.string(),
      branch: z.string(),
    }),
    handler: async (c, args) => {
      const pr = await createPullRequest(args.title, args.branch);
      return `Created PR #${pr.number}: ${pr.url}`;
    },
  },
});

async function fetchIssues(status: string) {
  return [{ id: 1, title: "Fix login bug" }];
}
async function createPullRequest(title: string, branch: string) {
  return { number: 42, url: "https://github.com/example/repo/pull/42" };
}

const vm = agentOs({
  options: {
    software: [common, pi],
    toolkits: [tools],
  },
});

export const registry = setup({ use: { vm } });
registry.start();

The agent sees these as shell commands: agentos-project list-issues --status open. No MCP configuration, no auth handshake. Tool handlers run on the host with full access to your databases and services. The agent never sees the credentials, only the tool's input/output. Because tool calls are shell commands, agents can use code mode, reducing token usage by up to 80%.

Granular Security

agentOS is deny-by-default. No syscalls are bound until you explicitly configure them. Network access, filesystem mounts, and process spawning are all opt-in.

• V8 isolate boundary: no code escapes the isolate. The same sandboxing technology behind Google Chrome.
• Resource limits: configure maxMemoryMb and maxCpuPercent per agent.
• Network control: outbound requests are proxied through the host with configurable allowlists.
• Filesystem isolation: mount boundaries prevent symlink escape. Each agent is fully isolated.
• Permission system: agents request permission before tool use. Auto-approve in CI, or require human approval in interactive sessions.

Orchestration

Schedule agents on cron, process work through durable queues, and coordinate multi-agent pipelines with workflows.

• Cron: standard cron expressions. Run a shell command or start an agent session on schedule. Survives sleep/wake.
• Queues: durable, ordered message processing with backpressure. Feed webhooks from Slack or GitHub into an agent queue for serial processing.
• Workflows: durable multi-step pipelines with per-step retry. Crashes pick up where they left off.
• Agent-to-agent: agents communicate through host tools. No credentials in the VM. The host reads from one agent's filesystem and writes to another.

Use Cases

• Coding agents: full OS access, file editing, shell execution, tool use.
• Automated pipelines: clone repos, fix bugs, run tests, open PRs.
• Multi-agent systems: coordinators dispatching to specialized agents, review pipelines, planning chains.
• Webhook-driven agents: Slack bots, GitHub handlers, or any external event feeding into an agent queue.
• Scheduled maintenance: cron-based agents that audit code, update dependencies, or generate reports.
• Collaborative workspaces: multiple users observing and interacting with the same agent in realtime.
• Evals: near-zero cold start and low memory per instance make it cost-effective to run thousands of parallel evaluations.
• Background agents: long-running, asynchronous agents that work for hours without intervention. Persistent state means they pick up where they left off.

Open Source and Free

agentOS is Apache 2.0 licensed and free to self-host. It's just an npm package. Run it on your laptop, Railway, Vercel, Kubernetes, or on-prem. No vendor lock-in. For managed infrastructure, Rivet Cloud handles deployment and scaling.

Get Started

• agentOS documentation
• Quickstart guide
• GitHub
• Discord