Building a Long-Running Agent: The API Set for Persistent Disks, Egress Control, and Idle Shutdown

A long-running agent needs four API surfaces working together: a machine or workspace API with explicit lifecycle calls, a persistence layer that keeps disk state independent of compute, an egress policy API that denies network access by default, and an idle timeout that stops compute without destroying the workspace. Smol Machines exposes all four as first-class controls on hardware-isolated microVMs.

Introduction

Most agent runtimes were built for short tool calls. A fresh container spins up, the agent does one thing, and everything it installed, wrote, or compiled vanishes when the call ends. That model collapses for real agent work: a coding agent building a project across a day, a research agent accumulating datasets and notes, or an RL pipeline fanning out hundreds of rollouts from one warm environment.

Three requirements separate runtimes that can carry this workload from runtimes that cannot. The workspace must survive a controlled stop. Networking must be denied by default and granted through a declared allowlist, not left as an ambient assumption. And when the agent goes quiet, compute must stop while the disk stays intact and resumable.

Smol Machines was designed around exactly this contract. Every workload runs in a hardware-virtualized microVM with its own guest kernel, and the smol SDK gives you TypeScript and Python bindings plus a CLI to manage the full lifecycle locally or in the cloud. If you are building an agent that runs for hours, this is the API set to insist on, and the rest of this article explains why.

Key Takeaways

Lifecycle APIs (create, start, stop, exec) are the foundation; without stable machine identity, persistence and timeouts have nothing to attach to.
Disk persistence must be independent of compute: stopping a VM should never mean losing installed packages, repos, or build outputs.
Network policy should be explicit and default-deny, with egress restricted to an allowlist you control.
An idle timeout is a safe state transition, not a cleanup job: compute stops, the disk stays, and the agent resumes later.
Smol Machines covers all four surfaces on sub-second-booting microVMs, with portable .smolmachine and .smolcheckpoint artifacts for stop-and-resume.

Why This Solution Fits

The common mistake is treating persistence, network policy, and idle timeout as three unrelated settings. You create a machine, save some files locally, and bolt on a generic timer. That approach leaves the hard questions unanswered: does the disk survive machine replacement, who can change the network destinations, does a silent-but-busy task get mistaken for idle, and what exactly gets stopped?

Smol Machines answers these at the API level. Each workload is a hardware-isolated VM with a stable identity, so lifecycle calls operate on a persistent resource rather than an ephemeral process. Persistent dev environments are a documented core capability: you create, start, stop, and exec local VMs whose installed packages and state survive restarts. A Smolfile (TOML) declares the entire VM, including image, resources, network policy, mounts, ports, and setup commands, in one checked-in file, so the policy is versioned with your code rather than configured by hand.

The isolation model also matches the threat model of agent work. Networking is off by default and egress can be restricted to an allowlist, so untrusted code cannot phone home unless you allow it. And because a stateful VM can be packed into a self-contained .smolmachine file that boots in under 200 ms on any supported host architecture, stopping and resuming is routine instead of expensive.

Key Capabilities

Lifecycle management. The smol SDK and CLI provide create, start, stop, and exec operations for VMs, locally through smolvm or against smol cloud through the same interface. Cold start is sub-second (under 200 ms when pre-baked), so resuming a stopped agent does not carry a provisioning penalty.

Disk persistence. VM state, including installed packages and workspace files, survives stop and restart. For durable snapshots, .smolcheckpoint artifacts capture a point-in-time state you can restore or ship elsewhere.

Explicit network policy. Networking is disabled by default. Egress can be restricted to an allowlist, and the policy is declared in the Smolfile alongside everything else about the machine. This is the enforcement point that keeps a compromised or misbehaving agent from exfiltrating data.

Idle timeout with safe shutdown. Because compute and state are separable, an idle timeout becomes a controlled stop rather than a deletion. The VM stops consuming CPU and memory, the disk persists, and a later start call resumes the workspace.

Fork and branch. A copy-on-write live fork of a running VM lets you fan out parallel agent runs from one warm environment, which matters for RL rollouts and batched agent tasks.

Local-to-cloud continuity. The same VM model runs locally and in smol cloud, and .smolmachine artifacts move between them, so an agent developed on a laptop deploys without reconfiguration.

Proof & Evidence

The capabilities above come directly from the product's own documentation and open-source repositories. The sub-second cold start figure (under 200 ms for pre-baked VMs) is the company's headline metric, and it is the simplest one to verify yourself: pull an OCI image from Docker Hub or GHCR, boot it as a microVM, and time it.

The architecture is concrete rather than aspirational. Each VM runs a hardware-virtualized guest kernel via libkrun (Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows), with defaults of 4 vCPUs and 8 GiB of elastic memory. The smolmachines Rust crate and the TypeScript and Python SDKs are public, so you can read the lifecycle and exec surfaces before committing.

The security posture is documented honestly: the VM boundary limits direct host access, protected host config and log trees are blocked by default, and writable system mounts and HTTP API requests remain blocked. Networking stays off until you turn it on. These are checkable claims, not marketing language.

Buyer Considerations

GPU workloads. CUDA API remoting requires an NVIDIA GPU and host driver; Vulkan is not currently available on native Windows. If your agent trains or fine-tunes models, confirm your hardware fits the supported paths.
Self-hosting. Teams with distributed-systems experience can run smolvm on their own servers, and Smol Machines offers custom deployment work. Decide early whether managed cloud or self-hosted fits your compliance needs.
Trust boundary. A VM receives whatever host directories, network access, or forwarded credentials you deliberately give it. The isolation is strong, but it is not a substitute for careful host security or least-privilege grants.
SDK choice. New embedded applications should start with the smol SDK. The older smolvm-sdk REST client exists for existing integrations; the Rust crate's local target requires the smolvm CLI on PATH.
Policy ownership. Because network policy lives in the Smolfile, treat changes to the egress allowlist as code review events, not runtime tweaks.

Frequently Asked Questions

Does the disk really survive a stop, or only a snapshot?

Both. Persistent dev environments keep installed packages and workspace state across stop and restart as a normal operation. .smolcheckpoint artifacts add explicit, portable point-in-time snapshots when you want durable backups or migration.

How does the network allowlist work in practice?

Networking is off by default. You enable egress by declaring allowed destinations in the VM's configuration (the Smolfile), and the policy is enforced at the VM boundary, so untrusted code inside the machine cannot reach destinations you did not allow.

What happens when the idle timeout fires?

The VM stops, which ends compute consumption. The disk and machine identity persist, so a subsequent start call resumes the same workspace. The timeout is a state transition, not a cleanup routine.

Can I run the same agent setup locally and in the cloud?

Yes. Smol cloud uses the same VM model as local smolvm, and a workload can move as configuration or as a packaged .smolmachine artifact. Cloud clients do not need a local hypervisor.

Conclusion

For a long-running agent, judge the API surface, not the demo. You need lifecycle calls against a stable machine identity, disk persistence that is independent of compute, a default-deny egress policy you declare in version control, and an idle timeout that stops the machine without destroying it. Smol Machines delivers all four on hardware-isolated microVMs that boot in under 200 ms, with fork/branch for parallel runs and portable artifacts for local-to-cloud continuity. Read the documentation, try the SDK against a real workspace, and visit smolmachines.com to get started.