Two Roads to Durable Agents: Replay vs. Snapshot — Eric Allam, CEO, Trigger.dev

Eric Allam, CEO of Trigger.dev, presents a fundamental architectural argument for why the replay-based durability model that has powered backend workflows for the past decade is inadequate for long-running AI agents, and introduces a two-part solution combining context logs with OS-level VM snapshots.

Allam opens with a compressed history of backend infrastructure: from stateless CGI in 1993 and the LAMP stack's shared-nothing architecture, to the adoption of durable execution engines (such as Temporal-style workflow orchestrators) roughly 10-15 years ago. Those workflow engines solve the re-entrancy problem — for example, preventing a credit card from being charged twice on retry — by wrapping every side effect in a cached step and replaying the function from the top on recovery. This replay model works well for discrete, bounded multi-step workflows.

The problem emerges when agents are treated like workflows. In the agent loop, the LLM orchestrates the code rather than the reverse. Each turn produces LLM call steps, tool call steps, and tool result steps, all appended to the replay journal. After a single turn the journal is already non-trivial; across many turns it grows without bound and eventually hits structural limits — either entry count or entry size. Allam cites research showing that the horizon of meaningful autonomous agent work is doubling every 4–7 months, currently sitting at a few hours and projected to reach multiple days. An agent running for days cannot be modeled as a transaction; it must be modeled as a session.

Allam proposes splitting the durability problem into two orthogonal concerns. First, context durability: the append-only log of all system messages, user messages, tool calls, tool results, and assistant responses. This data is already structured, lives naturally in a database or object storage, and scales well as an append-only log. Persisting it enables durability across code version upgrades and machine crashes. Second, execution durability: the live machine state — cloned repos, installed packages, in-memory datasets, running dev servers, subprocess sandboxes. This cannot be reconstructed from a log; it must be saved directly.

For execution durability, Allam advocates snapshot and restore rather than log replay. He traces the lineage back to IBM mainframe checkpoint-and-restore in 1966, then to CRIU (Checkpoint/Restore In Userspace), open-sourced in 2011, which Trigger.dev shipped in 2024 and has used for millions of snapshot-restore operations. CRIU's limitations — it cannot capture external processes like FFmpeg or Chrome, only captures open files, and becomes slow when pushed through container registries — motivated a migration to Firecracker microVMs.

With Firecracker, Trigger.dev snapshots the entire VM. Naively, a 512 MB machine produces a 512 MB snapshot. They address this with seekable compression: on restore, only the memory pages actively needed are decompressed on demand. Combined with snapshot layering techniques, they achieve snapshots of approximately 14 megabytes compressed. Benchmark results: snapshot time is slightly under one second; restore time is a few hundred milliseconds. Their infrastructure handles 15,000 VM starts per minute — roughly 30 frames per second if rendered as video. Allam announces that these capabilities are being packaged into an open-source CLI tool called FCRun (or Fcrun), designed as a drop-in Docker CLI replacement for running containers in Firecracker VMs with built-in snapshot, restore, and fork support.

The talk concludes by reuniting the two halves: context log (database-backed, append-only) plus execution snapshot (Firecracker VM, sub-second save, hundred-millisecond restore) together yield durable agents that survive version upgrades, multi-turn pauses, LLM retries, and machine crashes. Allam frames this as backend infrastructure's transition from stateless compute — the dominant paradigm for 30 years — to stateful compute.