# Two Roads to Durable Agents: Replay vs. Snapshot Eric Allam, Trigger.dev | AI Engineer Europe 2026 | 16:36 Source: https://www.youtube.com/watch?v=svCnShDvgQg Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/two-roads-to-durable-agents-replay-vs-snapshot Published: 2026-05-10 Tags: agents, deployment, inference ## TL;DR - Replay makes side effects safe to retry, but long-running agents can outgrow a journal and the coding constraints it creates. - Agent durability has two separate parts: an append-only context log and a snapshot of the machine running the agent. - Firecracker snapshots let Trigger.dev preserve complete execution state with compressed snapshots as small as 14 megabytes, sub-second saves, and restores in a few hundred milliseconds. ## Summary Eric Allam explains why the replay model used by workflow engines becomes awkward for agents. Replay wraps every LLM call and tool call in a journal, then re-executes the function and skips work already recorded. That protects side effects, but the journal grows with each turn, code outside steps must be deterministic, and version changes complicate recovery. Allam separates agent state into context and execution. Context is the messages, tool calls, results, and responses, and an append-only log can store it in a database or object store. Execution includes files, memory, subprocesses, installed packages, and running services. That state cannot be reconstructed well from a log, so Trigger.dev uses machine snapshots and restores. With Firecracker microVMs, the company compresses snapshots to 14 megabytes and restores them in hundreds of milliseconds. Allam argues that agents are pushing backend systems toward stateful compute. ## Key ideas ### Replay made multi-step side effects safe to retry [03:30](https://www.youtube.com/watch?v=svCnShDvgQg&t=210s) Workflow and durable execution engines solved failures in sequences such as charging a credit card and sending a receipt. Each side effect is wrapped in a step and cached when it runs. On a retry, the system skips completed steps and performs only the unfinished work, so the card is not charged twice. Allam calls this the replay model. It adds an execution history that can act as an audit trail, and it lets a workflow resume after a failure or wait for an external event, such as a human action. ### Replay imposes structure that becomes difficult for agents [04:37](https://www.youtube.com/watch?v=svCnShDvgQg&t=277s) Replay requires every side effect to be inside a step, while code outside those steps must be deterministic. Allam says this creates a rigid way of writing programs. Replay journal versioning also becomes difficult when a new code version is deployed. These constraints were manageable when an LLM was simply another workflow step, such as a text classifier. Tool calling changed the arrangement because the LLM began directing code through an agent loop. ### An agent replay journal grows with every turn [05:30](https://www.youtube.com/watch?v=svCnShDvgQg&t=330s) To make an agent loop durable with replay, every LLM call and every tool call becomes an entry in the journal. When the function resumes, it runs again and replays the recorded work. After one modest turn, the log already contains several entries. As the user continues interacting, the log keeps growing until it reaches a limit based on the number or size of entries. Allam contrasts this with a workflow: a workflow has a beginning and an end, while an agent behaves more like a session that lasts as long as the user wants. ### Agent durability has separate context and execution state [07:12](https://www.youtube.com/watch?v=svCnShDvgQg&t=432s) Allam divides an agent into two parts. Context includes system messages, user messages, tool calls, tool results, and assistant responses, meaning everything sent to or returned from the LLM. This is an append-only log and can be stored durably in a database, object storage, or a distributed file system. Execution state belongs to the machine itself. An agent may clone a GitHub repository, install packages, keep data in memory, run a development server, or create a subprocess. These pieces of state matter, but they need different persistence methods. ### Snapshot and restore preserves the machine between turns [09:20](https://www.youtube.com/watch?v=svCnShDvgQg&t=560s) An agent may wait hours for the next user message, yet leaving its machine running would be expensive. Allam's solution is to snapshot the machine, shut it down, save the snapshot to disk, and restore it when the next message arrives. This preserves what the agent was doing while avoiding an always-on machine. Combined with a durable context log, snapshots provide durability across turns and across changes to the code harness. ### Different failures call for different recovery paths [10:02](https://www.youtube.com/watch?v=svCnShDvgQg&t=602s) The recovery method depends on what failed. If an LLM request asks the system to retry after 15 minutes, the machine can be snapshotted rather than held in memory, then restored when the retry is allowed. If the machine itself has a bug or another infrastructure problem, the context log can be used to recover the agent's conversation and execution path. The two forms of saved state therefore cover different failure boundaries. ### Firecracker snapshots capture complete machine state [11:42](https://www.youtube.com/watch?v=svCnShDvgQg&t=702s) Trigger.dev first used CRIU to suspend and restore processes, but that approach could not reliably cover programs such as FFmpeg or Chrome, and it had limitations around file systems and container registries. Firecracker microVMs let the company snapshot the entire machine, including whatever was running inside it. A naive snapshot of a 512-megabyte machine would occupy 512 megabytes, so Trigger.dev uses seekable compression and layered snapshots. It can reduce a snapshot to 14 megabytes compressed and restore memory pages as they are needed. ### FC Run packages fast VM snapshotting behind a Docker-like interface [14:19](https://www.youtube.com/watch?v=svCnShDvgQg&t=859s) Allam describes FC Run, an open-source tool that Trigger.dev planned to release. It provides a Docker-like command-line interface for running containers in Firecracker VMs, then snapshotting and restoring them. The examples include running Alpine, snapshotting a live VM, and forking a VM. The reported save time is slightly under a second, while restore takes a few hundred milliseconds. Allam says the tool is intended to power Trigger.dev's future compute layer. ## Notable quotes - "The big difference there is code is sort of no longer orchestrating the LLM. LLM sort of orchestrates the code, right?" (05:30) - "An agent isn't like a transaction, it's like a session." (06:52) - "Instead of recreating the execution state from a log, we should use snapshot and restore." (09:24) - "We can get the snapshot down to like 14 megabytes compressed." (13:58) - "Snapshots are like slightly under a second, and restores are a couple hundred milliseconds." (14:19) ## Tools & references mentioned - Trigger.dev - Ruby on Rails - Node.js - LAMP stack - CRIU - Firecracker - FC Run - IBM mainframes - FFmpeg - Chrome - GitHub - Docker ## Who should watch - You are building agents that need to pause between user turns without keeping a machine running. - Your workflow system relies on replay and is becoming difficult to version or keep within journal limits. - You need files, memory, subprocesses, or running services to survive failures and resume later. ## Related talks - [From Stateless Nightmares to Durable Agents](https://aietalks.com/talks/from-stateless-nightmares-to-durable-agents) (Samuel Colvin, Pydantic, 22:13) - [Your Agents Need a Save Button](https://aietalks.com/talks/your-agents-need-a-save-button) (Hamza Tahir, ZenML, 17:07) - [Building Durable Agents with Workflow DevKit & AI SDK](https://aietalks.com/talks/building-durable-agents-with-workflow-devkit-ai-sdk) (Peter Wielander, Vercel, 1:09:49) - [Your agent architecture has a half-life of 6 months](https://aietalks.com/talks/your-agent-architecture-has-a-half-life-of-6-months) (Dan Farrelly, Inngest, 19:20) - [Building Durable, Production Ready Agents](https://aietalks.com/talks/building-durable-production-ready-agents) (Cornelia Davis, Temporal, 1:18:30)