A Process-Oriented Runtime: Sandboxes, Snapshots, Recovery
Long-horizon tasks cannot keep state in memory: lightweight sandbox isolation, second-level checkpoints, and event-driven wake-up on demand.
Many first-generation agents run on something fragile: one long-lived process on a server, with every intermediate file and piece of state left in a directory on the host or in that process's memory.
It looks fine in a demo. In production it fails in three ways.
First, wasted resources and a concurrency ceiling. When a task waits for human approval, or for a slow external test suite, the process can only idle on the host. As concurrent tasks pile up, CPU and connections run out.
Second, no recovery for long runs. A host reboot or a dropped network connection kills a task that has already run for half an hour. Nothing was persisted, so the only option is to start over — losing both the wall-clock time and every model call already paid for.
Third, shared pollution and blast radius. Tasks share the host filesystem. One agent that deletes a common dependency, or downloads a hostile script, takes down every other task on the machine.
The fix is to change the runtime abstraction from a fragile long-lived process to an elastic, process-oriented sandbox.
Compute is temporary, state is durable
The first principle is to separate compute from business state completely.
Compute is ephemeral. When the agent needs to run a command, analyze code, or process data, the system allocates a lightweight sandbox on demand. Once the operation finishes, or the task enters a waiting phase, that compute can be paused or destroyed.
State is durable. Which step the task reached, which files it changed, which dependencies it produced — all of that lives in durable storage, never in one machine's memory.
| Dimension | Long-lived process | Process-oriented sandbox |
|---|---|---|
| Isolation | Tasks share the host directory | Each task gets its own MicroVM or container |
| Resources | CPU and memory idle while waiting | Suspends and releases on wait, restores in seconds |
| Recovery | A crash loses everything; rerun from step one | Snapshot at safe points; roll back and retry in place |
| Environment life | Runs long enough to rot, residue accumulates | Destroyed on completion or failure; always clean |
Lightweight isolation and egress control
Isolation is usually built on lightweight virtualization. firecracker-microvm
Each task mounts a read-only base image plus a writable layer of its own. Inside the sandbox the agent may create and modify files freely, but it sees only a strictly bounded virtual space: it cannot touch host files or read a neighboring sandbox.
Egress needs an allowlist too. By default the sandbox is offline, or reachable only to internal package mirrors. When a task genuinely needs the public internet — fetching public documentation, say — the request passes through a proxy that inspects the domain, so a manipulated agent cannot ship internal data outward.
Second-level checkpoints and safe rollback
For tasks that run for tens of minutes, checkpointing is the core asset behind successful delivery. cursor-cloud-sandboxes
The system takes incremental snapshots at three moments:
- A milestone lands — environment initialized, core files written, unit tests green.
- A high-risk action is about to run — a database write, a configuration change, anything irreversible.
- The model is about to commit to one of several approaches.
A snapshot captures the filesystem delta plus the step counter, a session memory summary, and the environment configuration. Mature open-source implementations of process-level freeze and restore are worth studying here criu-checkpoint.
When the agent later loops, or the chosen approach proves wrong, no one has to restart the task. The scheduler tells the sandbox to discard the recent bad changes and rolls back to the last healthy snapshot. The model gets a clean environment plus a clear explanation of why the last attempt failed, and picks a better route.
Suspend on demand, wake on events
When the task reaches a human approval gate, or waits on a slow third-party system, the workflow does not let the sandbox spin.
The runtime freezes the sandbox state to object storage and suspends the microVM. fly-machines Its CPU and memory are released immediately and handed to other active tasks.
When an approver clicks through in chat or on the web, or an external build sends its completion webhook, an event gateway matches the task id to the suspended record. Within a few hundred milliseconds the scheduler starts a fresh, clean sandbox, restores the snapshot, and the task continues as if it had never stopped.
Final archival and teardown
When the task passes acceptance and ships, the deliverables — an archive, a patch, a data report — move into the company's durable storage with a tamper-evident delivery record.
The temporary sandbox is then deleted and its scratch directories cleared. No stray processes, no accumulated debris. That full arc — create, isolate, snapshot, suspend, destroy — is what gives long-horizon agents the stability and cost control a production system needs.