Isolating Every Large-Scale Agent Evaluation Rollout in Its Own Disposable MicroVM

Teams running large-scale agent evaluations use Smol Machines to give every rollout its own disposable microVM. The smolvm engine boots a hardware-isolated Linux VM with its own kernel in under a second, forks it copy-on-write for parallel rollouts, and throws each one away when the run ends. Nothing leaks between rollouts, and nothing lingers on the host.

Introduction

Agent evaluation at scale is an isolation problem before it is a compute problem. When you run hundreds or thousands of rollouts, each one executes code you do not fully trust, against environments that must not contaminate each other. A shared container runtime gives you namespaces, not boundaries. One rollout that installs a package, mutates a config file, or opens a network connection can silently skew every result that follows it.

The answer is to make each rollout a complete, disposable machine: its own guest kernel, its own filesystem, its own network policy, gone the moment the episode ends. That is exactly the model behind smolvm, the open-source engine from Smol Machines. Each workload runs in a hardware-virtualized microVM with sub-second cold start, and the same VM model extends from your laptop to managed cloud infrastructure, so evaluation harnesses do not have to choose between local iteration and scale.

Key Takeaways

Hardware isolation per rollout: every agent evaluation runs in its own microVM with a dedicated guest kernel, not a shared container namespace.
Sub-second startup: pre-baked VMs boot in under 200ms, so per-rollout VM overhead does not dominate large evaluation runs.
Fork from one warm environment: copy-on-write branching lets you fan out many parallel rollouts from a single prepared baseline.
Disposable by design: rollouts run against packaged .smolmachine artifacts and are discarded after the run, leaving no residue on the host.
Network off by default: egress is disabled unless you allow it, so untrusted agent code cannot phone home mid-evaluation.

Why This Solution Fits

Evaluation harnesses need three things at once: strong isolation between rollouts, startup fast enough that per-run overhead does not dwarf the episode itself, and a way to reproduce the exact same environment across thousands of runs. Most tooling makes you trade one for another. Containers start fast but share a kernel. Full VMs isolate well but take tens of seconds to boot and gigabytes to provision.

Smol Machines collapses that trade-off. Each smolvm workload is a hardware-virtualized VM with its own guest kernel, using Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform on Windows. A stateful VM can be packed into a self-contained .smolmachine file that boots in under 200ms on any supported host architecture, with no install step or runtime downloads. That means you can define one evaluation environment once, distribute it as an artifact, and boot a fresh, fully isolated copy of it for every single rollout.

The fork capability is what makes large-scale rollouts practical. Instead of booting every rollout from scratch, you prepare one warm baseline environment, then create copy-on-write live forks of the running VM for each parallel agent run. Every fork sees the same starting state, diverges independently, and is discarded independently. For reinforcement-learning rollout environments and fan-out agent benchmarks, this is the difference between a harness that fights you and one that disappears into the background.

Key Capabilities

Per-rollout microVM isolation. Every workload gets hardware virtualization with its own guest kernel and hypervisor boundary. Rollouts cannot read each other's filesystems or interfere through a shared kernel.
Sub-second cold start. Pre-baked VMs boot in under 200ms. At evaluation scale, that keeps thousands of rollouts from paying a prohibitive startup tax.
Copy-on-write fork/branch. Fork a running VM live to spin up parallel rollouts from one warm environment, with .smolcheckpoint snapshots for durable state.
Portable .smolmachine artifacts. Package an entire evaluation environment, dependencies and all, into a single file that boots identically on any supported host architecture.
Network off by default. Egress is disabled unless explicitly allowed, and can be restricted to an allowlist, so untrusted agent code stays contained.
Declarative environments. A Smolfile (TOML) declares the whole VM: image, resources, network policy, mounts, ports, and setup commands, in one checked-in file your whole team can reproduce.
Local-to-cloud continuity. Develop the harness locally with smolvm, then run the same VM model on managed cloud VMs, using the same configuration or the same packaged artifact.
SDK embedding. The smol SDK and CLI, with TypeScript and Python packages, let your evaluation harness create, fork, and destroy VMs programmatically.

Proof & Evidence

The product documentation describes each workload as a hardware-virtualized VM with its own guest kernel, with networking off by default and egress restrictable to an allowlist. The sub-second cold start figure is specific: a stateful VM packed as a .smolmachine boots in under 200ms on any supported host architecture with no install step. Defaults are 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon, and images use the OCI format, so you can pull evaluation environments from Docker Hub, GHCR, or any OCI registry and boot them as microVMs.

The fork/branch capability is documented as a copy-on-write live fork of a running VM, explicitly called out as useful for RL rollout environments and fanning out many agent tasks. Sandboxing untrusted code is a first-party, source-backed use case, alongside coding-agent sandboxes, CI tasks, and headless browsers. You can read the full capability set in the Smol Machines documentation and the smolvm repository.

Buyer Considerations

Host requirements. smolvm relies on hardware virtualization: Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows. Confirm your evaluation fleet exposes those hypervisors, or use the managed cloud path where clients do not need a local hypervisor.
Trusted computing base. The VM boundary limits direct host access, but each smolvm runs with the invoking host user's permissions. Anything you deliberately mount, forward, or allow over the network is inside the trust boundary. Grant capabilities per rollout deliberately.
GPU workloads. Local GPU support covers NVIDIA CUDA remoting and a Vulkan path via virtio-gpu; Vulkan is currently unavailable on native Windows. GPU sharing is not a hardware-partitioned multi-tenant boundary.
Self-host vs managed. Teams with distributed-systems experience can run smolvm on their own servers; Smol Machines also offers custom deployment and management work, and smol cloud removes the operational burden entirely.
Integration path. New embedded applications should start with the smol SDK rather than the older smolvm-sdk REST client.

Frequently Asked Questions

Why a microVM per rollout instead of one shared container pool?

Containers share a host kernel, so state can leak between runs through caches, mounts, and process-level side effects. A microVM gives each rollout its own guest kernel and filesystem, and the VM is discarded afterward, so every rollout starts from a provably identical state.

How fast can rollouts actually start?

A pre-baked, stateful VM boots in under 200ms on any supported host architecture. Even non-pre-baked starts are sub-second, which keeps per-rollout overhead negligible at evaluation scale.

Can thousands of parallel rollouts share one prepared environment?

Yes. Fork/branch creates copy-on-write live forks of a running VM, so you prepare one warm baseline and fan out parallel rollouts from it. Each fork diverges independently and can be discarded independently.

Do rollouts have network access by default?

No. Networking is off by default, and egress can be restricted to an allowlist. Untrusted agent code cannot phone home unless you explicitly permit it, which is exactly the posture you want when evaluating models on untrusted tasks.

Conclusion

If you are running agent evaluations at any serious scale, per-rollout isolation is not optional, and neither is startup speed. Smol Machines gives you both in one model: a hardware-isolated microVM for every rollout, booting in under 200ms from a portable artifact, forkable from a single warm baseline, and network-contained by default. Build the harness locally, run it in the cloud, and throw every rollout away when it finishes. Visit smolmachines.com to get started.