What a Persistent VM Actually Owns That Serverless Cannot Lease You

Persistent AI agent infrastructure differs from serverless functions in what survives between tasks. A persistent VM holds the agent’s disk, processes, software, sessions, and resumable memory image. Serverless functions treat compute as disposable, so agents that depend on that environment must rebuild it when compute disappears. The choice turns on what rebuilding costs.

Why do long-running AI agents fail on serverless infrastructure?

A longer timeout lets one execution run longer while leaving unchanged what survives when that execution environment is discarded. Serverless keeps durable state somewhere else, such as a database, an object store, or a queue. The function itself remains replaceable.

That contract is intentional and often useful. Disposable compute can scale to zero, avoid idle charges, and work with queues and durable workflows. The mismatch begins when an agent accumulates a checked-out repository, native dependencies, build artifacts, a warm cache, or a browser profile. Those are parts of its working environment.

A session ID can track a task that is still underway independently of the lifetime of its process. If compute stops because of inactivity, a failed health check, or a maximum lifetime, the next invocation may receive fresh compute. Continuity becomes valuable when throwing away the environment imposes a real reconstruction cost.

What the persistent VM actually holds that cannot be leased back after an invocation boundary

Local disk state includes repositories, generated files, package caches, and build outputs. A durable volume can preserve these through a stop. Disk persistence is not process persistence, however. Keeping the files does not keep the programs that were using them alive.

Running processes include a build daemon, a language server, a browser, or a local database. A fresh execution must restart them unless a restorable machine image preserves their runtime state.

Open sockets include TCP connections, WebSocket sessions, and authenticated API streams. They belong to a live execution environment. When that environment disappears, the new one must open connections again because it cannot load them like ordinary stored values.

Signed-in sessions include authenticated browser profiles, exchanged OAuth tokens, and active Citrix sessions. Credentials alone do not preserve the whole interaction. An agent may retain authentication material yet still need to reconstruct the live application session around it.

Installed dependencies include native binaries, language runtimes, CUDA stacks, and OS-level drivers. These belong to the machine’s software environment. An ephemeral replacement needs them installed or supplied through an initialized image before the agent can continue.

A resumable memory image includes loaded model weights, in-memory caches, and partially computed state. Snapshot-restore preserves the machine’s memory so that execution can resume.

Why RAM, processes, and open sockets cannot be preserved across serverless invocation boundaries

The decisive boundary is disposal. An execution environment may be there between calls, but being able to reuse it does not guarantee ownership of it. Once it is discarded, its RAM, subprocesses, and open connections are gone.

A running process includes more than its inputs. Its memory contains work already performed and state that has not necessarily been written to disk. A saved repository therefore cannot substitute for a running language server, just as a browser profile cannot substitute for a live browser instance. Restarting those programs is reconstruction, even when their files survive.

Writing everything to a database addresses a different problem. A database can retain goal progress, context, and a transaction log. It does not turn an open TCP stream into a portable record or preserve a desktop process merely by recording its last action. The record describes execution rather than preserving the environment that executed it.

In durable orchestration, Step Functions and Lambda durable executions make that distinction useful by separating waiting from computing, allowing a goal to pause without keeping compute active. They resume workflow progress from a checkpoint, potentially in a different process. Snapshot-based suspension offers a different contract by retaining machine state, although retained memory does not itself promise that an external connection will remain valid.

What signed-in sessions and installed software cost to reconstruct — and why agents cannot afford that cost per task

An agent that uses real software may have to pay the cost of setup again and again. Rebuilding may mean loading drivers, preparing native dependencies, starting applications, authenticating, and restoring working context before useful work begins. Repeating them turns a disposable environment into a continuing operational expense.

Authentication makes that expense harder to predict. Browser cookies and OAuth tokens are not the same thing as an uninterrupted signed-in desktop or Citrix session. When reconstruction requires re-authentication, an agent working with legacy Windows applications or healthcare EHR systems may encounter MFA, lockout policies, or session auditing. The consequence can be a blocked workflow.

Software installed at the OS level also takes work to set up again. An orchestrator can decide what happens next, but that control plane cannot take the place of the compute plane that holds the drivers, native binaries, and running applications. A persistent VM keeps that toolchain with the agent. Its value comes from avoiding repeated preparation.

Sleep-and-resume changes the economics of keeping it. With per-second billing and no idle compute charges for sleeping machines, preserving an environment need not mean paying continuously for running RAM and vCPU time. The snapshot still requires storage.

Computer-use agents expose the gap most clearly — a desktop is not a request

A desktop combines a running process, a rendered framebuffer, application context, and a signed-in session. Each action depends on that combined state. A mouse click has meaning because a particular window is open in a particular application.

Anthropic’s computer-use API gives a model screenshot, mouse, and keyboard control of a desktop environment. Anthropic recommends a dedicated VM or container with minimal privileges, a domain allowlist, and human confirmation for important decisions. That guidance treats the desktop as an environment to contain. It does not reduce it to a stateless function call.

Microsoft’s UFO² research project uses a different interface but shows the same need for the environment. Its “Desktop AgentOS” combines GUI actions with Windows APIs, while UFO³ Galaxy extends orchestration to Linux and Android. Window state, application context, and OS identity remain part of the work.

Agent S3’s OSWorld 1.0 performance of 72.6% with best-of-N was measured against persistent desktop VMs. The figure shows how the test was run but does not prove that the infrastructure is better in general. Legacy Windows, Citrix, and phone-only workloads make the underlying constraint more concrete because their required OS, drivers, and sessions cannot simply be replaced with a function runtime.

Why sandboxing LLM-generated code requires VM-level kernel isolation, not container boundaries

An agent that operates software may also execute generated code. That introduces a separate requirement from persistence. The environment must contain code that may be buggy, destructive, or influenced by prompt injection. Keeping a desktop alive is not enough if its execution boundary exposes the host.

Containers share the host kernel, while a VM has its own kernel behind a hypervisor boundary. That distinction defines the isolation being purchased. A container boundary is not an independent kernel boundary, so it cannot provide that same separation for untrusted execution.

Microsoft disclosed CVE-2026-25592 in February 2026, with a broader research disclosure in May 2026. The attack used prompt injection in agent frameworks to carry out host-level remote code execution. That is the relevant attack class here. The concern is not limited to whether generated code produces the wrong answer.

Firecracker and Cloud Hypervisor give each sandbox its own kernel. This keeps the host kernel outside the sandbox’s shared execution boundary. Disposable VMs also allow the sandbox disk and kernel to be discarded together. Persistence and disposal can thus do different jobs: keeping trusted working state and isolating untrusted execution for its task.

At eval and RL scale, the environment's throughput becomes the training bottleneck

One isolated agent environment becomes a different engineering problem when thousands of rollouts run in parallel. A training batch can generate thousands of code execution requests. If those requests overwhelm local CPU resources, GPUs wait for environment work to finish. The training bottleneck can move from model compute to environment throughput.

Generated code also makes shared execution unpredictable. Bugs and hard-to-kill threads can threaten the main training process. A dedicated isolated code environment service therefore becomes part of the training system. Provisioning speed alone is not enough. Execution, verification, teardown, and recovery all contribute to the time a batch takes.

DeepSeek’s DSec infrastructure, deployed starting with DeepSeek-V3.2 in 2026, separates rollout execution into an agent sandbox and a worker container. The sandbox hosts the scaffold and tools, while the worker manages it and provides a scaffold-agnostic control layer. Together they retain complete rollout state. A preempted GPU job can reconnect and continue without reconstructing execution through command-log replay.

Snapshot branching addresses the related cost of parallel starts. A snapshot captures the full in-memory state of a rollout in progress, allowing branches to begin from copies of that image. They need not repeat the preparation that produced it. A disposable function contract offers no equivalent continuity unless a separate mechanism preserves and restores the environment.

How Firecracker makes per-agent VM ownership economically viable at scale

Giving each agent a VM to keep sounds expensive if that means a conventional VM that runs all the time. Firecracker micro-VMs change that assumption through snapshot-restore and sleep-when-idle. An idle agent can be parked as a snapshot, releasing its active RAM and vCPU allocation. Ownership can outlast active compute billing.

The distinction between a parked snapshot and a resumed machine is important. Storage preserves the image while the machine sleeps, and restoration makes its memory and software environment available again. Installed packages, files, and in-memory work need not be rebuilt from scratch. External sessions and connections still depend on the services at their other ends.

AWS Lambda MicroVMs, launched June 22, 2026, illustrate how explicit lifecycle controls change the contract. They support building a MicroVM from a Dockerfile, snapshotting the initialized environment, and restoring dedicated instances through run, suspend, resume, and terminate hooks. When environments are suspended, compute billing stops, while snapshots keep memory and disk state for several hours.

The billing model completes the argument. Per-second charges with no idle compute charges let intermittently active agents retain useful environments without renting running compute continuously. Storage and active execution still have costs.

The right way to choose between ephemeral, durable-orchestration, and persistent-VM architectures for a given agent workload

The practical decision starts with what must survive. Ephemeral execution fits agents that are stateless between steps, including webhook responders, document classifiers, event-driven agents, and short-lived tool runners. If rebuilding the environment has no cost that can be measured, there is little to gain from keeping a machine. Serverless is the right shape for that work.

Durable orchestration fits goals that outlive a compute allocation but have cheap-to-reconstruct environments. Multi-step approvals and workflows waiting on external events belong here. They need to keep a record of progress but can do without a live browser, an open socket, or a desktop session. A long pause is not, by itself, a reason to preserve a VM.

Persistent or restorable VMs fit agents whose working environment is expensive or impossible to reconstruct. That includes desktop and legacy-software automation, snapshot-branching eval and RL workloads, and agents accumulating toolchains, build artifacts, or authenticated browser profiles. Untrusted generated code also needs kernel-isolation, even when its sandbox will be thrown away. For per-user agent products, VM-per-user ownership also gives disk, processes, sessions, and credentials a separate machine boundary.

Choosing an execution model requires moving from “How long does the task run?” to “What does the agent’s environment own, and what does it cost to destroy and rebuild that environment per task? Duration describes the schedule. The answer to the second question selects the execution model.