What Agent Products Actually Do When a Task Outlives the Function That Started It

Persistent AI agent infrastructure keeps task progress, context, and authority across executions in a way that serverless functions do not. When a task outlives the function that started it, a longer timeout is not enough. Reliable completion requires checkpointing, explicit workflow recovery, and a separation between durable state and disposable compute.

Why tasks outlive the functions that start them

Cloud functions have hard limits on how long they can run, but research pipelines, compliance document analysis, and week-long content workflows can take longer. The failure is not simply that execution stops. If progress exists only inside the originating process, termination also destroys the information needed to continue. A function timeout thus causes the workflow to fail when the product ties the life of the task to the life of the process.

Agents in the Large: Perception-Centered Architecture for Persistent Agents distinguishes a longer-running task agent from one that organizes conditions that survive individual tasks. The Pera paper also notes that effective task horizons remain much shorter than extended runs, with progress often plateauing.

Three different requirements are involved here. Long-horizon reasoning deals with dependent planning, long-running execution involves processes that make many model invocations, and persistent agency keeps identity and state across tasks. Confusing them produces the wrong architectural response. Once work exceeds its originating process, the concrete decisions are how to checkpoint state, resume mid-workflow, and separate durable context from ephemeral execution.

What "state" actually means for an agent that must survive a process death

Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents treats the agent’s operative system as more than retrievable memory. It includes task commitments, trigger conditions, permissions, credentials, provenance, and external effects. These records have different governance requirements. A preference can be revised, while an audit record has a different purpose and a credential grants authority.

The distinction prevents a single undifferentiated memory store from serving every need. Working memory is the fast context window with limited space, and episodic memory keeps the history of recent sessions, which can be summarized. Semantic memory holds facts and preferences queried on demand, while procedural memory holds instructions and learned behaviors, often in an archival vector store. The orchestration layer controls promotion between these tiers.

That model explains retrieval, but not all recovery obligations. Task state must keep commitments, and credential state must live on without letting another agent access it. Authority, scope, mutability, provenance, recoverability, and actionability determine how each record is handled. Anything retained only in process memory disappears with the process, regardless of its significance to the next task.

Checkpointing: the first and most portable recovery primitive

Checkpointing writes the minimum resumption record to stable storage after a meaningful unit of work. That record holds the items already processed, intermediate results, the place reached in the task, and the context needed to make later decisions. After a crash, execution reads the record and continues from the saved position. It need not reconstruct the entire run from conversation history.

The checkpoint should stay smaller than working memory. Saving the full model context or every interaction makes records grow and slows recovery, but saving too little leaves the next worker without what it needs to go on. Cadence presents a similar trade-off. Writes after each document or pipeline stage align recovery with completed work, whereas a fixed timer may not.

Local files can work for agents on a single machine, while agents that work together and progress that people need to see call for shared persistent storage. Object storage such as S3 or GCS offers durability without itself supplying the collaboration layer. Writing state from time to time adds overhead, but restarting a long task that failed uses compute, tokens, and time all over again.

Recovery still has a sharp limit. A checkpoint can restore the agent’s position without undoing an external action already committed. Resuming execution and reversing its consequences are separate capabilities.

Decoupling execution from orchestration with message queues and task ledgers

A checkpoint protects progress, but it does not protect an orchestrator blocked on a long direct call. In that model, the orchestrator waits throughout execution and can lose its account of in-flight work if it crashes, even when the worker completes. A queue separates those lifetimes. The orchestrator publishes work, a worker executes it and publishes a result, and each component can restart independently.

This separation also permits parallel work and independent worker scaling. It is not free of operational cost. For short tasks with little parallelism, queue infrastructure can add more complexity than it removes. Its justification strengthens when execution takes a long or unpredictable amount of time.

The ledger, however, is the durable workflow record. It distinguishes dispatched steps, completed steps, and steps that committed external effects, independently of the worker that performed them. LangGraph shows how a workflow is built through a directed graph of decision steps, tool calls, and data flow. A ledger that also records which step produced an output and under which policy supplies provenance for audit and possible rollback. A queue alone does not provide that account.

The return arc: updating, forgetting, and rolling back state

The Always-On survey identifies an imbalance between accumulating state and governing what happens afterward. Writing and retrieving receive more attention than updating, forgetting, auditing, and rolling back. This return arc exposes production failures that successful retrieval can conceal. An agent may remember accurately what it once believed while continuing to act on information that has since changed.

Revision is not the same as propagation. Correcting a factual record does not automatically correct downstream state or actions derived from the old belief. Likewise, excluding a record from search results is not erasure of the underlying data. Without an account of which memory informed which action, debugging behavior over time becomes nearly impossible.

Validation addresses an earlier part of this problem. Checking new state against existing state before commitment prevents contradictory beliefs from accumulating unchecked. Consolidation then keeps long-term memory usable by summarizing history, merging redundancies, resolving conflicts, and discarding noise. That governance work belongs asynchronously in idle time.

Pera places adaptation at the lifecycle-control layer, beyond individual task execution. Persistent service requires responding to changes in the agent and its environment. Accumulation without that control preserves obsolete conditions as readily as useful knowledge.

Why micro-VM isolation is the right execution boundary for persistent agents

An agent that retains a user’s authority across sessions must not expose it to sibling workloads while installing packages, running shell commands, or executing generated code. Shared process boundaries are insufficient for this workload. If another agent can reach its credential store or filesystem, the per-user model has already failed.

Firecracker microVMs give workloads separate kernels through KVM hardware virtualization. That boundary separates untrusted execution from the shared-kernel model, while approximately 125-millisecond boot times keep runtime overhead small. Snapshot-restore addresses the remaining initialization work. A prepared environment with tools loaded and a warmed memory index can be captured and restored for each session.

Managed products use this execution pattern, but the state architecture is still needed. Amazon Bedrock AgentCore Tools provisions a dedicated Firecracker microVM for each Code Interpreter or Browser session. Deno Sandbox, announced in beta February 3, 2026, also uses a dedicated Firecracker microVM per sandbox. These boundaries still require orchestration and visibility. A self-managed fleet must build observability that reaches across the VM boundary without undermining isolation, which is a substantial distinction between managed and self-hosted approaches.

How snapshot-restore and idle scheduling change the economics of per-user agents

Keeping every user’s agent in memory is simple but costs a lot. Most agents are idle most of the time, so a resident fleet pays for memory that is not doing useful work. Pure scale-to-zero gets rid of that cost but adds cold-start latency. Interactive products expose that delay directly to the user rather than absorbing it inside a background batch job.

Snapshot-restore changes what the operator retains during inactivity. The initialized environment is saved, compute is released, and the next invocation restores it. Idle compute becomes idle storage. The same mechanism that makes recovery fast thus lowers the cost of deploying an agent for each user when those agents do little work.

It does not eliminate the rest of the cost model. The Always-On survey treats resident state, retrieval, and consolidation as resource-governance concerns across execution substrates. A snapshot cuts the cost of keeping an agent in memory, but the durable stores and the work to maintain them still use resources. The relevant comparison with serverless functions is consequently not just invocation cost. It is the cost of preserving a usable agent between invocations, including the latency required to bring it back.

What the per-user agent pattern demands from multi-tenant infrastructure

A shared API key or OAuth app can turn one customer’s bulk operation into another customer’s intermittent failure. The first tenant consumes shared quota, and unrelated agents encounter rate limits. VM isolation does not itself separate that quota. Tenant-specific access and quota boundaries address a different failure mode from runtime containment.

Credential bleed requires containment at the execution boundary. A compromised agent must not reach sibling tools, credentials, or data through the network or filesystem. Per-agent VMs with scoped permissions enforce that separation. This follows directly from the earlier state taxonomy, where credential and permission records grant authority and therefore cannot be treated as globally shared context.

MCP uses OAuth 2.1 authorization code flow with PKCE for scoped grants, without requiring the agent to handle the user’s credentials directly. Consent visibility and revocation depend on the external authorization server. Per-tenant policy must also be enforced during execution.

When a tenant leaves or revokes consent, hiding its records from retrieval is not actual erasure.

Where to insert humans into long-running workflows without breaking them

Human approval belongs at predefined workflow boundaries, especially before irreversible external actions or when an instruction is ambiguous and confidence is low. Sending an email, committing a transaction, and deleting a record are concrete examples. These pauses are architectural features. Their placement must be known before autonomous execution reaches them.

The ledger must represent “waiting for approval” as a legitimate state. At that boundary, the agent can snapshot its environment, release compute, and restore when approval arrives. A human wait then uses the same persistence mechanism as technical recovery. The workflow can remain suspended without losing its position or consuming idle compute.

Approval does reduce uninterrupted automation at that point. However, a well-placed checkpoint requires one human decision before a consequential action, while correcting a wrong committed action may be costly or impossible. The rollback gap makes that distinction concrete. Human checkpoints preserve automation around a decision that the recovery machinery cannot safely reverse.

What building a production persistent agent actually requires, end to end

The types of state set the needs for storage, which shape how checkpoint and recovery work. Recovery then interacts with orchestration, while credential authority constrains the execution boundary. That boundary determines available idle scheduling, and idle scheduling shapes the economics of deploying an agent per user.

Validation, revision propagation, erasure, provenance, and rollback govern what survives and what consequences remain attributable. A runtime can restore perfectly while restoring contradictory beliefs or obsolete permissions. Reliable execution therefore depends on the governance of the state it resumes.

Pera describes the shift as moving from “programming in the small” to “programming in the large.” The subject is software architecture for sustained service. Managed isolation and snapshot mechanisms can absorb infrastructure work, but they do not decide which records bind the agent to future actions.

For teams choosing between persistent agent infrastructure and serverless functions, the decisive questions concern state survival, auditable external effects, tenant authority, and idle cost at the intended fleet size. Functions can supply bounded execution within that design. The product depends on the durable workflow around them to finish the work.