Enduring agents, disappearing machines

I went looking for the correct box to put a coding agent in. I found two boxes, then learned that one box can mount the other.

The boxes are agentOS and ComputeSDK. Both execute code inside isolated environments, so I first read them as competing answers. Then I found that agentOS can use ComputeSDK as its external sandbox. agentOS stores the actor and session while ComputeSDK asks a provider for the machine a task needs. They solve different parts of the same system.

The actor and its sandbox

agentOS includes an isolated Linux VM with its own filesystem, process table, network policy, and V8 and WebAssembly executor. ComputeSDK gives an application common calls for creating and controlling a provider’s sandbox. They overlap at “run code.” Nearly everything around that verb belongs to a different layer.

The agentOS VM implements a limited Linux environment. Its documented limitations include installing arbitrary binaries or using package managers such as apt, Docker and eBPF, file watching, and direct GPU or hardware access. The built-in VM has clear limits. Check them before asking it to run a browser or use a GPU.

When a workload needs a browser, native compilation, or another full Linux capability, agentOS can mount an external sandbox on demand. ComputeSDK is one of the supported adapters for that sandbox. In that setup, agentOS manages the actor and session while ComputeSDK gives it one API for asking the selected provider to provision the heavier environment. The external machine handles work that the built-in VM cannot.

ComputeSDK standardizes the sandbox interface. The application owns the lifecycle: it must install a provider adapter and supply its credentials, handle API and network failures, and destroy the sandbox before it becomes an idle cost. For ephemeral providers, files normally last only for the sandbox lifetime. Providers with persistent filesystems or snapshots can preserve them. The API can standardize the machine. It cannot remember to stop billing itself.

The ComputeSDK quickstart calls compute.sandbox.create() and later sandbox.destroy(). The agentOS quickstart calls getOrCreate("my-agent") and opens a durable session. The calls return different things: a sandbox ID from ComputeSDK and a named actor from agentOS. One answer is an environment. The other answer expects to meet you again.

A turn can need both

A coding agent may need to inspect a website, change some code, and run a native build. This is one turn with three jobs. The conversation stays with the agent session. A separate machine supplies the browser and native toolchain.

agentOS wakes the named actor and reconstructs the session from persisted state. When the turn needs capabilities outside its focused VM, the configured sandbox extension starts an external environment through ComputeSDK and the selected provider. The durable actor starts a separate machine for the work.

The external sandbox runs the browser, commands, and build, and its filesystem is mounted inside the agentOS VM. Before teardown, the agent must copy any results it wants to keep into durable agentOS storage. The sandbox can then disappear while the actor’s identity, configuration, and completed history remain available. Forget the copy, and teardown becomes an extremely reliable deletion feature.

What each layer owns

Sleep rebuilds the VM from stored state

Across sleep, agentOS stores selected files, session configuration, completed history, and permission bookkeeping. When the actor wakes, it boots a fresh VM and reconstructs the session. Live commands and agent processes end. This resembles reincarnation through SQLite, except the running processes do not participate.

The external sandbox adds capabilities

The first-party sandbox-mounting extension starts an external sandbox through the configured provider, projects its filesystem into the actor VM, exposes remote process controls, and destroys the sandbox with the VM. Durable actor files, session metadata, and completed history remain available when agentOS reconstructs the session later. The external machine leaves. The work record stays.

Update, August 2026: four things can survive

Recent coding agents made the noun “state” too small for the job. There are at least four things we may want to survive. A work record includes the conversation, task, pushed branch, and review trail. An environment recipe defines setup scripts, images, dependency rules, and credential policy. Retained workspace state holds files and other in-progress work between sessions. Execution state covers the running machine, processes, memory, and network connections. Call all four “state,” and eventually someone preserves the wrong one with tremendous confidence.

Capy stores a durable thread with its conversation, machines, tasks, and pull requests. Its machine identity can survive a replacement VM. When a Capy machine sleeps, its filesystem stays while its memory, processes, and network connections end. Any filesystem work not pushed through Git can be lost when Capy deletes the machine. The thread record remains. Git is not merely version control here. It is the marked exit.

Grok Build reaches the same boundary on a developer’s computer. It keeps resumable session records, and parallel subagents can work in separate persistent worktrees until the user removes them. A resumed session can also start in a fresh worktree. The boundary survives even when the machine is the one already under your desk.

The word “snapshot” also names different contracts, which is a calm way to give one noun several incompatible jobs. GitHub Copilot can stop a cloud sandbox and retain its files, environment variables, and in-progress work. GitHub meters that saved state separately from active compute. A Devin environment snapshot is a clean template: each session starts from a fresh copy and its changes do not flow back into the snapshot. Same word. Different escape plan.

Parallel cloud agents multiply environments. Each separately provisioned cloud environment needs isolated credentials, network policy, cleanup, and a reliable way to collect its changes. ComputeSDK can supply external environments. agentOS can keep a named actor across tasks. A pushed branch or pull request may hold enough work state when the product does not need a durable actor. Every new environment arrives with its own credential, network, and cleanup rules.

Set policy at the integration boundary

agentOS describes its security model as beta and still undergoing review. Within that model, its threat model places its virtual kernel, sidecar, and approved host bindings inside the trusted system. The selected sandbox provider remains responsible for the external environment’s isolation, images, credentials, and network policy. Mounting one box inside another does not merge their threat models by magic.

The application must decide which actor may create a sandbox, which credentials enter it, what network it can reach, and which files may return. That policy decides what crosses between the two systems.

The durable SQLite database can contain sensitive state. The persistence documentation says each actor VM’s SQLite database is trusted plaintext and may contain credentials, prompts, messages, and permission payloads. Database and backup access should therefore be treated as access to the agent’s secrets and history. “Durable” is good news until the durable object is a plaintext collection of everything interesting.

Choose by what needs to survive

For one bounded job, an application can create a sandbox through ComputeSDK, run the work, save its output, and destroy the sandbox. Use agentOS when the same named agent needs identity, files, and completed history across requests. If that agent also needs a browser, native toolchain, GPU, or another provider-specific capability, configure an external sandbox and copy durable outputs back before disposing of it. Keep the actor. Rent the machine. Remember which box contains the thing you wanted.