Understanding Session Persistence in Long-Running Agent Tasks

An agent that handles a clean demo without a hitch can fall apart three hours into a real job, and nobody on the team can say exactly where it went wrong. The usual response is to swap in a better model, assuming the failure is a reasoning problem. That response is almost always misdirected. Long-running agent tasks fail because most deployments don't have the infrastructure to hold on to state, recover cleanly after something breaks, and pick back up where they left off. Addy Osmani's taxonomy separates three things people lump together under "long-running": long-horizon reasoning, which is a model quality problem; long-running execution, which is an infrastructure problem; and persistent agency, which is a memory and identity problem. Mixing these up is how teams end up trying to fix an infrastructure gap by upgrading a model, which does nothing for the actual failure.

A task with a very high chance of surviving any single minute still only has a coin-flip chance of finishing a 60-minute job without some kind of interruption, once you compound that reliability across every minute of the run, and that compounding is why the failures stack up instead of staying flat. A preprint on months-long, LLM-assisted development work sorts the resulting failures into four kinds: knowledge loss, repeated work, context degradation, and silent memory death. The paper's core argument is that the fourth one reframes the other three, because without something watching the memory subsystem itself, the other three failures happen without anyone noticing.

The three walls every long-running agent hits, regardless of which model powers it

The same three walls appear regardless of which model or framework is used. The first is finite context that degrades before it's actually used up. The second is the total absence of persistent state once a session ends. The third is the lack of any reliable way for the agent to check its own work.

Context is the easiest wall to picture. Every context window has a hard limit, but long before an agent hits that limit, output quality starts slipping, a pattern usually called context rot. A 24-hour run simply will not fit inside any context window that exists today, so something has to decide, continuously, what gets carried forward and what gets compressed or thrown out. If that decision is left unmanaged, the agent runs out of room or starts producing worse answers well before it does.

The second wall is about what happens between sessions, not during them. Picture a construction site staffed in shifts, where each new crew shows up with zero memory of what the last crew built, decided, or ran into. That's the default state of most agent deployments at a session boundary. Nothing in the model itself knows what happened last session unless something outside the model wrote it down and handed it back. The gap is in the surrounding system that has to be closed with actual infrastructure, not a smarter model.

The third wall is quieter and more dangerous, because it doesn't look like failure at the time it happens. A model asked whether it's finished tends to say yes more often than the work actually supports. Without an independent check, separate from the agent's own judgment, a task can ship at a fraction of what was asked for, with the agent fully convinced it nailed it.

The five runtime primitives of session persistence

Session persistence is a stack of five distinct runtime primitives, and skipping any single one is enough to reproduce the failures above. Each has to be deliberately built or bought, not assumed to come free with a good model.

The first primitive is the session itself: the run log that survives even if the process hosting it crashes and restarts. In practice this is usually an append-only event log or a conversation store built specifically so it outlives the process that's writing to it.

The second is the harness, the orchestration layer responsible for driving model turns and tool calls until the task is actually done, without stalling out or quietly dropping work along the way. A good harness keeps the agent moving even when individual steps fail or time out.

The third is the sandbox: a boundary that keeps one workload's code, files, network access, and tools from leaking into another's. If one job goes wrong, whether through a bug or a security incident, the sandbox is what stops that failure from spreading to every other job running nearby.

The fourth is the checkpoint, the save point that lets a run resume without replaying everything that came before it. A practical rule of thumb is to checkpoint after every meaningful unit of work, such as after each document in a document pipeline or after each stage in a multi-stage job. Checkpoint too often and the system wastes I/O on saves nobody needed. Checkpoint too rarely and a single failure throws away real, completed work. What actually belongs in a checkpoint is narrow: which items have already been processed, intermediate results, the current position in the task list, and whatever context is needed to make the next decision. The full model context or entire conversation history doesn't belong there, because it grows too fast and makes recovery slow instead of fast.

The fifth is the trace, the record detailed enough that a person can debug and audit a long run after it's over, and it matters most for silent failures that never throw an error.

The message-queue approach applies here to the harness primitive. It separates "decide what to do" from "actually do the work," so either half can crash and restart on its own without the other side losing its place. That separation matters most when task execution time is unpredictable or when several tasks are running in parallel.

How the leading agents handle these primitives

No agent on the market covers all five primitives out of the box, and comparing how each one handles the stack shows where the operator still has to do the work.

Claude Code uses a five-tier compaction pipeline, building on context management techniques it introduced. Microcompaction offloads bulky tool results early in a session, and full auto-compaction kicks in as the session nears its context limit, producing a summary and a compaction block. That compaction is lossy by design: the plan an agent was following tends to survive, but the reasoning behind that plan often doesn't. The months-long development study calls this knowledge loss, and names it the most significant of the four failure kinds it tracked. The practical fix is to put anything the agent must always follow into a persistent file like CLAUDE.md rather than leaving it in session context, since compaction will eventually discard whatever lives only in that context. As of August 2026, Claude Code also supports an experimental, opt-in Agent Teams feature with shared task lists and direct messaging between teammates, along with Dynamic Workflows that scale out to dozens or hundreds of subagents. Running more agents in parallel raises the surface area for persistence problems.

OpenAI Codex solves the problem differently at the architecture level. It spins up a sandboxed virtual machine with the repository loaded, plans the work, executes it, runs tests, and hands back a diff along with a changeset ready for a pull request, which bakes the sandbox primitive directly into how the system executes. Codex's /goal command gives the agent a durable objective it keeps pursuing on its own across turns and interruptions, potentially spanning hours or days without a human checking in at every step. Paired with a memories feature for carrying context across sessions, this covers the harness side of persistent workflows. The trade-off is that per-run isolation is strong because of the sandboxed VM model, but cross-session memory rests on the memories feature specifically rather than on a continuous state store that persists by default.

OpenClaw takes a different shape. It's a local-first WebSocket gateway linking more than two dozen messaging surfaces, including WhatsApp, Telegram, Slack, Discord, and Signal, to an embedded agent runtime, with companion apps on macOS, iOS, and Android. Where Claude Code is a command-line coding harness tied to a single repository session, OpenClaw functions as a persistent control plane for assistance that spans many channels at once. Its persistence challenge is keeping identity and context continuous across those channels, not keeping a codebase continuous across compaction cycles.

Hermes, from Nous Research, is open-source and compatible with Claude, Codex, and ACP, built on a skill-based architecture with support for MCP. The primitives are all available to compose, but Hermes leaves the actual assembly to whoever is deploying it, rather than shipping a fixed opinion on how the stack should fit together.

Across all four, the pattern holds: every agent covers some primitives well and leaves others for the operator to build. Knowing exactly which ones are covered, and which aren't, is the first step toward knowing what the deployment layer still needs to add.

The four memory failure modes instrumented production use reveals

Months of real production use surface four distinct memory failure modes, and the most dangerous of them is the one that hides the other three from view.

The clearest example is repeated work. In one documented project, three separate sessions each independently proposed building a subsystem that had already been built and was sitting dormant, with the relevant design documents sitting right there in context each time. The agent wasn't failing to reason through the problem. It was failing to remember that the problem had already been solved, despite the evidence being available to read.

Knowledge loss is the companion failure to that one. Context compaction strips out the connective tissue behind long arcs of work, so the plan an agent was following often survives while the reasoning behind it doesn't. The agent keeps talking fluently, but it's working from a thinner and less grounded understanding of why it's doing what it's doing.

Context degradation occurs when teams try to fix knowledge loss the obvious way, by injecting more retrieved context back into the agent's working memory. That fix backfires, because the injected context isn't reliably relevant. Blocks of injected context that are only sometimes relevant train both the operator and, plausibly, the agent to skim past them, and once that channel has been learned as noise, it does more harm than having no context channel there.

The fourth failure mode is silent memory death, and it's the one that makes the other three invisible. The memory system itself, whether that's an index, an embedding server, or a hook pipeline, can degrade or die quietly while everyone keeps trusting its output, with no crash and no error message to flag it. The paper's central claim is that persistent agent memory is infrastructure, and infrastructure needs the same reliability engineering as any other critical system, including health checks with alarms that actually trigger action, heartbeats, freshness targets, and an alerting setup that doesn't waste the operator's attention on noise.

The mem0 State of AI Agent Memory report backs this up from a different angle, naming cross-session identity, temporal abstraction at scale, and memory staleness as the hardest open problems in the field right now. That lines up with what the production failures show: these aren't rare edge cases, they're the actual frontier the field is still working through.

Why stateless architectures break over idle time

The failure mode that gets the least attention is the one that happens when an agent pauses for days waiting on a person, a signature, or some outside event, and then has to resume into a context it can no longer reliably piece back together.

Google's ADK tutorial names three specific ways a stateless design breaks down over that kind of idle time. The first is prompt context pollution: after hundreds of turns spread across a workflow running for weeks, the conversation history fills up with irrelevant chatter, stale tool outputs, and duplicated instructions, and the model starts losing track of which step it's actually on. The second is token cost: replaying an entire multi-week conversation history on every single inference call burns through token budgets fast, since the cost scales with everything that's accumulated, not just with what's relevant now. The third is reasoning hallucination across idle time. When an agent pauses for days and comes back to a huge context dump, it frequently hallucinates steps that never happened, claiming approvals it never received or skipping steps it wrongly assumes were already finished.

HR onboarding shows this clearly. HR sends a welcome packet, days pass while the new employee signs paperwork, IT provisions accounts, more days pass while hardware ships, and HR eventually sends a day-one schedule. That is a background process with several pause-and-resume cycles, human approval gates along the way, and handoffs between teams. A stateless chatbot has no way to survive that kind of gap.

The fix isn't a bigger context window. It calls for a different architecture altogether, one where the agent's state is explicit, durable, and separate from raw chat history, built around something like a state machine that tells the agent exactly where it stands in the workflow at any moment, instead of asking it to reconstruct that position from old conversation turns. The same shape of problem occurs in invoice dispute resolution, in sales prospecting sequences, and in any workflow where a human or a third party sits in the critical path and the agent has no choice but to wait.

The tool-authentication layer: how credential expiry silently breaks long-running workflows

Even an agent with flawless state management will still fail, silently, if its tool credentials expire in the middle of a task. Most OAuth-based integrations are built around short sessions, well short of the multi-hour or multi-day runs long-running agents actually need.

The fast.io guide calls this out directly as its own failure category. Google OAuth access tokens expire after one hour. Slack's token rotation limits each token to 12 hours. Those windows are fine for a person clicking through a web app, but they're far too short for an agent working through a job that spans an afternoon, let alone several days. A task that runs past either limit needs its own plan for refreshing credentials mid-run, or it will stop making progress on a tool call with no clear error pointing back to the actual cause. That failure sits entirely outside the memory and state discussion covered above, and it's just as capable of quietly derailing a long-running agent as any of the primitives already named.