Session-Free Agent Design When Background Execution and Memory Must Outlive Any Single Process

Persistent and scheduled autonomous agents at scale need execution environments, session lifecycles, and persistent memory that can survive independently. Session-free design connects those layers through explicit handoff contracts, so a fresh process can resume coherent work.

Why session-bound execution is an architectural mistake, not just a limitation

The word “agent” implies something autonomous, persistent, and goal-directed. Yet much of the architecture behind that name delivers a chat loop with a clever wrapper. A session begins with a connection, holds the working state, and ends when that connection closes. Execution and memory end with it. Three logically independent concerns have been bound to the lifetime of one conversation.

That binding explains why a system can handle a single-step request yet fail at work that spans days. The model may be capable of the individual steps, but nothing around it was built to preserve their continuity. What happens when the process disappears between a decision and the next action? Without a clear record of the handoff, the next process cannot reliably tell what was done from what was planned, or which decisions still hold from which plans were dropped.

The Perception-Centered Architecture for Persistent Agents, or Pera, frames this shift as analogous to software engineering’s move from programming-in-the-small to programming-in-the-large. Bounded executions give way to persistent systems that must remain reliable as requirements and operating conditions change. Repeatedly restarting an agent without a handoff resembles onboarding an engineer who has no memory of yesterday’s shift, with the added difficulty that the system may mistake that fresh start for continuity.

The three concerns that must be separated before anything else can be designed

The execution environment is the compute substrate where reasoning and tool calls run. It can hold working state during a session without having to own that state for good. An environment may support a long sequence of dependent actions and still be disposable once everything needed for continuation has been externalized.

A session represents a logical unit of work, including its goal, plan, observations, and actions. Persistent memory has a broader lifetime still. It holds accumulated knowledge, preferences, and decisions that remain useful across many sessions, giving the agent continuity beyond any one task.

Picture an execution layer performing work, a session layer recording the work’s progress, and a memory layer preserving knowledge across runs. Each has its own lifecycle and interface. The execution layer can disappear while the session stays open, and the session can end while its useful lessons stay in memory.

The handoff contract specifies how those layers connect. It defines what execution must give the session record, what that record exposes to memory, and what memory supplies when a new environment resumes work. Pera describes persistent agents as continually perceiving changes across episodic tasks, internal context, and external signals. All of that cannot fit inside one context window or an object that dies with the process.

What the execution environment owes the rest of the system

The execution environment’s durable obligation is a faithful, complete record of what happened. Everything else about the environment should be disposable. That does not make it a simple sandbox, because agent work is multi-step, tool calls require controlled network access, and concurrent sessions need separation. At scale, creation latency and teardown reliability also become performance variables.

Isolation determines how well that separation holds. Ordinary container separation shares the host kernel, so a kernel vulnerability can expose the host node and other sessions. Firecracker microVMs give each session a lightweight VM with its own guest kernel through KVM. Kata Containers place OCI containers inside lightweight VMs through a pluggable VMM and fit container-orchestration-native operation. Both are appropriate choices for most production multi-tenant agent platforms.

gVisor offers a different balance by handling syscalls through a userspace kernel. Its lower overhead comes with I/O latency and syscall compatibility gaps. It is a reasonable middle ground for compute-heavy workloads where full VM overhead is not justified and application compatibility has been confirmed.

The same precision applies to filesystem and network boundaries. Filesystem access must be explicitly whitelisted before execution reaches the OS, because an LLM-driven tool cannot enforce its own limits. Network access must let tools do their work, but neither full lockdown nor unrestricted access is enough. Any state that will be needed later must be moved out of the disposable environment before teardown. Before it shuts down, the environment must write the session record as well as shut down cleanly.

Designing the session as a durable, resumable artifact

A session becomes durable when a fresh process can resume from its record. An append-only event log can preserve the recorded reasoning, tool calls, and observations needed to reconstruct working state. A fresh environment can then call wake(sessionId). Checkpoints give that reconstruction a durable starting point. A record that cannot support resumption is only a log.

The daemon/client inversion makes this possible operationally. An independent background server owns the execution queue and checkpoint store, while UI clients act as stateless observers. The direction of dependence is decisive here. Pizza Bot, developed at Amazon and released under the Apache 2.0 license, illustrates the distinction between a desktop UI that supervises an embedded api-server and an always-on standalone backend. Closing the UI stops the embedded server, so running in the background requires the standalone arrangement.

With that separation, a client disconnect need not interrupt progress. The agent can complete its step, persist the checkpoint, and wait, while a reconnecting client hydrates from durable state. HTTP and Server-Sent Events support reconnection and buffered event replay, but event replay does not replace checkpoints. Process supervision is still needed so that orphaned processes do not keep using resources after a parent crash.

Session initiation can then come from cron schedules or incoming webhooks. Human approval goes into the Action queue as an entry that survives a restart, without a blocking call, while the Unread queue holds finished runs. Approval can survive an indefinite pause and a restart. Sessions can also follow a resolved user identity from Slack to email and a later reply. The threads stay in their own channels, but decisions, plans, and in-flight work are shared under that identity.

Tiered memory as the contract between sessions

An intact session record does not guarantee useful continuity. The wrong knowledge may have been preserved, relevant knowledge may be hard to retrieve, or stale knowledge may appear current. What should the next session actually receive? Persistent memory answers that question, and its selection rules are as important as its ability to store data.

A three-tier design separates immediacy from reach. The hot layer keeps the last several turns verbatim in the active context window. The warm layer holds semantically scored recent history in a vector store, bridging the gap between active context and retrievable knowledge. The cold layer archives everything else in object storage for retrieval when explicitly needed. This cuts token cost by a lot while keeping older history even when it no longer fits in context.

Richer state can improve continuity while adding noise and increasing the chance that stale information resurfaces. Graph-hybrid stores add meaningful retrieval latency but improve relational reasoning across events from different sessions and times. The right tradeoff depends on whether the agent needs a recent fact or needs to link a series of past events. Neither need is satisfied by indiscriminately loading more history.

Memory also needs boundaries and revision rules. Runtime-resolved actor and session identifiers must scope namespaces so one user’s knowledge never appears in another’s context. Compression and retrieval must deal with context rot, which starts before the hard token limit is reached. Pera extends this responsibility to perceiving changes in internal context and using them to update service procedures proactively. Deciding what persists, what is compressed, and what is discarded is therefore a governance decision enforced by the runtime.

What the explicit handoff contract looks like in practice

Filesystem state needed for continuation must be externalized, and the durable session record must describe the progress that a replacement environment can actually recover. The order is consequential. A checkpoint that assumes files are available cannot support coherent resumption if those files existed only in the lost environment. Clean teardown is useful, but recovery must rest on durable artifacts.

At resume, the new environment mounts the same session storage so source files, build artifacts, installed packages, and git history remain intact. It receives memory retrieval results scoped to the session and actor, then replays the session log forward from the last checkpoint. These operations restore different kinds of state.

The agent’s first action should be a structured self-briefing. It reads its session record and retrieved context before continuing execution, much as an engineer reads yesterday’s notes before touching the code. In multi-agent runs spanning hundreds of requests, that briefing needs more than an undifferentiated transcript. A director’s working journal, annotated findings with credibility scores, and a chronological findings timeline preserve which sub-agent produced a result and why it deserves attention.

Resumption also needs a separate test of completion. A model’s confidence is not evidence that the work is finished, and partial completion presented with full confidence is a known failure mode. The handoff contract should therefore include a verification checkpoint evaluated by an external process or a separate model before the session is marked complete. This signal must remain distinct from the working agent’s own assessment. Otherwise, a confident but unfinished conclusion can become the starting assumption of the next run.

The EpistemicOps pattern makes the full cycle concrete. A local-first SRE agent runs a bounded reasoning loop over deterministic incident fixtures and writes a structured postmortem into Hindsight, a persistent memory layer. That layer consolidates postmortems into an evolving runbook. When a similar incident arrives, the agent recalls prior knowledge.

What purpose-built agent infrastructure provides that retrofitted tooling cannot

General-purpose cloud primitives can host these components, but they do not supply the agent lifecycle contract by themselves. Retrofitting persistence leaves the team responsible for making execution, checkpoints, approvals, and retrieval agree across failures. That is the infrastructure gap. An agent’s execution path is partly generated at runtime, so the system graph can change while the system is active rather than remain fixed like a conventional request path.

Firecracker and Kata Containers address isolated execution, while gVisor offers a workload-dependent alternative. Pizza Bot shows how background operation, durable approvals, and the inbox pattern work, while Hindsight provides persistent memory in the incident-investigation recipe. Choosing one component gives no assurance that the other lifecycle guarantees are in place.

A suitable runtime needs explicit session storage with resume semantics, managed checkpoints, identity-scoped memory, and durable approval queues. It must enforce filesystem and network boundaries below the application layer. Low-friction onboarding should also let a team run its first durable agent without writing checkpoint logic itself. Scheduled wakeups are insufficient if each wakeup starts without the state needed to advance the goal.

Pera distinguishes agents coordinating around a current user task from persistent agents adapting across a full service lifecycle. That distinction explains why task-oriented tooling needs a redesigned coordination layer. This abstraction is taking on a role like that of an operating system for applications, handling execution, state, and context beneath the logic that pursues the goal. For hundreds of long-running agents, the decisive question is whether that abstraction owns the handoff, or leaves every application team to rebuild it.