How Serverless Execution Boundaries Corrupt Multi-Step Agent State

Persistent AI agent infrastructure differs from serverless functions in what survives between executions. Serverless boundaries can corrupt the state of a multi-step agent when the plan it resumes no longer matches its workspace, process state, or committed external effects. Persistent VM environments keep local execution state so it need not be rebuilt after idle gaps, but safe recovery still depends on that state matching the outside world.

Why are serverless functions structurally incompatible with multi-step agent state?

An inconvenient boundary holds up work without changing what it means. A structurally unsafe boundary separates a decision from the state that justified it. Serverless functions fit short, stateless request/response cycles, but multi-step agents can rely on links between parts of their state that disposable invocations do not keep. The limitation applies specifically to agent workloads with those dependencies.

A 3-day goal may need only minutes of compute execution, with long waits between them. Agent memory is also not execution state. Recalling a conversation does not establish which plan version was active, which logical actions completed, or whether a tool operation committed before execution stopped.

Execution state includes artifact versions, approvals, tool operation IDs, retry counts, and compensation status. These determine what the agent may safely do next. A session identifier can connect invocations without preserving those facts or the environment they describe. The architectural mismatch begins when the application treats that identity as proof of uninterrupted execution.

The four categories of state an agent must carry across invocation boundaries

Safe to Resume? Breaking Execution Continuity of Agent Execution via Rollback distinguishes framework-state, workspace-state, and OS/VM-state checkpoints, while treating external effects as a separate outside-world concern. When choosing infrastructure, these are four categories of state that must agree with one another. They do not share a recovery scope. Restoring one category does not establish that the others match it.

Framework state includes the planner, model context, memory index, and persona configuration. Workspace state includes checked-out files, installed dependencies, build artifacts, browser profiles, and warm caches. A planner can therefore survive while its workspace does not. In that case, the next action follows a retained plan against an environment different from the one that produced it.

OS/VM state includes process handles, open file descriptors, network connections, and in-flight tool calls. The external effect ledger keeps track of which actions have already changed the outside world, including emails sent, payments submitted, and change sets pushed. Its records must agree with actual effects. An agent can return HTTP 200 for every invocation while propagating an incorrect prior state, because successful execution of each step does not establish continuity between steps.

How cold starts corrupt state before the agent executes a single step

Restoring a plan after a cold start does not restore its working environment. The new invocation lacks the prior process and cannot assume that its workspace survives. Reconstruction may produce a different starting point. For a coding agent, cloning a large repository and reinstalling dependencies is therefore both startup overhead and evidence of lost workspace continuity.

The rebuilt environment may be missing package versions pinned by an earlier step, partial build artifacts, or a browser session that was mid-authentication. A warm cache that changed execution behavior may also be absent. Process handles and open file descriptors do not reappear through repository reconstruction. Even before the first new action, the retained plan can refer to conditions that no longer hold.

Framework state can diverge at the same boundary. If the planner remained in process memory without being persisted, the new invocation resumes from an older recorded plan. That plan may precede the last committed external effect. The C/R study identifies external state mismatch as a failure mode in which restored internal state no longer agrees with its environment, making reconstruction a state-integrity problem.

How timeouts truncate execution state mid-plan, and why retrying is not recovery

A timeout creates a different break in continuity. Instead of rebuilding the environment before work begins, it terminates work after some actions may already have taken effect. The stopping point need not be a safe checkpoint. A Lambda durable function’s individual invocation still operates within the ordinary 15-minute Lambda timeout, so a long-lived goal does not remove the boundary around each compute interval.

Emails can be resent, API calls duplicated, and payments resubmitted while the restarted agent follows an apparently valid plan. The external world does not roll back. The study calls this unrecorded external effects, where internal recovery state lacks a record of effects that were already committed.

Durable orchestration provides a real partial answer. Step Functions and Lambda durable executions separate waiting from computing, allowing a goal to span multiple invocations without keeping compute active throughout. But that does not automatically save a plan that model output changed during execution. When the agent chooses its next branch after seeing new evidence, recovery must preserve that choice and its effects.

How forced teardown introduces the most dangerous class of inconsistency — security-relevant state carried across a boundary that was never valid

Forced teardown followed by partial restore can preserve a security decision while replacing the artifact that decision covered. A genuine approval or scan result can become unsafe when used with a different workspace, even if both the saved decision and the restored checkpoint are genuine.

The study illustrates this with a coding agent that removes malware from a repository, scans the cleaned version, and records a passing result. Rollback then restores the pre-cleanup workspace while retaining the post-scan agent state. The verification now describes the wrong artifact. If the agent releases that repository as verified, it acts on a judgment that never applied to the restored files.

The study demonstrates end-to-end attacks on Hermes, Cline, and LangGraph, including malware-verification bypass, unauthorized mail forwarding, and double payment. It finds five failure modes that recur and calls the requirement that governs them execution continuity. Security-relevant states, decisions, assumptions, and effects must all agree with a valid history of what ran. These attacks expose a gap in checkpoint scope.

Keeping more local state together leaves fewer chances for a mismatch during restore, but judgments kept in a saved environment may still lose their validity over time. External dependencies and effects remain outside the checkpoint. Safe continuation depends on both the fidelity of the restore and their agreement with the restored execution.

Why external state stores and durable orchestration cannot fully close the gap serverless creates

External stores preserve useful execution records across disposable invocations. Plan versions, logical action history, and approval records can all survive independently of a process. Durable orchestration preserves progress through a workflow. Together, these tools solve substantial parts of the problem, especially when a predetermined graph separates idempotent work from waiting.

Their limitation is the scope of that preservation. Writing an approval record does not preserve the filesystem to which the approval applied, while recording a tool operation ID does not preserve its live connection or process. Unsaved workspace state must be reconstructed. A database entry can describe an installed package, browser session, or artifact without restoring the environment in which it existed.

An external store may retain that an artifact passed validation, but the resumed workspace must still contain that artifact. Likewise, an orchestrator cannot checkpoint a change the model makes to a plan unless it has that change in its own state. Its workflow state and the agent’s execution state are related, but they are not interchangeable.

AgentCore’s session model similarly separates identity from compute. Its session ID is a continuity handle that leaves open whether a process survives or all four state categories remain aligned. External records can support recovery, but they do not by themselves preserve a filesystem, live process state, and effect ledger as one local continuation.

What VM-level persistence eliminates by design, and how snapshot-restore changes the economics of keeping it

A persistent micro-VM changes the unit that survives an idle gap. Instead of retaining selected application records and rebuilding the rest, it preserves the execution environment containing framework state, workspace state, process state, and the local effect ledger. Local reconstruction is no longer the default. A byte-level restore can bring those saved parts back together, without having to assemble pieces that were recovered separately.

Firecracker gives each agent its own micro-VM and Linux kernel, with isolation at the hardware virtualization boundary. The micro-VM can be snapshotted, hibernated, and restored without rebuilding its environment. This closes the local-state gap described earlier. It does not roll back a payment, restore an outside service, or turn an incomplete effect ledger into a complete one.

When isolated VM creation is slow, a warm pool hides startup latency by keeping capacity available and billable. Fast creation changes that trade-off. With snapshot-backed hibernation and restoration, the saved environment can stay in storage between periods of work without keeping compute running.

DeltaBox explores change-based checkpointing through two coordinated mechanisms. DeltaFS freezes the writable filesystem layer and inserts a new one, making updates copy-on-write and rollback a layer switch. DeltaCR handles process state through incremental dumps and forks from a frozen template process to bypass traditional restore pipelines. Both mechanisms make it less work to save states that are close to one another.

That economy depends on how much state changes. DeltaBox assumes that each checkpoint is much like the one before it, so larger file writes or memory churn in realistic agent traces can make delta costs approach full-state costs. Its millisecond-level results may therefore not generalize to every workload. Snapshot-restore changes the cost of continuity, but its benefit still depends on the state being preserved.

What this means for developers building agent-native products — choosing the infrastructure layer that matches the state model

The choice should start with the continuity the agent needs, while also taking goal duration and platform cost into account. Short, stateless steps with no external effects that must not be duplicated fit standard serverless invocation. Persistence adds little to those requirements. A long pause between steps that otherwise stand on their own is not enough reason to use a persistent environment.

Durable orchestration fits goals that span invocations when the plan graph is predetermined and steps are idempotent. Step Functions and Lambda durable executions can then manage the wait/compute split without preserving a working machine throughout. The workflow supplies the relevant continuity. This is a different requirement from retaining an evolving repository, browser session, or model-driven execution plan.

Persistent VM-level environments fit agents that require workspace continuity, preserve security-relevant state across steps, or revise plans at runtime in ways that depend on the live environment. In the per-user agent model, each user has an isolated VM that hibernates between sessions. A snapshot-restore scheduler allows compute charges to track actual work.

A stable goal identifier must correlate with session and execution IDs, plan and checkpoint versions, tool operation IDs, approvals, and produced artifacts so that an operator can reconstruct what happened across a boundary. Persistence does not replace that requirement. The governing design principle is to match the infrastructure layer to the state model, preserving the environment when safe continuation depends on more than recorded progress.