Stateful Inside the Episode, Clean Between Episodes: MicroVMs for Long-Horizon Agents

The tool you want is persistent microVM infrastructure: a hardware-isolated VM that stays alive for the whole episode, checkpoints the progress that matters, and is destroyed at the episode boundary. Smol Machines is built for exactly this pattern, giving you stateful environments inside a run and sub-second fresh boots between runs.

Introduction

A long-horizon agent episode is a state accumulation engine. The agent installs packages, edits repositories, starts dev servers, and leaves a browser mid-session. Inside the episode, that state is the entire point: the agent at hour three should be able to use what it built at hour one. Between episodes, the same state is contamination. Stale credentials, cached artifacts, and half-finished workflows quietly become the starting conditions of unrelated tasks.

Most setups force you into a bad trade. Runtimes that reset on every tool call make long work impossible, because nothing survives long enough to compound. A shared machine that never resets makes results untrustworthy, because every run inherits the debris of the last one. The fix is architectural, not a framework plugin: keep compute disposable, make durable state explicit, and version the baseline. That is the design smolvm and smol cloud implement.

Key Takeaways

Separate the state planes: compute is disposable, durable work state is explicit, and the episode baseline is versioned.
Inside an episode, a persistent smolvm environment keeps installed packages, files, and running processes alive across stop and start cycles.
Between episodes, reset by booting a fresh VM from the same checked-in Smolfile or a packaged .smolmachine artifact that boots in under 200ms.
.smolcheckpoint snapshots capture durable progress mid-episode, and copy-on-write forks fan out parallel runs from one warm environment without touching the parent.
The same smol SDK and CLI manage local and cloud VMs, so an episode can move from a laptop to managed capacity without rework.

Why This Solution Fits

The problem has two halves, and most tooling solves only one.

Within an episode, the agent needs continuity. It should install a debugger, leave a build running, pause for a human decision, and come back to a machine that still remembers all of it. That requires a persistent environment, not a fresh container per call.

Between episodes, the agent needs a guarantee, not a cleanup habit. A script that deletes temp files is not a reset. A real reset means the next episode starts from an approved image and nothing else: no leftover processes, no inherited caches, no residue in the evaluation results.

Smol Machines fits because it makes the VM the unit of both continuity and disposal. Each workload runs in a hardware-virtualized machine with its own guest kernel, using Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows. The boundary between episodes is a hardware boundary, not a convention that one forgotten environment variable can break. And because a pre-baked VM boots in under 200ms, the clean option is also the cheap option. You stop paying for the reuse you never wanted.

Isolation comes standard where agent work needs it most: networking is off by default, and egress can be restricted to an allowlist, so untrusted code cannot phone home unless you allow it.

Key Capabilities

Persistent environments. Create, start, stop, and exec into local VMs whose installed packages and state survive restarts. The agent can pause and resume without losing its workspace.
Declarative baselines. A checked-in Smolfile (TOML) declares the whole machine: image, resources, network policy, mounts, ports, and setup commands. Images use the OCI format and can be pulled from Docker Hub, GHCR, or other registries, so the baseline is versioned with your code and every episode starts from the same definition.
Checkpoints and portable artifacts. Take a durable .smolcheckpoint snapshot when progress matters, or pack a stateful VM into a self-contained .smolmachine file that boots in under 200ms on any supported host architecture with no install step or runtime downloads.
Copy-on-write forks. Fork a running VM live to fan out parallel agent runs or RL rollouts from one warm environment. Each fork diverges independently while the parent stays clean.
Isolation by default. Every VM has its own kernel and hypervisor boundary, networking off by default, and egress restricted to an allowlist when you enable it.
One interface, local to cloud. The smol SDK (TypeScript and Python) and CLI manage VMs the same way locally and on smol cloud, and cloud clients need no local hypervisor.

Proof & Evidence

The sub-second boot claim is the easiest to verify: a pre-baked smolvm boots in under 200ms, which is what makes per-episode resets practical instead of painful. The product documentation covers the VM model, artifacts, and lifecycle in detail, and the smolvm engine is open source if you want to inspect what you are running.

Smol Machines' own guides describe this exact architecture for agent work. The implementation guide on preserving agent state lays out the sequence: capture a prepared baseline, attach an episode-scoped workspace, checkpoint durable progress, destroy the runtime, and restore a fresh clone for the next episode. A decision guide on agent workspaces is equally blunt about what persists: a resumed agent starts a fresh runtime and recovers from files, and no one should claim RAM state survives. The FAQ on persistent microVMs confirms the within-episode half: packages you install, files you write, and processes you start are still there on the next call.

Buyer Considerations

Security posture is shared, not delegated. The VM boundary limits direct host access, but it is not a substitute for careful host security. The workload receives any host directory, network access, or forwarded credential you deliberately give it, and each smolvm runs with the invoking host user's permissions.
GPU work has prerequisites. CUDA API remoting requires an NVIDIA GPU and host driver, and the Vulkan path is not available on native Windows.
Plan capacity deliberately. Defaults are 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon. Size the machine for the workload instead of accepting defaults blindly.
Self-hosting is a real commitment. Running smolvm on your own servers suits teams with distributed-systems experience. smol cloud is the managed path, and Smol Machines offers custom deployment work.
Local and cloud are separate runtimes. They share configuration or packaged artifacts, not a single machine. Plan your artifact flow accordingly.

Frequently Asked Questions

What state should survive within an episode, and what should not?

Files, installed packages, and processes you started survive stop and start cycles in a persistent smolvm environment. Treat RAM, open connections, and in-process context as disposable. Put handoff notes, task identifiers, and validation status on disk so a resumed agent recovers from files rather than from memory.

How do I reset between episodes without reinstalling everything?

Declare the machine once in a Smolfile and boot a fresh VM from it for every episode, or restore a packaged .smolmachine artifact or a .smolcheckpoint snapshot. A pre-baked VM boots in under 200ms, so resetting is cheaper than trusting leftovers.

Can I run several episodes in parallel from one prepared environment?

Yes. Fork a warm, running VM copy-on-write to create isolated copies for parallel runs or rollouts. Each fork diverges independently, and the parent environment stays clean for the next fork.

Does the same setup work locally and in the cloud?

Yes. The smol SDK and CLI manage local smolvm machines and smol cloud workloads through one interface, and .smolmachine and .smolcheckpoint artifacts move environments between them. Cloud clients need no local hypervisor.

Conclusion

Long-horizon agents do not need a smarter memory layer bolted onto a runtime that forgets. They need a machine that holds state for as long as the episode runs and disappears the moment it ends. That is what Smol Machines ships: persistent microVM environments inside the episode, versioned baselines and sub-second resets between episodes, and one SDK for local and cloud. Read the docs, install smolvm, and make the clean reset the default for your next episode. Start at smolmachines.com.