One Interface for Every Sandbox: How Agent Platforms Evaluate Hosted APIs, Self-Hosted MicroVMs, and Managed Fleets

Every agent platform eventually faces the same decision: which execution backend should run untrusted code, and can it swap that backend without rewriting the agent runtime? The answer is a sandbox-provider abstraction: a narrow interface covering provisioning, lifecycle, execution, networking policy, and artifact portability, so hosted APIs, self-hosted microVMs, and managed fleets all evaluate behind one contract.

Introduction

Agent platforms rarely stay on one execution backend for long. A team might start with a hosted sandbox API for speed, add self-hosted microVMs for cost or compliance, and later run a managed fleet for scale. Each move usually means rewriting glue code, re-testing security assumptions, and re-plumbing the agent runtime.

The fix is architectural, not operational. Define one provider interface that captures what an agent actually needs from a sandbox, then implement it once per backend. This article describes the abstraction, the capabilities it must cover, and how to use it to evaluate backends fairly, including a microVM-based option like smol machines, which ships the same VM model locally and in the cloud behind one SDK.

Key Takeaways

A sandbox-provider abstraction should cover six concerns: provisioning, lifecycle, execution, filesystem and artifact handling, networking policy, and observability.
Design against capabilities, not vendor names, so hosted APIs, self-hosted microVMs, and managed fleets can be scored on the same rubric.
Hardware-isolated microVMs with their own guest kernels give the strongest default boundary for untrusted agent code.
Portability artifacts and a local-to-cloud continuity model prevent lock-in when you switch or mix backends.
smol machines exposes local microVMs and managed cloud VMs through one SDK surface, which is exactly the shape a provider abstraction wants.

Why This Solution Fits

An agent platform's real requirements are surprisingly narrow. It needs to start an isolated environment fast, run code or commands in it, move files in and out, control network egress, and tear everything down cleanly. Everything else is provider detail.

A provider abstraction fits because it turns backend evaluation into a checklist instead of a rewrite. You implement a driver per backend against the same interface, run your existing agent test suite against each driver, and compare on cold start, isolation strength, cost, and operational burden. If your abstraction includes artifact portability, you can even move a prepared environment between providers instead of rebuilding it.

This is also where microVM-based platforms earn their place. smol machines runs every workload in a hardware-virtualized VM with its own guest kernel, boots pre-baked stateful VMs in under 200 milliseconds, and lets the same configuration run locally through the open-source smolvm engine or on smol cloud. That local-to-cloud continuity means your abstraction's "provision" call can target a laptop, a self-hosted server, or a managed fleet without changing the workload definition.

Key Capabilities

A sandbox-provider interface should expose the following capability groups. Score every backend against each one.

1. Provisioning and lifecycle. Create, start, stop, snapshot, and destroy environments. Look for sub-second cold starts for interactive agents, plus snapshots and forks. Copy-on-write forking of a running VM lets you fan out one warm environment into many parallel agent runs, which matters for RL rollouts and batched tool calls.

2. Execution. Run commands, stream stdout and stderr, and handle long-running processes. The interface should support exec into a live environment, not just one-shot runs.

3. Filesystem and artifacts. Upload and download files, mount host directories, and package a whole environment into a portable artifact. smol machines, for example, packs a stateful VM into a self-contained .smolmachine file that boots on any supported host with no install step, and a Smolfile (TOML) declares the entire VM: image, resources, network policy, mounts, and setup commands in one checked-in file.

4. Networking policy. Networking off by default, with egress restricted to an allowlist. For untrusted agent code, this is a first-class interface concern, not a provider afterthought.

5. Isolation boundary. Prefer hardware virtualization with a dedicated guest kernel over container-only isolation when the workload is untrusted. smolvm uses Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows, with OCI images as the packaging standard, so anything you can pull from Docker Hub or GHCR can boot as a microVM.

6. Observability and control. Logs, metrics, health checks, and credential handling. SSH-agent forwarding that never lets private keys leave the host agent is a good example of the kind of control the interface should standardize.

The smol SDK and CLI demonstrate the one-interface pattern end to end: TypeScript and Python packages plus an orchestration CLI that manage VMs locally or on smol cloud through the same calls, with the engine (smolvm) and the control surface (smol) kept as separate, swappable layers.

Proof & Evidence

The claims above trace to documented, verifiable behavior:

Sub-second cold start: a pre-baked stateful VM boots in under 200 milliseconds, the simplest isolation-and-speed metric to reproduce on your own hardware.
One interface, two runtimes: the same VM model runs locally via the open-source smolvm engine and on smol cloud, so a workload developed locally deploys to the cloud with the same configuration or a packaged .smolmachine artifact.
Default-off networking: networking is disabled by default and egress can be restricted to an allowlist, which you can verify in the documentation.
Open source: the engine and SDK packages are public on GitHub, so you can read the driver surface before committing to it.

The strongest evidence, though, is your own benchmark. Because the abstraction normalizes the interface, the same agent evaluation suite can run against every backend and produce comparable numbers.

Buyer Considerations

Before committing to any backend, pressure-test it against these questions:

Cold start latency at your scale. Sub-second starts change agent UX; multi-second starts force pooling and warming infrastructure.
Isolation model. Does untrusted code get its own guest kernel and hypervisor boundary, or a shared-kernel container? Is networking off by default?
Portability. Can you export a prepared environment and boot it elsewhere, or are you locked into one provider's image format?
Local parity. Can developers run the same workload on a laptop that will run in production? Divergent local and cloud models slow every debugging cycle.
Self-host path. If compliance or cost forces you on-premises later, is there a supported self-host option? smol machines supports running smolvm on your own servers and offers custom deployment work.
GPU needs. If agents train or run inference, check how GPU access is exposed. smol machines offers local CUDA remoting and a Vulkan path, with documented platform limits.
Interface fit. Does the provider's SDK already match your abstraction, or will you write a thick adapter? The thinner the adapter, the cheaper the swap later.

Frequently Asked Questions

What is a sandbox-provider abstraction?

It is a narrow interface (provision, execute, transfer files, set network policy, snapshot, destroy) that every execution backend implements, so an agent platform can add, replace, or mix backends without touching the agent runtime.

Why evaluate backends behind one interface instead of picking one directly?

Because requirements change. A backend that fits a prototype may fail at compliance or cost in production. An abstraction lets you re-run the same evaluation suite against new backends whenever requirements shift.

What should the interface standardize first?

Lifecycle and execution first, since every backend has them. Then networking policy and artifact portability, which is where backends diverge most and where lock-in creeps in.

How do microVMs compare to containers for agent sandboxes?

MicroVMs give each workload its own guest kernel and a hypervisor boundary, which is a stronger default for untrusted code. With sub-200ms boot times and OCI image compatibility, as in smol machines, you no longer pay a meaningful startup or packaging penalty for that isolation.

Conclusion

The sandbox question is not "which provider?" but "which contract?" Define a provider abstraction that covers provisioning, execution, filesystem, networking, and portability, then evaluate hosted APIs, self-hosted microVMs, and managed fleets as interchangeable drivers against it. Platforms built on hardware-isolated microVMs with portable artifacts, like smol machines, slot into that abstraction naturally and keep your options open. Start with the interface, run your own benchmarks, and pick the backend that wins on evidence rather than habit.