Why Serious Agent Products Graduate From Serverless to Owned Execution Environments

Persistent AI agent infrastructure differs from serverless functions because it preserves the working environment along with the task’s recorded progress. Serious agent products move to execution environments they own when their workflows need persistent state, long-running execution, and isolation for generated code. The environment must survive between steps without charging for compute that runs the whole time.

What serverless was actually built for, and why agents fall outside that model

Serverless functions follow a narrow execution contract. An event arrives, a stateless function runs briefly, and the environment can be discarded afterward because state lives elsewhere. That contract suits webhook handlers, API glue, and sporadic one-shot tasks. A customer support agent that responds to a new ticket, calls an LLM, and returns an answer fits cleanly within it.

The mismatch begins when an agent needs more than an answer from a single invocation. Agents that maintain context, take consequential actions, or delegate through multi-hop chains depend on continuity across execution, memory, tooling, and governance. External storage can keep records even after the environment that made them is gone. A checked-out repository or configured browser is part of the working context.

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

One team building a complex agentic system encountered intermittent production timeouts during multi-step reasoning, external tool calls, and long-running streaming sessions. The cause was Vercel’s 300-second default execution limit. The agent’s work had not finished when its execution allowance expired. Moving to a Node.js runtime and setting an explicit maxDuration provided more breathing room, but the environment remained ephemeral between invocations.

Longer limits address only the immediate interruption. Twenty-five seconds can be adequate for a traditional API endpoint, yet disappear across multiple LLM calls, database lookups, and third-party integrations. The relevant duration is the time required for the whole chain. Extending that duration also does nothing to preserve installed dependencies or build artifacts after the environment is discarded.

Durable orchestration can extend a goal’s lifetime to months, but goal lifetime and environment lifetime are different requirements. A workflow can remember where to resume but lose the repository, native dependencies, warm cache, or browser profile it needs to pick up work quickly. A goal can last a long time without needing compute to run the whole time. They do, however, need a deliberate answer to what survives suspension when rebuilding the environment is slow, expensive, or unsafe.

Why cold starts and connection exhaustion compound into user-visible latency

An agent can stay within execution limits and still feel broken. In an e-commerce support deployment, sequential cold starts of one to two seconds per tool call could produce a six-second pause during an agent turn. A multi-step interaction therefore exposes startup costs that a single endpoint benchmark can obscure.

Connection management adds another source of pressure. Serverless environments struggle with persistent connections, and high concurrency can exhaust TCP limits and connection pools. Teams operating at scale have decoupled state management and moved session state and tool execution queues into HTTP-based external stores to sidestep connection exhaustion. Those changes address connection handling, but do not turn disposable execution into a persistent workspace.

With the stateless invocation pattern, each tool call can start without the warm context left by the previous call. As calls accumulate, startup becomes part of the interaction itself. Agents need a different latency contract, namely waking in under a second with context already present.

The idle-time illusion and why scale-to-zero billing punishes agents specifically

Agents spend much of their session lifetime waiting. In a large study of production coding-agent sessions, the median session ran LLM or tool calls for only 20% of its lifetime. The sandbox was still allocated while the agent waited between those steps. Charging for the whole session therefore charges for waiting as though the agent were doing useful work.

Scale-to-zero creates a structural dilemma for these workloads. Keeping the sandbox alive avoids reconstruction but incurs continuous idle compute charges. Tearing it down reduces sandbox cost while moving work into the next interaction, where the agent must recover its context. Repeated snapshot capture and restoration can also raise total customer cost by a large multiple, even when teardown substantially reduces the sandbox bill.

Agent economics depend on storage-priced sleep. An idle agent’s environment must be checkpointed so that compute can stop while its state remains available. Restoration must then be fast enough to avoid the user-visible penalties of rebuilding. Snapshot-and-restore scheduling supplies this model, but only if saving and restoring state is itself efficient. The economics depend on both sides of that condition.

What agents structurally need that serverless cannot provide and the four requirements

Fast resume is the first requirement. The latency failures establish that an agent must return from idle in under a second with context already in place. Resume performance must measure the time until the workspace is ready to use, including the time after a process starts.

State persistence is the second requirement because workflow records alone cannot keep an agent’s operating context. Filesystem contents, memory, installed dependencies, browser profiles, and credentials must survive between invocations. Goal lifecycle, execution lifecycle, workflow state, and agent memory are distinct concerns. Conflating them encourages either over-provisioning through always-on compute or under-provisioning through purely ephemeral execution.

Strong isolation is the third requirement for consequential tool use and generated code. Each agent needs its own kernel boundary rather than depending on a shared container kernel to separate untrusted workloads. The fourth requirement is pricing that fits traffic with bursts of work and long idle periods. Compute charges must cover only active use, with idle periods charged at the cost of storage.

Why Firecracker microVMs satisfy all four requirements where containers and FaaS cannot

Firecracker combines VM-level isolation with sub-second boot and low resource overhead. It boots in approximately 125ms and uses less than 5 MiB of memory overhead per VM, making fine-grained provisioning practical. Each microVM has its own kernel instance. Unlike Docker’s shared-kernel model, that boundary separates guest kernels and reduces the blast radius of badly behaved generated code.

The execution primitive provides isolation and startup speed, but it needs lifecycle management above it to keep state and charge for idle periods at the cost of storage. That distinction explains why microVMs can support the four requirements without implying that a bare VM automatically satisfies them. Containers do not have the same kernel separation, and stateless FaaS does not keep the environment between steps as agents need it to.

Industry adoption reinforces this architectural direction. Amazon Bedrock AgentCore Runtime uses Firecracker with one microVM per session and offers serverless microVMs as well as Instances running on AWS-managed EC2 in the customer’s own AWS account. AWS announced Lambda MicroVMs on June 22, 2026, as a dedicated Firecracker-based primitive for user-supplied or AI-generated code. It keeps in-session state, has dedicated HTTPS endpoints, and gives direct lifecycle control, showing that serverless delivery can work with persistent execution.

Copy-on-write forks allow branches of a running VM’s memory and disk, supporting patterns such as trying five fixes from the same starting state and keeping the one that passes. The environment becomes something an agent can branch. That capability makes isolation useful for the agent’s work as well as for security.

How snapshot-restore and speculative prewarming solve the remaining scheduling and latency problems

Efficient fleets require more than fast VM startup. Checkpointing must release idle resources cheaply, and scheduling must make an environment ready when the next tool call needs it. Otherwise, persistent environments reproduce the same choice between expensive reservations and slow on-demand execution. Research on incremental state capture and predictive scheduling addresses these remaining costs.

DeltaBox uses diff-based checkpoint and restore through deltaCheckpoint and deltaRestore. Its authors report checkpoint completion in 14ms and rollback in 5ms by capturing changes rather than repeatedly duplicating the complete sandbox state. Reducing that overhead makes frequent branching and rollback more practical for agents that explore inside a sandbox before committing changes.

SpecBox addresses readiness from the scheduling side. It uses keyword matching and streaming semantic embedding during LLM token generation to identify pending tool execution demands. Sandbox bootstrapping can then overlap with inference, while context-aware stochastic prefetching uses a sandbox dependency graph to anticipate later needs. Its authors report up to a 2.9× reduction in P99 end-to-end latency against an on-demand sandbox baseline, with substantially lower peak memory use than permanently reserved deployments.

These mechanisms address different parts of the idle-cost dilemma. Incremental checkpointing makes an environment cheaper to preserve, while speculative prewarming gets it ready during the time spent waiting for the model. Neither requires permanent reservation as the default. With snapshot-and-restore scheduling, they let sleeping agents in a fleet use storage and give active agents compute without making them wait for a full rebuild.

What the execution environment must expose to developers and the tooling layer above the VM

A microVM is necessary infrastructure. The tooling layer must expose usable tools, permissions, telemetry, and budget controls without requiring each product team to rebuild them. MCP, donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, in December 2025, has become the default interface between agents and external data. Leading production runtimes include the Claude Agent SDK, OpenAI Agents SDK, and Google ADK.

Protocol standardization does not remove execution responsibilities. Tools exposed through MCP still need authentication, per-user permissions, reliability, and observability. A single session can fan out into dozens to hundreds of tool calls in seconds, followed by long idle periods. The execution layer must handle that concurrency without making the protocol endpoint a bottleneck.

Observability must also follow the goal across executions. AgentCore Observability emits OpenTelemetry-compatible telemetry, but investigating a multi-day goal requires more than isolated invocation traces. Operators need a stable goal ID correlated with session and execution IDs, plan versions, tool operation IDs, and produced artifacts. Those relationships preserve the trajectory needed to understand work that spans pauses and resumptions.

Cost control requires similarly layered boundaries. A token budget for each request limits runaway loops, a budget for each task limits endless tool retries, a daily limit for each user caps abuse by that user, and a monthly budget for each tenant protects margin. Developer workflow completes this operational layer. The target deployment path is code to a live API endpoint in a single push, with no manual infrastructure configuration standing between the product and its execution environment.

The per-user agent fleet as the target architecture for agent-native products

The destination is one microVM per user, per agent. Each user’s agent gets a persistent, isolated environment. Its guest kernel and VM boundary reduce the risk that a failure or malicious action reaches neighboring tenants. Snapshot scheduling makes that separation economically viable even at thousands of users because most agents are idle most of the time.

Such an environment needs concrete operating capabilities. A persistent disk, a real kernel with package installation privileges, browser sessions, credential storage that survives sleep, and wake latency under one second distinguish it from a serverless workaround. These capabilities let the agent keep its installed context and the state it builds up as it works. Persistence becomes a product property.

That accumulated context also creates product defensibility. The longer an agent works in its environment, the more institutional knowledge and established working state make migration costly. Its value is not confined to the next isolated response. The product becomes a dedicated environment that belongs to its user, preserves their context, and runs their workflows, closer to a personal computer than a timeshared terminal. The per-user agent is the primitive that this infrastructure makes practical.