Long-Horizon Agent Tasks Need a Process That Outlives Any Function Invocation
Agents keep progress through interruptions only on persistent runtimes.
Long-horizon agent tasks need persistent AI agent infrastructure rather than serverless functions because their working state must outlive any invocation. A persistent process with durable state, checkpoint-and-resume, and active-time billing lets an agent keep its progress when work is interrupted without paying to run the whole time it waits.
Why long-horizon agent tasks are a structural problem, not a capability problem
A single-turn benchmark gives an agent one chance to be right, while long-horizon work gives it dozens of chances to go quietly wrong. Each decision changes what the next one has to work with. StateM identifies the revealing failure pattern in which a model can solve the constituent steps but still loses mutable state, skips known procedures, or stops prematurely.
AGI House’s technical primer defines long-horizon work through tightly coupled, interdependent decisions. Its H1 category has many steps that depend on each other within one context window. H2 crosses context boundaries and requires externalized state and resumption, while H3 spans changing tasks and requires reusable skills that accumulate. These categories demand different infrastructure. Because small per-step failure rates add up, reliable execution needs to catch and correct drift as work runs, as well as improve the odds of one correct answer.
What are the limitations of running AI agents on serverless functions?
The files, dependencies, and partial results built up over a multi-day task need to survive even when an invocation’s local environment ends. Retrying an invocation does not restore that environment. The economic mismatch is separate but equally concrete, because agents wait on inference calls and external events while traditional reserved sandboxes continue billing for idle time.
StateM calls out mutable-state ambiguity when completed goals, pending dependencies, failed attempts, and valid next actions must be inferred from an append-only trace. Its control-signal dilution hypothesis describes another way things go wrong, when the plan and completion criteria get buried under commands, observations, and repairs. Neither problem is corrected by retry logic alone. Even a high probability of surviving each minute leaves a multi-hour run exposed to interruption, so the runtime needs a defined way to preserve position.
What the harness around the model must do that the model cannot do for itself
StateM shows that changing the execution system around a fixed model can fix failures that would otherwise be blamed on what the model can do. GPT-5.5 with its harness surpasses GPT-5.6 Sol Ultra on Terminal-Bench 2.1 without changing model weights. A frozen runbook transfers to a newer model without retuning and raises a smaller model above a larger model’s reference score. The surrounding control system changes the outcome.
The runtime organizes work around durable states, phase-local context, checked transitions, recoverable runbooks, and versioned procedural practices. Those mechanisms keep current instructions and verified progress available without asking the model to reconstruct them. LongHorizon-Harness also treats execution as task-state management, keeping explicit state outside execution and updating it with facts about the environment that have been checked independently. The model reasons about the work. The harness owns workflow control, memory, tool lifecycle, verification, enforcement, and recovery. AGI House’s two-pillar loop has an effect over the longer term, because harness trajectories become training data that lets models learn from execution practices that work.
Durable state outside the context window as the foundational primitive
Arbor’s Hypothesis Tree Refinement makes accumulated evidence an explicit structure by linking hypotheses, artifacts, evidence, and distilled insights in a persistent tree. A long-lived coordinator manages strategy over that tree while short-lived executors implement and test hypotheses in isolated worktrees. Results reshape the search frontier after executors finish. The state outlives the attempt that produced it.
Across six research tasks in model training, harness engineering, and data synthesis, Arbor reports more than 2.5× the average relative held-out gain of comparable coding agents that use the same interface and have the same resource budget. StateM approaches the same requirement through authoritative current state and refreshed phase-local control information.
Durable state therefore contains processed items, intermediate results, task-graph position, decision context, verified milestones, and known failures with their mitigations. It is not the entire conversation history. Preserving that growing trace as the recovery unit makes recovery slow and recreates the context-window constraint that external state is meant to remove.
Checkpoint-and-resume as the operational answer to interruption
A high per-minute survival probability does not guarantee an uninterrupted multi-hour run. Checkpointing makes that statistical exposure operationally manageable by limiting how much verified progress an interruption can erase. A crashed process reads saved state and continues. The useful checkpoint boundary is a meaningful unit of verified work. Excessive checkpointing spends time writing state, while sparse checkpointing leaves too much work exposed.
Firecracker provides a complementary mechanism at the machine level. A snapshot restore memory-maps the snapshot file, loads CPU state, and resumes execution without booting a kernel, running init, or restarting the agent. The cited November 2026 bare-metal benchmarks give a restore response time of 25 ms. This supports hibernation during inference waits, when the host checkpoints an inactive sandbox until the next call.
Resumption still needs attention to the guest clock. It remains frozen at snapshot time, so time-sensitive operations such as TLS certificate validation require clock resynchronization on resume.
Why a persistent process — not a container or a function — is the right carrier for agent state
A persistent microVM holds the filesystem, memory, and process tree, with snapshot-and-resume at hypervisor granularity. Persistence does not mean continuous CPU use. Sleeping machines can keep recoverable state without an active process using CPU, while per-second active-time billing charges for time spent running regardless of how long the task lasts.
A function remains scoped to an invocation, which suits stateless requests but does not itself preserve an agent’s accumulated environment. A container shares a kernel and does not itself provide hypervisor-level snapshots. Restarting its process is different from resuming an instruction stream.
DigitalOcean’s Managed Agents public preview adopts Firecracker microVMs per session, with isolation, networking, storage, and checkpoint restore managed by the platform. AWS Lambda MicroVMs, described in the 2026 research brief, similarly provides stateful execution environments with extended runtimes and suspend/resume preservation. The execution primitive determines what a service can do, regardless of whether the service has a serverless label.
How the coordinator–executor split maps onto persistent and ephemeral machines
Arbor’s coordinator–executor split follows directly from the different lifetimes of strategy and experiments. The coordinator keeps the hypothesis tree, decision log, task queue, and evidence base for as long as the research lasts. Its machine must persist through individual executor failures and completions. An executor needs only the environment for its assigned experiment. Its sandbox and disk can be deleted when that experiment ends, after results return to the persistent tree.
This separation also defines how work scales. The coordinator serializes decisions while many isolated executors run experiments in parallel and return results asynchronously. Disposable environments keep untrusted or generated code away from coordinator state, the host filesystem, and other users’ environments.
CUA-Gym’s 2026 architecture uses the same split for training at scale. Persistent trainer logic connects rollouts to thousands of parallel VM instances through a router that restores an episode snapshot. After termination, each VM resets to a clean snapshot and returns to the pool.
Running evals and RL rollouts at scale requires the same persistent-process primitive
SWE-bench Verified with strong agentic scaffolding can cost thousands of dollars for a single confidence-interval-grade evaluation run. The Holistic Agent Leaderboard spent tens of thousands of dollars on tens of thousands of rollouts across models and benchmarks. Environment economics become significant at this scale. Rollout infrastructure costs more without adding evidence when it lets environments use CPU while they are inactive.
CUA-Gym uses a pool of parallel OSWorld VM instances, restoring a snapshot for each episode and resetting the environment before release. At the described pool size, average VM utilization per training step is high, and rollout latency is not the training bottleneck. Snapshot pools separate reusable capacity from episode state. Idle VMs consume memory rather than CPU, while clean restores provide the starting point for independent runs.
GRPO-style training collects more rollouts per prompt, which gives more reason to keep execution separate from training. Agent Lightning assigns the execution loop to the harness while the trainer observes LLM request-response pairs. Its optional Collocated Async RL mode decouples collection from training steps, although its default trainer creates rollouts synchronously and waits for completion.
Computer-use agents need a persistent desktop, not a headless function
A desktop between agent actions is the accumulated result of the agent’s work, and losing it removes the environment the next action expects to manipulate. A headless function cannot substitute for that continuity. Healthcare EHR systems, Citrix environments, legacy loan origination systems, and document management systems also lack consistent accessibility APIs, making a persistent display essential for vision-based interaction.
Microsoft’s UFO² combines UI Automation, native app APIs, and vision through host and per-app agents. Its picture-in-picture virtual desktop lets the agent work without taking over the user’s desktop. UFO³ extends coordination across Windows, Linux, macOS, Android, and Web, where each device needs its own persistent session.
Vercel Labs released agent-desktop on October 30, 2026, providing computer use through operating-system accessibility trees on macOS, Windows, and Linux. Multiple agents can operate in parallel with separate cursors. Hybrid GUI and API agents need both the display session to last between actions and API clients to keep authentication state across calls.
Security and compliance properties that only a process-level boundary can provide
The NVIDIA AI red team says that running LLM-generated code without isolation can lead to remote code execution. Generated code must be treated as hostile. OWASP’s Q1 2026 exploit roundup maps the CustomMCP remote code execution flaw to ASI05, Unexpected Code Execution, and names sandbox execution and restricted outbound connectivity as mitigations. The runtime must constrain execution independently of the model’s judgment.
For this threat model, a process inside a shared-kernel container is not the required boundary. A dedicated microVM keeps each session separate through VM-level isolation, with support from default-deny policies and escape prevention. That boundary prevents the design from depending solely on application rules to separate users’ code, credentials, and environments. Persistence and isolation deal with different risks, but the same machine primitive can offer both.
Healthcare workloads also require immutable audit trails of AI-assisted decisions. Durable, versioned checkpoints can support a record of progress and recovery, connecting resilience with auditability. They provide supporting infrastructure for the broader controls required for HIPAA-compliant operation.
Choosing the right machine type for the task
The practical choice follows the lifetime of state and the trust boundary around execution. A persistent agent box suits coding agents, research agents, and coordinators that need their working environments to last through tool calls and human interruptions. It can sleep when idle and resume in about a second. A throwaway sandbox fits one experiment or a task involving generated or user-supplied code when no working state needs to survive completion. Its disk is deleted with the task.
For RL collection and batch evaluations, parallel sandbox swarms provide independent episodes from clean snapshots. Persistent desktop machines on Linux, Windows, or Android fit GUI applications, Citrix, EHR systems, and phone-only apps whose sessions must remain intact. Per-user machines suit products that handle untrusted code, PHI, or sensitive credentials for users who must be kept separate. Active-time billing makes that isolation compatible with intermittent use.
These machine types can coexist within one workflow.
