I came across agentOS and ComputeSDK while looking at the same question: where should a coding agent run? They look like competitors because both execute code inside isolated environments.
The counterintuitive part is that agentOS can use ComputeSDK as its external sandbox. The relationship makes sense once you separate the agent’s durable state from the machines that run its code.
They look like competitors
agentOS and ComputeSDK both run code, but they operate at different layers. agentOS includes an isolated Linux VM with its own filesystem, process table, network policy, and V8 and WebAssembly executor.
That VM implements a focused Linux surface rather than a full distribution. 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.
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.
ComputeSDK standardizes the sandbox interface; it does not own the application lifecycle. The application must install a provider adapter and supply its credentials, handle API and network failures, and destroy the sandbox before it becomes an idle cost. Its files only last for the sandbox lifetime unless the application copies them somewhere durable.
The quickstarts make the boundary concrete. ComputeSDK calls compute.sandbox.create() and later sandbox.destroy(). agentOS calls getOrCreate("my-agent") and opens a durable session. The first API centers a sandbox resource; the second centers an actor that can use one.
Boundary
Which lifetime do you need?
A turn can need both
Imagine an agent that needs to inspect a website, change some code, and run a native build. The conversation belongs to the agent session, but the browser and toolchain belong to a machine created for that work.
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 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.
Name both compute layers
agentOS owns persisted actor state and the session that can be reconstructed from it. The external sandbox owns provider-hosted compute for as long as the workload needs it.
| Concern | agentOS actor and VM | External sandbox |
|---|---|---|
| Identity | Named actor, sessions, history, and permissions | Sandbox ID for one environment |
| Lifetime | The VM may sleep; persisted actor state survives | Until the application destroys it or its timeout expires |
| State | Durable files, session configuration, and completed history | Mounted files, live processes, ports, and working state |
| Capability | Focused Linux surface with V8, WebAssembly, and registered tools | Full Linux; browsers, compilers, and GPUs when the provider supports them |
| Trust | Runtime, durable storage, and host bindings | Provider isolation, images, credentials, and network |
Sleep does not freeze the agent
agentOS preserves selected files, session configuration, completed history, and permission bookkeeping across sleep. It does not preserve live commands or agent processes. Waking an actor reconstructs a safe continuation from durable state; it does not resume a frozen computer.
The external sandbox adds capabilities
Both layers run code, which is where the architecture can become confusing. The agentOS VM is the focused environment inside the application host. The selected provider runs the external full Linux sandbox. ComputeSDK is the interface between them, not the machine itself.
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 bridge needs its own policy
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.
The integration needs an explicit policy for which actor may create a sandbox, which credentials enter it, what network it can reach, and which files may return. Each system can enforce its own boundary, but the application owns what crosses between them.
Continuity also accumulates 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.
Choose by what needs to survive
For one bounded job, ComputeSDK and a sandbox provider can be the whole architecture. For identity, files, and completed history across requests, use agentOS. When the same 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.
The agent can outlive every machine it uses.