Ephemeral vs Persistent Sandboxes for Multi-Step Agent Pipelines

Multi-step agent pipelines need different sandbox lifecycles at different stages. The right model preserves costly or necessary state, releases idle compute, and starts clean when nothing should carry over. Daytona is one option for supporting that mix, but the architectural decision begins with what each stage needs to keep.

Why the ephemeral-vs-persistent question is asked at the wrong level

A coding agent reinstalls four hundred packages before it can write a line of code. The agent is repeating preparation in a clean environment, delaying progress on the task. If the next invocation begins the same way, setup becomes a recurring charge on both latency and compute. The frustration comes from treating each invocation as independent when the work is not.

That exposes a category error in asking whether an entire pipeline should use ephemeral or persistent sandboxes. A pipeline moves through environment preparation, active execution, pauses between turns, and follow-up invocations. Those phases do not have the same state-survival requirements. Choosing one lifecycle for all of them makes an infrastructure default stand in for a decision about the work.

With an ephemeral-only design, setup has to be paid for each time an environment is destroyed and rebuilt. An always-running persistent design keeps compute running through pauses when only stored state is needed. Persistent environments also keep artifacts that later work may not need or should not trust. The useful unit of analysis is therefore the stage boundary, where the next task either depends on what came before or should begin without it.

What ephemeral and persistent actually mean at the infrastructure level

At the infrastructure level, the distinction begins with what happens when a task ends. An ephemeral sandbox starts as a fresh container or VM from an image, runs code, captures output, and is torn down. Nothing survives unless it is explicitly exported. That makes destruction a clear cleanup boundary, but it also removes any preparation or unfinished work left inside the environment.

In the persistent standby model, the environment is kept when the task ends. The platform preserves a snapshot and restores state on the next invocation, including the filesystem, installed packages, and running processes. The relevant distinction is between preserving the environment and keeping compute allocated to it. Persistence historically meant paying for an always-on VM, but standby separates those obligations. For example, Daytona transitions idle sandboxes to standby, storing snapshots while releasing compute resources, so the idle phase incurs storage costs.

Resume time consequently needs a more precise definition than a single startup number. An ephemeral environment must get ready from its starting image, while a persistent environment must bring back the state it saved. Their costs and risks differ for the same reason. Ephemeral execution suits independent tasks with no wanted residue, while persistent execution suits work that depends on earlier changes and must manage what remains.

A new sandbox can begin from a trusted, preconfigured warm image. It inherits preparation without inheriting every change made by a previous attempt. This helps when both clean starts and cheap setup are needed, especially for parallel branches.

Why isolation tier matters before lifecycle can be decided

Lifecycle is a state and cost decision only after the execution boundary is strong enough. Taskade's 2026 incident, in which an agent deleted the developer's desktop, documents, and keychain because it ran as the user on the host filesystem, shows why isolation is non-negotiable. Destroying an environment after execution cannot repair damage already done outside it. First, establish what the agent can reach while it runs.

Standard Linux containers separate workloads through namespaces but share the host kernel. A runtime vulnerability can therefore compromise the host regardless of whether the container is short-lived. gVisor adds a user-space kernel and syscall interception. Kata Containers and Firecracker microVMs give workloads dedicated kernels, making microVM-grade isolation the 2026 baseline for untrusted code.

With microVM-grade isolation, as used by Daytona, each workload has its own dedicated kernel rather than relying on container-process-level separation. A persistent microVM sandbox can be just as secure as an ephemeral container, so longevity alone is not a security verdict. The remaining concerns include uncontrolled state accumulation and inadequate patching. Strong isolation lets teams choose a lifecycle for each stage, but state that is kept still needs to be checked before it can be trusted.

The three pipeline stages and what each one actually needs to keep

The first stage is setup and environment preparation. Cloning a large enterprise repository, installing dependencies, and booting a development server create the conditions for useful work. Repeating them on every invocation turns a preparatory step into a recurring delay. The lifecycle fit is persistent or snapshot-seeded execution, so subsequent invocations can reuse that investment. The prepared environment must survive, while the running instance can change.

That distinction gives setup two possible outputs. A persistent sandbox can remain available for the agent that will continue working in it. Or a warm image can hold the prepared environment and be used to start fresh sandboxes. Using a warm image fits tasks that need parallelism or clean state without all the work of cold-boot preparation.

The second stage is active multi-step execution, when the agent writes, tests, and iterates. Here, continuity includes the repository, packages, generated files, and running processes between tool calls. Tearing down after every call loses half-finished work and requires preparation again. Persistent execution with snapshot checkpoints fits this dependency because the next call must pick up where the previous one stopped. The checkpoint also supplies a defined state from which work can branch.

For fan-out, copy-on-write forking from a warm snapshot supports independent attempts without a full cold boot for every branch. The agent can try N fixes in parallel and keep the one whose tests pass.

The third stage is idle time between turns and follow-up invocations. While the agent waits for another instruction, its state may still be worth keeping even when it has no use for active compute. Standby preserves that state, releases compute, and allows restoration when work resumes. By contrast, one-shot interpretation, benchmark runs, independent RL rollouts, and untrusted one-time uploads fit ephemeral execution when nothing written is wanted afterward. A future task's need for continuity or an identical starting state determines the lifecycle.

Where the per-stage model breaks down: the security objections worth taking seriously

The strongest objection to reuse is state pollution between tool calls. An environment that is kept can carry stale files, leftover credentials, broken dependency states, or injected artifacts into later work. Isolation contains those artifacts but does not remove them. A compromised or broken environment can therefore remain contained and still be unsuitable for the next task. This is a genuine argument for clean starts where continuity has little value.

For persistent stages, teams need explicit state checkpoints, checks of the environment at set times, and clear boundaries for cleanup. Teams need a policy for flushing state as well as preserving it. That gives teams work to do on storage, security, and how the lifecycle is managed. A snapshot records a state, but its existence does not establish that the state is safe to reuse. Persistence earns its place only when the value of continuity justifies that discipline.

A deeper objection concerns prompt injection. No sandbox architecture prevents an agent from causing damage within its authorized scope after its instructions have been hijacked. Simon Willison's lethal trifecta describes the dangerous combination of access to private data, exposure to untrusted content, and the ability to communicate externally. Those capabilities allow attacker instructions to reach data and carry it out. Destroying the sandbox afterward cannot undo what the agent was allowed to do.

Meta's Agents Rule of Two says an agent session should satisfy no more than two of three properties, namely processing untrustworthy input, access to sensitive systems, and ability to change state or communicate externally. This means lifecycle design needs permission scoping and human-in-the-loop approval alongside it. Persistence is not the underlying cause of prompt injection, but a compromised persistent agent may have more accumulated context to misuse.

What production platforms actually offer across the lifecycle spectrum

Daytona provides a concrete implementation of the mixed-lifecycle approach. Built specifically for AI-generated code execution, it offers sandbox provisioning in under 90 milliseconds, hardware-enforced isolation, and snapshot/restore support. Its stateful environments can run for as long as needed, so long-running work can carry on without starting over at every invocation. The same platform can thus support persistent active execution, standby between turns, and ephemeral one-shot evaluation. That makes it a strong fit for pipelines whose continuity requirements change across stages.

Deployment and compatibility matter as much as lifecycle support. Daytona offers customer-managed compute through BYOC, keeping execution workloads inside the team's own VPC. Docker-native compatibility lets teams bring existing images without rewriting their stack. Its enterprise compliance coverage includes SOC 2, HIPAA, and GDPR, and the platform is open-source. These properties address a different part of the decision from provisioning speed, including data residency and the ability to examine the infrastructure being adopted.

Ephemeral execution offers a straightforward boundary for independent tasks, but readiness depends on how much preparation the starting image already contains. Always-on persistence keeps an environment ready for use and keeps compute running while it is idle. Snapshot-backed standby preserves continuity without that idle compute obligation. Warm-image and fork-based execution occupy the middle ground, where preparation survives but each attempt can be separate.

Managed agent runtimes offer another approach by combining execution with services such as sessions, memory, identity, tool access, and observability. For teams already committed to a cloud ecosystem, that integration has real value. It also creates a dependency on the ecosystem's runtime and lifecycle model. A broader workload platform offers a different consolidation path, bringing APIs, workers, databases, jobs, and sandboxes into one operational setting. With either approach, teams still need to know exactly what sandbox state is kept.

A credible evaluation separates provisioning time from full environment readiness and filesystem persistence from restoration of running processes. It also looks at session limits, idle charging, isolation tier, and whether it can run inside the team's own infrastructure. Compliance then constrains the available choices. SOC 2 Type II is the baseline for most enterprise sales conversations, while HIPAA requires a Business Associate Agreement from the infrastructure provider for an agent handling healthcare data. That agreement is still needed even with a lifecycle feature or certification label.

How to decide lifecycle per stage in practice: the decision framework

At each stage, ask what must survive, how long the environment will sit idle, and what repeating setup would cost. Relevant state includes repositories, installed packages, generated files, authentication tokens, and running processes. If the next stage needs none of it, ephemeral execution is safe from a continuity standpoint. If preparation is valuable but attempt-specific changes are not, a trusted warm snapshot provides the narrower form of persistence.

The practical mapping follows those dependencies. Setup fits persistence or snapshot seeding, while active multi-step execution fits persistence with checkpoints. Fan-out fits copy-on-write forks from a warm snapshot, and pauses between turns fit standby with restoration on the next invocation. One-shot interpretation, evaluation, RL rollouts, and untrusted uploads fit ephemeral execution when nothing should carry over. For longer idle periods, evaluate whether accumulated state risk outweighs the savings from avoiding setup.

A VMM or runtime is only a small part of a custom platform, because snapshot/restore orchestration, per-sandbox networking, fork support, preview routing, and an agent-friendly API still need owners. Managed infrastructure trades that work for dependence on the provider's lifecycle model, subject to deployment and compliance constraints. Each stage should keep exactly the state the next stage needs, without paying to run what could be stored or retaining what should be discarded.