Isolation is the easy half of the sandbox problem

When we built AgentBox v1 and launched it two months ago, we designed it with a person in the loop. A person creates an environment, waits for it to become ready, enters it, and works inside it.

Version 2 is designed around a different caller: it gives an agent a machine it can command through an API. Each workload now runs inside a microVM with its own guest kernel. Stronger isolation is the first step, yet an autonomous agent also needs reliable lifecycle states, clear results, and retries that won't accidentally run the same operation twice. This is the harder half of the sandbox problem we are targeting in v2.

What changes when the caller is an agent

Two problems in v1 made the difference clear.

First, creating an environment crossed nine orchestration boundaries before it became available. That execution path was designed around an interactive workflow, not a caller coordinating many operations through an API.

Second, retries could hide repeated side effects. In one retry sequence, the same command ID returned the same execution ID three times, creating the appearance of one logical execution. Underneath, the command ran three times.

A person might notice the duplicated output. An unattended agent may continue as if the command ran only once — after writing the same file again, triggering the same deployment again, or performing another action that cannot be cleanly reversed.

Both problems pointed to the same conclusion: an agent sandbox needs more than a secure place to execute code. It needs a machine boundary and an API contract designed for autonomous callers. That is what we rebuilt in AgentBox v2.

Each runtime gets its own kernel

Every v2 workload runs inside a microVM with its own guest kernel. From the workload's point of view, the machine looks like this:

┌──────────────────────────────────────────────┐

│ Workload                                     │

│ Image, startup command, files, services,     │

│ and commands                                 │

├──────────────────────────────────────────────┤

│ Guest kernel                                 │

│ This runtime's processes, filesystem,        │

│ and network stack                            │

├──────────────────────────────────────────────┤

│ Virtual machine monitor                      │

│ Boots, isolates, and destroys the machine    │

├──────────────────────────────────────────────┤

│ Host                                         │

│ Physical compute, storage, and networking    │

└──────────────────────────────────────────────┘

The workload interacts with its own guest kernel. Hardware-assisted virtualization separates that guest from the host and other runtimes.

This gives each workload a machine-level boundary for running untrusted or agent-generated code. It also gives AgentBox a runtime that can be created, observed, suspended, resumed, and deleted as one independently managed machine.

But microVM isolation does not answer the operational questions an agent depends on:

• What does Running guarantee?

• What happens when a request times out but the operation may still be in progress?

• Can retrying a command execute it twice?

• Can a late response revive a runtime after deletion has been accepted?

• When does usage metering stop?

• Do API commands and terminal sessions follow the same identity policy?

Those guarantees must come from the platform around the machine.

One contract around the runtime

Every v2 runtime is a microVM. Infrastructure details stay behind AgentBox's APIs. What an agent programs against is the contract AgentBox owns around each runtime: identity, lifecycle, policy, commands, files, logs, and usage.

An agent works in a loop:

Authenticate → Create → Running → Upload → Exec

     → Result / Logs → Download → Delete → Final usage

Our first v2 release supports that loop end to end, and there are three promises central to it.

Running means usable

In v2, Running is not merely an observation about lower-level infrastructure. It is an AgentBox API state. If the API reports that a runtime is Running, the runtime is ready to accept commands. There should not be a separate interval in which the machine appears ready but exec cannot yet be used.

Agents should not need an extra polling loop to discover whether a supposedly ready runtime is actually usable.

Results are machine-readable

Every completed command returns stdout, stderr, and an exit code. A person can often inspect a line of output and infer whether something worked. An agent needs an explicit result it can use to choose its next action.

The first v2 release returns one completed result per call. Streaming command output will follow in a later release.

Every access path follows one identity boundary

An organization's identity comes from its authenticated API key, never from an organization value supplied in the request. Runtimes do not expose a separately authenticated SSH service or require customers to manage long-lived SSH credentials. When interactive terminal access is enabled, it is established through the authenticated AgentBox control plane.

This gives commands and terminal sessions the same access model. Every supported path into a runtime can be authenticated, attributed to a caller, and audited.

Preparing environments before they are needed

In v1, a create request passed through a long orchestration path before the environment became available. In v2, we changed when environment preparation happens.

Pulling an image and preparing its dependencies now happen when a builder registers or updates a template. Each template change produces an immutable version. A version that has finished preparing becomes ready for activation. Publishing it is a single activation step, and rollback means activating an earlier ready version. By the time an agent requests a runtime, its environment has already been prepared. Runtime creation no longer means rebuilding that environment on the critical path.

The result, measured over the public network in internal testing this July:

The gap between those two rows is the interesting one. About 60 milliseconds separate the API returning from the runtime being ready to accept commands. In v1, that gap was where image pulls and dependency preparation happened, and it was measured in seconds.

Under burst the path still degrades, and we would rather say so than round it off. A wave of 128 concurrent cold creates completed 128 of 128, and the whole wave finished in 5.4 seconds, but p95 create-to-Running rose from 0.26 s to just under 4 s. Image preparation is not what causes that, because v2 moved it off the create path entirely. What remains is our own orchestration cost, and reducing it is the next piece of work.

Our goal is that environment creation has no user-visible impact at agent concurrency, where hundreds of tasks starting together without the platform becoming the bottleneck.

Separately, a pilot deployment has held 50,000 runtimes alive at the same time. That is a steady-state count rather than a creation rate, and the two numbers should not be read against each other.

Templates were already central to AgentBox v1: builders publish them, and enterprises provision runtimes from them on demand. That product model remains intact. The registry, templates, the marketplace, IAM, billing, and the console continue to work around the new runtime architecture. Builders do not need to relearn the product to benefit from the new execution model.

Making command retries safer

We find that a stable execution ID is not enough. If an API returns the same identifier while the underlying command runs multiple times, the identifier hides the duplicate instead of preventing it.

In v2, we did it differently: the caller's request_id is the idempotency boundary for command submission. A uniqueness constraint in the AgentBox control plane ensures that the same request_id is accepted for execution at most once. The guarantee is enforced at command submission, inside the path AgentBox owns.

Command timeouts also have explicit semantics. When a command reaches its configured execution timeout, AgentBox terminates the process group, preserves the output produced so far, and records the result as timed_out with a termination reason. The runtime itself remains Running, so the agent can inspect the result and decide what to do next.

This guarantee is deliberately narrow: one request_id is accepted for execution at most once. It does not imply that every external side effect produced by arbitrary code can be made transactional. If a command calls an external API, writes to an external database, or triggers a deployment, that external system still needs its own idempotency strategy.

We believe the sandbox should make its own behavior precise without pretending it can control every system the workload touches.

Lifecycle operations follow a separate rule

Commands and lifecycle changes operate differently. Create, suspend, resume, snapshot, and delete change the runtime itself, so AgentBox allows only one lifecycle mutation to be active for a runtime at a time. Commands do not take that lifecycle lock. An agent can continue using a running machine without placing every execution into the same serialized workflow.

The distinction matters most when operations overlap. An agent may request deletion while creation is still in flight, and the create result may land after AgentBox has already accepted the delete.

In v2, deletion intent is durable. Once AgentBox accepts and records it, a late create or resume response cannot return the runtime to Running. The lifecycle continues toward deletion. This prevents a late-completing create or resume from reviving a runtime the customer has already asked AgentBox to remove.

You stop paying when you say delete

Deletion creates two related but distinct timestamps: the billing boundary and the infrastructure-release confirmation.

The billing boundary is the moment the deletion request is accepted and durably recorded. The acceptance time becomes the cutoff used for usage accounting, and the stop-metering event is emitted only after the underlying resource has been confirmed to release. Even if delivery is delayed or retried, the event retains the original deletion-acceptance time.

Time spent waiting for release confirmation is treated as provisional and is not invoiced, which is an intentional separation. Emitting a success event before infrastructure release would create a false record of cleanup. Waiting until release to define the billing cutoff would charge the customer for delay caused by the platform.

AgentBox waits for confirmed release before declaring cleanup complete, while preserving the accepted delete time as the customer's billing boundary.

What remains shared

Giving every runtime its own guest kernel does not mean every layer of the platform is physically dedicated. Depending on deployment, runtimes may still share physical hosts, a hypervisor, storage systems, network infrastructure, image distribution, and parts of the AgentBox control plane.

The isolation boundary comes from giving every runtime its own machine boundary, identity, filesystem view, network policy, and authorized path in. A large share of the v2 work went into making those shared platform services behave as though every runtime were an independently managed machine, especially when operations overlap or fail halfway through.

What ships next

Three capabilities are not included in the first v2 release: streamed command output, suspend, and snapshot. Suspend and snapshot will follow in a later release, together with Endpoints: a stable HTTPS URL for each runtime, private by default.

• Suspend keeps the runtime ID and disk, but does not preserve memory, running processes, or live connections.

• Resume performs a fresh boot, and the runtime's startup command runs again.

  

• A snapshot is an immutable copy of the filesystem. It does not include memory, process state, live connections, or temporary credentials. Creating ten runtimes from one snapshot produces ten independent runtimes.

  

For existing builders, current deployments remain unchanged until they are migrated. Templates survive runtime deletion. Terminate becomes Delete with the lifecycle semantics described above, and Open Shell becomes Run Command. We are still finalizing the migration schedule and will share it before existing deployments are affected.

Isolation is where the sandbox begins

AgentBox v2 gives every workload its own kernel, a visible architectural change. The deeper change is the contract around the machine. An autonomous agent needs to know that Running means usable, a result includes an exit code, the same request_id will not be accepted for execution twice, and an accepted deletion cannot be reversed by a late infrastructure response.

Isolation limits what a workload can reach. Clear lifecycle, timeout, identity, and retry semantics determine whether an agent can trust the sandbox when nobody is watching.

AgentBox v2 is entering private beta ahead of general availability. If you run code you did not write, or build agents that operate unattended, we would like you to help test it: https://discord.gg/mbYhCJSbF6