Snapshot Execution Beats Replay for Durable Agents
AI Engineergo watch the original →
the gist
Trigger.dev separates agent durability into context logs (append-only DB) and execution snapshots on Firecracker microVMs (14MB compressed, <1s save, 100-200ms restore), overcoming replay model's log bloat for long-running sessions.
Replay Model Limitations
The talk critiques the replay-based durability used in workflows and early agents, where every LLM call and tool becomes a cached step in a journal. This works for short transactions but fails for agent sessions: journals grow unbounded with turns (e.g., after one turn, log already balloons), code must be deterministic and wrapped in rigid steps, and versioning complicates resumes. Agents now exceed hours of work, doubling every 4-7 months, turning transactions into open-ended sessions.
Shared-nothing architecture (request + DB = response, from CGI 1993 to serverless) extended to async workflows via durable engines 10-15 years ago, but agent loops invert control (LLM orchestrates code), amplifying replay's constraints.
Context Durability via Append-Only Logs
Eric Allam splits agent state: context (system/user messages, tool calls/results, assistant responses) stores as an append-only log in databases, object storage, or distributed filesystems. This scales well, enables code version upgrades without losing history, survives machine crashes, and supports pauses (e.g., human input).
Context alone handles LLM outages by snapshotting execution and retrying later.
Execution Durability with Firecracker Snapshots
Execution state (files, memory, subprocesses, Git clones, package installs, dev servers) requires snapshots, not logs. Trigger.dev uses Firecracker microVMs for whole-machine checkpoint/restore, transparent to processes and container-compatible.
Optimizations: seekable compression reduces 512MB RAM to 14MB (tunable), page-on-demand restore. CRIU (2011) inspired but limited to single processes, open files, slow with registries; Firecracker snapshots everything.
Historical nod: IBM mainframes (1966) used checkpoints for expensive jobs.
Upcoming open-source fc-run (or frun) CLI mimics Docker: fc-run alpine, snapshot/restore/fork VMs fast. Benchmarks: 15,000 VM starts/minute (~30 FPS video rate), snapshots <1s, restores 100-200ms.
Combined: durable agents recover from errors (LLM retry via snapshot+restore; machine crash via context replay), shift backend infra to stateful compute.
Implementation and Future
Trigger.dev shipped CRIU-based snapshots in 2024 (millions done), switched to Firecracker last year. fc-run powers their compute layer, enabling production agents with laptop-like state (e.g., running Chrome, FFmpeg) across turns without idle costs.