AI Agent Workspaces

Patterns for giving every AI agent its own computer with agentOS: one Rivet Actor per agent that owns a portable, lightweight in-process OS running on Wasm and V8. Use it for code interpreters that keep state between runs, agents that ship artifacts behind shareable preview URLs, per-user dev environments, and scheduled maintenance agents. agentOS is in preview and the API is subject to change.

This entry is about giving an agent a workspace. For conversation memory, message queues, and streaming chat patterns, see AI Agent.

Starter Code

The agent-os collection is reference code, one sub-example per capability; treat it as patterns to copy into your project rather than a turnkey app. The agent-os-e2e example is the complete end-to-end walkthrough.

Setup

The whole backend is one registry with one agentOs() actor:

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

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

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

See the Quickstart for the client side and project layout.

Workspace Model

• One actor per workspace, key as identity. client.vm.getOrCreate(["my-agent"]) gives each agent its own workspace; key by user id for per-user dev environments. Each workspace has its own filesystem, processes, and networking with no shared state and no cross-contamination (see the overview).
• Software packages choose what is installed. agentOS starts with no commands installed. The software option installs packages such as @rivet-dev/agent-os-common (a meta-package of Wasm command-line tools: coreutils, sed, grep, gawk, findutils, diffutils, tar, and gzip), @rivet-dev/agent-os-git (git), and @rivet-dev/agent-os-pi (the Pi coding agent). See Software.
• The VM boots lazily and sleeps when idle. The first action boots the VM (clients see a vmBooted event); when nothing is active, the actor sleeps and broadcasts vmShutdown, then wakes on the next action.

What survives a sleep/wake cycle (see Persistence):

The actor holds itself awake while sessions, processes, shells, or hooks are active, then sleeps after a grace period.

Capability Tour

Two details worth knowing up front:

• createSignedPreviewUrl returns a relative path plus the token and expiry. Build the full URL with the client handle's getGatewayUrl() method; it is a client method, not an actor action.
• Schedule cron jobs through the actor with the exec and session action types only. Callback cron actions are defined in server code and do not serialize through listCronJobs.

Driving a Coding Agent Session

Only the Pi agent (@rivet-dev/agent-os-pi) is currently supported as a session agent; Amp, Claude Code, Codex, and OpenCode are coming soon. See Sessions.

1. createSession("pi", { env: { ANTHROPIC_API_KEY } }) returns a sessionId. The VM does not inherit the host process.env, so API keys are passed explicitly per session or kept server-side through the LLM gateway.
2. Open a realtime connection and subscribe to sessionEvent to stream the agent's output, such as message chunks, as it works.
3. sendPrompt(sessionId, ...) starts a turn; cancelPrompt stops one in flight.
4. When the agent asks to use a tool, clients receive a permissionRequest event and answer with respondPermission, or the server auto-approves with the onPermissionRequest config hook (see Permissions).
5. Transcripts are persisted automatically in the universal transcript format (Agent Communication Protocol, ACP). After sleep, resumeSession continues a session in the rebooted VM, and listPersistedSessions plus getSessionEvents read history without booting the VM at all.

Host Tools

Expose your backend functions to the agent as CLI commands inside the workspace. Define a toolkit with toolKit() and hostTool() (Zod-schema'd JavaScript functions on the host), pass it via agentOs({ options: { toolKits: [...] } }), and it is installed as a command such as agentos-weather forecast --city Paris --days 3 and injected into the agent's system prompt. The agent calls your backend with no HTTP endpoints or MCP servers to stand up, and CLI-shaped tools are code mode compatible for large token savings. See Tools and the tools example.

When to Mount a Full Sandbox

agentOS is not a replacement for sandboxes; it is designed to work alongside them. When a workspace needs native binaries, browsers, compilation, or desktop automation, use sandbox mounting: start a Docker-backed sandbox with SandboxAgent.start({ sandbox: docker() }), project its filesystem into the VM as a native directory (for example /sandbox) with createSandboxFs, and expose sandbox process control as host tools with createSandboxToolkit. Filesystem actions like writeFile and readFile project transparently through the mount while heavy workloads run in the container.

See Sandbox Mounting for the hybrid model and agentOS vs Sandboxes for when each side wins: the lightweight VM has a near-zero cold start (~6 ms) and installs with npm install, while sandboxes are full Linux environments billed per second of uptime.

Architecture

Actors

• Key: vm[workspaceId], for example client.vm.getOrCreate(["my-agent"])
• Responsibility: Owns one workspace. Boots the VM lazily on the first action, serves all capability actions, proxies signed preview URL requests into the VM's virtual network, and persists sessions and tokens to actor SQLite.
• Actions (grouped; the most load-bearing of each area)
  • Filesystem: readFile, writeFile, mkdir, readdir, readdirRecursive, stat, exists, move, deleteFile
  • Processes: exec, spawn, writeProcessStdin, waitProcess, listProcesses, killProcess
  • Shells: openShell, writeShell, resizeShell, closeShell
  • Network: vmFetch, createSignedPreviewUrl, expireSignedPreviewUrl
  • Cron: scheduleCron, listCronJobs, cancelCronJob
  • Sessions: createSession, sendPrompt, cancelPrompt, respondPermission, resumeSession, closeSession, destroySession, listPersistedSessions, getSessionEvents
• Queues
  • None
• Events
  • vmBooted
  • vmShutdown
  • sessionEvent
  • permissionRequest
  • processOutput
  • processExit
  • shellData
  • cronEvent
• State
  • SQLite
  • agent_os_sessions and agent_os_session_events (session metadata plus seq-ordered transcript events)
  • agent_os_preview_tokens (signed preview URL tokens with expiry)
  • agent_os_fs_entries (file content for database-backed mounts)

Lifecycle

sequenceDiagram
	participant C as Client
	participant A as vm actor
	participant V as agentOS VM
	participant P as Pi session

	C->>A: getOrCreate(["my-agent"])
	C->>A: writeFile("/tmp/hello.txt", ...)
	Note over A,V: first action boots the VM
	A-->>C: vmBooted
	C->>A: exec("echo hello | tr a-z A-Z")
	A->>V: run command
	V-->>A: {exitCode: 0, stdout}
	C->>A: spawn("node", ["/tmp/server.mjs"])
	C->>A: createSignedPreviewUrl(8080, 60)
	A-->>C: {path, token, expiresAt}
	C->>A: fetch(gatewayUrl + path)
	Note over A: token checked in SQLite, request proxied into the VM network
	C->>A: createSession("pi", {env})
	A->>P: start session
	C->>A: sendPrompt(sessionId, ...)
	loop streamed agent output
		P-->>A: agent event
		A-->>C: sessionEvent
	end
	Note over A: idle, sleeps after grace period (vmShutdown)
	C->>A: resumeSession(sessionId)
	Note over A,V: wake reboots the VM, restoring transcripts, preview tokens, and persistent mounts

Security Checklist

• Authenticate connections: Add the onBeforeConnect hook in the agentOs() config so only authorized callers reach a workspace. Signed preview URL requests deliberately skip it because the token is the credential; browsers navigating a preview URL cannot supply actor connection params.
• Gate agent tool use with permissions: Session permission requests broadcast as permissionRequest events for human-in-the-loop approval via respondPermission, or run a server-side onPermissionRequest policy for automated pipelines. See Permissions.
• Treat preview URLs as bearer credentials: Tokens are randomly generated 32-character values with a default expiry of 1 hour and a maximum of 24; revoke early with expireSignedPreviewUrl. Preview responses carry permissive CORS headers, so do not serve private data on a preview port without app-level auth.
• Keep LLM credentials off the browser: Create sessions from trusted server code with the key in createSession env, or keep keys entirely server-side with the LLM gateway. Session keys are injected into the session environment inside the VM and are never stored in actor config or SQLite.
• Treat mounted sandboxes as their own trust boundary: A mounted sandbox is a full Linux environment outside the workspace's Wasm and V8 isolate. Scope what its network and filesystem can reach before projecting it into an agent's VM.
• Set resource and cost limits: Cap per-workspace memory and CPU (maxMemoryMb, maxCpuPercent, see Security). Active sessions, processes, and shells hold the actor awake, so add per-workspace session caps and token budgets as a recommended extension.