Keeping Background Agents Alive When Sessions Die, Queues Stall, and Hosts Restart

Keeping background agents alive through session drops, queue stalls, and host restarts requires infrastructure. Persistent and scheduled autonomous agents need three layers, which are durable state outside the context window, checkpoint-and-resume logic, and a runtime that expects failure. Google Agent Platform and Amazon Bedrock AgentCore provide parts of this foundation, but choosing infrastructure means checking which recovery responsibilities remain with the application.

Why background agents fail at the infrastructure layer, not the model layer

A background agent appears to reason continuously as it monitors email, checks queues, or runs a nightly code review. Underneath, it makes stateless API calls joined together by application code. The model remembers nothing between those calls. Remembering a preference or continuing after a crash depends on a state layer that saves context and supplies it again when execution resumes.

Could a very long context window solve this? It gives the model more working space, but that space remains finite and ephemeral. A multi-day task can outgrow it, while a process restart removes the active context regardless of its size unless the surrounding system restores it. A background agent is a daemon process, and keeping a conversation open alone will not keep it running. Its reliability depends on how work, state, and process lifetimes are managed.

The three distinct failure classes a background agent faces

When a session ends, the next session starts without its working history unless an explicit handoff restores it. The process need not crash for this to happen. A multi-step task can lose the thread, leaving the next session unable to tell which work is done and which work is left. The engineering response is persistent state paired with a way to reconstruct context.

Queue stalls break progress while leaving memory intact. A tool call can hang while waiting for a response, and without a timeout, no error arrives to trigger recovery. This is the “Infinite Wait” failure mode. Monitoring that looks only for errors can miss it while work accumulates behind the blocked call. The system needs a way to recognize that waiting has exceeded a limit and turn that condition into a recoverable failure.

Host restarts remove the executing process altogether, whether through deployments, configuration changes, maintenance, crashes, or OOM kills. Saved context alone cannot bring a dead process back. To recover, it also needs supervision and a durable record of work left to do. Silent memory pollution is another risk across all three classes. Zhang et al. (2026) describe an Exposure → Memory → Behavior pathway in which background content enters shared session context and shapes what happens later in the foreground, even without prompt injection. This makes separation of background ingestion and trusted memory part of both reliability and security.

Durable state that lives outside the context window

The first layer is a state store whose lifetime does not depend on a session. The agent’s append-only message log records observations, tool calls, and results, providing the history needed to recover. That log is the durable source of truth. SQLite, PostgreSQL, Redis, or a managed key-value store can provide storage for this pattern, provided the chosen setup preserves the record through failure. Without that record, a fresh session has no reliable account of what happened before it.

Four memory tiers serve different jobs, with different costs. In-context memory holds what the model can see now, making it useful for immediate work but expensive per token and lost when the session ends. An external key-value store holds structured facts such as user preferences, entity attributes, and task configuration for retrieval across sessions, with sub-millisecond reads. The episodic log preserves the sequence of actions and observations needed for crash recovery and session handoff. A semantic vector store retrieves past context by meaning when the log has grown too large to fit into the active context.

Retrieval by meaning is not the whole problem. A flat vector store can find similar passages without knowing how the facts in them fit together. A question such as “what did the client say about the budget after the contract was signed?” requires connections among entities and events. Graph-structured memory addresses that relational need. Testing a persistent memory layer must cover search quality as well as restart durability, multi-hop reasoning, multi-tenancy isolation, and feedback-driven improvement.

These tiers also need clear lifetime boundaries. Runtime session state and durable agent memory need separate systems because working context kept for a short time may not be fit to keep forever. The write path must preserve that distinction. The study’s pollution finding motivates a separate path for background observations, with an explicit promotion step before they enter long-term memory. Summarization, deduplication, and source attribution make that promotion deliberate rather than an accidental consequence of sharing a session.

Checkpoint-and-resume logic so any new session can pick up mid-task

Startup logic must read the saved state before it creates a fresh context, then pick up from the last completed step. Before each tool call, the agent writes its current messages, tasks still to do, and outputs made so far to the persistent store. Recording completion after the call then establishes the next recovery point. This is the “log is the agent” pattern, in which the execution history remains authoritative rather than competing with a separate account of what the agent supposedly did.

The checkpoint boundary determines how much work recovery repeats. Checkpointing after every tool call costs more than saving only at task boundaries, but limits recovery to replaying at most one tool call. Coarser checkpoints can require large portions of a task to run again. What must a new session know to continue coherently? Beyond completed actions, it needs the goal state and decisions already made, so it does not repeat answered questions, fetch the same data again, or contradict an earlier choice.

Foreground and background coordination adds another handoff boundary. Alibaba’s Qwen-Audio-3.1-Realtime (2026) describes a model in which the foreground submits a self-contained objective and the background works with its own tools and environment. Progress, permission requests, and terminal results stay linked to the originating task. That link must outlive the submitting session. Otherwise, saving the background worker’s history does not preserve the relationship between its work and the request that started it.

Managed platforms make parts of this coordination infrastructure-level features. Google Agent Platform provides Agent Sessions that persist conversation and event history, with custom session IDs that map to database or CRM records so a new runtime instance can locate the right state. Amazon Bedrock AgentCore separates long-running, EC2-backed Runtime Instances from its shorter-lived serverless microVM runtime. Both share identity controls and observability, while a lightweight orchestrator in a microVM can dispatch work to instances.

Queue-backed work ingestion and process supervision for host restarts

The runtime layer separates the arrival of work from the process that executes it. Schedules, webhooks, and events put jobs onto a queue. The agent pulls work when it can run. If it dies mid-task, unfinished work must remain recoverable for the next process instance beyond the lifetime of the original call. A schedule therefore supplies work that requires durable dispatch.

The key queue property is that unfinished claims expire. A Redis list, an SQS queue, or a database table with a claimed_at column can support the pattern, but the implementation needs a visibility timeout so uncompleted jobs become available again. A dead process must not hold work indefinitely. This queue behavior addresses lost ownership, while tool-call timeouts address a live worker that has stopped making progress. Neither mechanism replaces the other.

Process supervision supplies the next worker after a crash. PM2, systemd, or Kubernetes can restart the agent on unclean exit, after which startup logic automatically reads the checkpoint and resumes execution. For tasks that span days, Temporal-style durable execution adds a further layer by keeping workflow progress, retries, timeouts, signals, and durable timers outside the agent process.

The Temporal + AgentCore combination, described as a September 2026 prerelease, illustrates that division of responsibility. Temporal holds workflow state, while AgentCore supplies compute and identity controls. Under microVM pricing, idle CPU is not billed during I/O wait, although memory continues to be billed throughout the session. Identity must survive these compute changes too. Microsoft Copilot Autopilot uses Entra identity for agent instances, while AgentCore provides identity controls so permissions, audit trails, and memory lookups need not depend on an ephemeral process.

What infrastructure do hundreds of long-running agents need across all three layers?

At scale, the evaluation shifts from whether an agent can run to whether its whole lifecycle can recover. Persistent state management must provide or integrate with a durable store for the episodic log and structured memory. Checkpoint-aware execution must have built-in support for saving each step and recovering at startup. A durable work queue needs visibility timeouts and a dead-letter destination. These are separate requirements, even when a platform packages them together.

Health signals must distinguish an idle agent from a stuck one, while lifecycle management must connect automatic restart to checkpoint recovery. Identity, permissions, and audit history must carry through that restart. Write gates must keep background ingestion from becoming long-term memory on its own, especially when many agents and sessions share the infrastructure. Without these checks, running more agents also brings more unreliable context and repeated work.

Google’s platform fits the need for managed conversation and event history keyed to existing records. AgentCore fits teams that need long-running and shorter-lived compute tiers with shared identity controls and observability. Temporal-style orchestration addresses multi-day workflow state, retries, and timers, rather than replacing the agent’s compute environment. The shortlist identifies each option’s role while leaving its coverage of the full set of requirements to be checked.

A managed runtime reduces application plumbing, but the team inherits its checkpoint and resumption model. A developer-first agent operating system that installs with a single command and is built around the lifecycle offers another way to avoid building these pieces again for each project. The evaluation still needs all three layers. Because an agent can choose tools, delegate subtasks, and revise plans during execution, its operating layer must accommodate a changing execution graph.

Applying the three-layer pattern with concrete starting points for each failure class

Begin with the failure causing the most harm. For session drops, serialize the full message log and goal state to an external store at session end, and after every tool call for high-value tasks. At startup, look for a checkpoint keyed to the task or session ID before initializing new context. Keep background observations on a separate write path. Require explicit promotion through summarization, deduplication, and source attribution before those observations become long-term memory.

For queue stalls, route triggers through a queue with a visibility timeout and a dead-letter destination. Set a timeout on every tool call and treat expiry as a recoverable error, with retries and backoff. The memory-write path needs protection as well. If its worker stalls beyond a threshold, a circuit breaker should fail fast with an explicit error instead of allowing more work to queue behind the blocked worker.

For host restarts, put the process under systemd, PM2, or a Kubernetes Deployment with automatic restart and a startup hook that reads the checkpoint first. Move workflow state into a durable orchestrator when tasks span more than one process lifetime, preserving retry counts, timer state, and partial results. Give the agent an identity that stays the same across restarts. Permissions, memory lookups, and audit events should use that identity.

Incident investigation and long-running code review are useful first applications because both involve multi-step work that can run in parallel. Runbook lookup, deploy-history checks, and notification benefit from queue-backed dispatch and shared episodic memory. A restarted orchestrator can then reconstruct each worker’s progress without repeating completed steps. Adoption can remain incremental. Starting with an external checkpoint store and a queue with visibility timeouts, adding process supervision, and moving to a purpose-built runtime as task complexity and session duration grow allows adoption without a full architectural rewrite.