Session State Management Across Agent Restarts

An agent fails at step 14 of a 20-step task. If nothing checkpointed that progress, the agent restarts at step 1, burns through the same tokens twice, and because the underlying model isn't deterministic, the second run doesn't even match the first. That's the gap between a demo agent and a production one, and most teams building agents today have never once tested whether theirs survives it.

Separate this from hallucination, because people lump the two together and they aren't the same failure. A hallucination is loud: the agent says something wrong and you can point at it. A crash-and-restart failure is quiet. Nothing looks broken, yet the task runs long, costs more than it should, and comes back different or incomplete. You don't find out until you check the output against what you actually asked for.

Demos don't hit this problem because demos are short: one session, done in under a minute. Production agents run for hours, sometimes days, across dozens of steps with real tool calls and real side effects. Most agent frameworks were still built for the demo case; they're stateless by default, or they hand the whole problem to the developer with a shrug. If state lives in memory, a single server restart erases it (no warning, no partial recovery). That's the default failure mode of the entire category, and calling most of today's "production agents" production-ready is generous.

What "session state" actually contains and why it's harder to preserve than it looks

Session state sounds like it just means "the chat history." A running agent carries far more: the step it's on, every tool result it's accumulated, open file handles, intermediate files it's already written, environment variables, and whatever plan it built for itself before starting. Lose one of those on restart and the agent has to guess at everything from scratch, which defeats the entire purpose of checkpointing.

Most teams treat state as one bucket, and that's the mistake worth naming directly. Short-term state covers one task, start to finish: the message log for this run, how far it's gotten, what it's produced so far. Long-term state is what the agent should still know once that task ends, things like a user's preferences, decisions made in past sessions, skills picked up along the way. Short-term state can be thrown away once a task completes; long-term state can't. Throw away the wrong one and you either bloat every future session with junk or lose the thing that made the agent useful in the first place.

Serialization sounds simple until a tool result points at something alive: an open browser tab, a subprocess still running, a database connection that dies the moment the process does. You can't save a live resource. You decide what it means to resume it, or you accept that some things get torn down and rebuilt on restart instead of restored.

The tempting shortcut is stuffing the whole history into the prompt every time and calling it memory. Skip it. Every model has a hard ceiling on tokens, and even models advertising huge context windows get slower and more expensive as history grows. A 2025 study from Chroma tested 18 frontier models and found accuracy dropped by more than 30% for information buried in the middle of long conversations, an effect researchers call "lost in the middle." A bigger context window doesn't fix that; it just pushes the failure further out, which is worse, since it now shows up later, deeper into a task, after more work is already sunk into it.

Session state is an engineering problem with a structure to it. No amount of clever prompting changes that.

How checkpointing turns a crash into a recoverable event

Checkpointing is the mechanism that makes a crash boring instead of catastrophic. The loop: before running a step, write the full state to storage that survives a restart, then run the step. Succeeds, update the checkpoint. Crashes, reload the last good checkpoint and pick up at the next step, not step 1.

"Full state" at each checkpoint means the message log up to that point, the current step index, every tool result gathered so far, and any files the agent has already written. Miss one of those and recovery is partial, and partial recovery is just a slower version of the same failure.

This only works if the storage backend survives a restart, which rules out anything sitting in process memory. Redis, a database, a file-backed store, something outside the agent's own process that stays reachable even across a distributed system: that's the floor. LangGraph treats checkpointing as central to how it works: every node in the graph saves a state snapshot when it runs, which buys crash recovery for free and also unlocks something more useful, the ability to rewind to any prior checkpoint and inspect exactly what the agent knew at that moment. That's time-travel debugging, and it's also what makes human-in-the-loop interruption possible: pause an agent mid-task, let a person review it, resume from that exact point.

Checkpointing alone doesn't solve everything, and treating it as the whole answer is where a lot of teams stop too early. A checkpoint saved after 14 steps is still 14 steps of history the agent has to process on resume. Recovering from a crash and dealing with a bloated, ever-growing history are two separate problems, and checkpointing only solves the first one.

Tiered memory: how production agents manage history without drowning in it

The field has mostly landed on the same answer, and it's three approaches layered together.

Compaction summarizes the conversation as it grows, carefully enough to keep architectural decisions and branch points intact rather than just surface chatter. Structured external memory pushes progress files, checkpoints, and queryable databases outside the context window entirely, instead of stuffing them inside it. Sub-agent delegation breaks off a bounded subtask, runs it separately, and has it report back a compact summary instead of dumping its entire working history into the main thread.

The Stanford Generative Agents paper is the clearest demonstration of why this matters at scale. Researchers ran 25 simulated agents, each keeping a "memory stream," a full natural-language log of everything it observed. At retrieval time, the system scored those memories by recency, importance, and relevance rather than replaying the whole log. The payoff showed up in behavior: one agent spread a party invitation across the simulated town over two days, coordination that only worked because each agent held a coherent, queryable history of what it had seen and done, not a raw transcript ballooning with every tick of the simulation.

Querying for what's relevant now beats re-reading everything every time, and a good memory beats a big one, full stop. Any architecture that treats context window size as the solution to memory has the wrong target. Bigger context is a way to delay the bill, not pay it.

Tiered memory is the right architecture here, and that's exactly why building the stack from scratch rarely makes sense. Reinventing compaction, retrieval scoring, and sub-agent orchestration for every new agent project wastes a small team's time on a problem that's already been solved elsewhere.

How OpenClaw and Hermes implement session state differently — and what that means when you restart

OpenClaw and Hermes take genuinely different approaches, and the difference shows up the moment either one restarts.

OpenClaw stores sessions as append-only JSON event logs, memory backed by SQLite, with vector search layered on top for hybrid retrieval (BM25 keyword matching combined with vector similarity). That setup is built for recall: fast at pulling the right thing out of a long history, with less emphasis on the agent accumulating skill or judgment over time. OpenClaw has more than 345,000 GitHub stars, the most of any software project on GitHub, and version 2.0 shipped with 933 contributors and over 16,000 pull requests behind it. That's a codebase that's been through a lot of production use, and it shows in how the recall-first design holds up.

Hermes takes a different angle. It ships with persistent memory and more than 40 built-in tools, and cross-platform continuity is a deliberate design goal. Start a conversation on Telegram, keep going on Discord, or drop into a terminal instead, and the memory and session carry over with no reintroduction needed. The character of that memory tilts toward personalization and learning over time, less toward pure recall speed.

Some teams run both together: Hermes for reasoning and skill accumulation, OpenClaw for routing across channels. That split is legitimate when a project genuinely needs both strengths. But don't mistake the storage backend for a setting flipped later. Whether it's a JSON log or a persistent memory store, it's an architectural commitment. It decides what survives when the process dies and comes back up, and picking one after the system is already built costs far more than picking one before.

What per-user sandboxing adds to the state-management picture

Once more than one user runs an agent on shared infrastructure, state management stops being a performance question and becomes a security one. Shared state across users is dangerous, full stop. Treating it as a minor architectural detail is how one user's session context ends up leaking into another's, which is exactly the kind of bug that turns into a headline.

Per-user isolation means each agent gets its own disk, its own runtime, its own session state. A checkpoint for user A sits somewhere physically separate from user B's, no exceptions for convenience. Isolation matters here because a shared store makes deterministic recovery impossible: a crash recovery routine reading from a shared pool can pull in stale data, or worse, another user's data entirely.

Here's the failure mode that makes this concrete. A user submits a document for the agent to summarize, and buried in that document is a hidden prompt injection telling the agent to go read SSH keys off the host filesystem. Without per-agent isolation, that instruction has a real filesystem to reach. With it, the blast radius stops at that one sandbox, and nothing outside it is ever touched.

Isolation by itself isn't the finish line, either. Production sandboxes need immutable audit logs covering every network call, shell command, and file write, so nothing happens invisibly. They need outbound network filtering, because an agent writing a Python script has no legitimate reason to reach some IP address nobody recognizes. Credentials need to live as runtime configuration, never pasted into a prompt or checked into a manifest file. And the sandbox needs to support pause, snapshot, and resume, so it stops cleanly, captures its state, and comes back without losing anything.

Put together, this points to one rule, and it's not optional at scale: the right unit is one isolated, persistent agent per customer, provisioned automatically. Hand-configuring isolation for each new signup isn't a workaround, it's a ticking clock.

What managed hosting handles that self-hosting leaves to you

Self-hosting looks cheap right up until the checklist shows up in full: VPS provisioning, Docker environments, SSL certificates, persistent storage for checkpoints, sandbox isolation per user, uptime monitoring, crash recovery, keeping everything patched and updated. Every item on that list is a real decision with a real failure mode attached, and every state-management requirement covered so far (checkpointing, tiered memory, per-user isolation, audit logging, credential handling) has to get worked out before a single line of the agent's actual behavior gets written.

Managed platforms absorb a chunk of that list directly: the underlying servers, the Docker environments, SSL, per-agent isolation. Cloudways launched Managed AI Agents around OpenClaw and Hermes as one entry into this category, built for exactly this gap.

The tradeoff is easy to underestimate early on. Self-hosting keeps the dollar cost per agent low, but it moves all the operational weight (provisioning, monitoring, recovery) onto whoever's running the team. That math holds fine at ten users. It stops holding at a thousand, because hand-provisioning and manually recovering a separate agent instance for every new customer doesn't scale in a straight line; it compounds as the user count grows, and now someone's on call for all of them at once, every hour of every day.

Platforms offering one-click deployment of agents like OpenClaw, Hermes, Claude Code, and Codex, alongside a Cloud API that spins up an isolated, persistent, per-user sandbox with a single call, take that operational weight off the table. That frees a team to spend time on the agent's actual behavior instead of keeping servers alive. Pricing that bills per agent, per minute, rather than requiring a dedicated VPS per customer, changes the build-versus-buy math meaningfully once you're past a handful of users. Below that, self-hosting is fine. Above it, the math turns fast, and pretending otherwise is how teams end up buried in infrastructure work they never meant to sign up for.

How integrations interact with session state — and why connection persistence matters

Session state isn't only what an agent remembers. It's also what the agent is currently connected to: an authenticated Gmail session, a Slack workspace, a GitHub repo, whatever tools it's plugged into for the task at hand.

A restart puts all of that at risk in ways a checkpoint won't show. OAuth tokens expire mid-task, webhook subscriptions drop silently, and actions the agent queued up in some external system end up orphaned, sitting there with nobody watching them. A checkpoint captures the agent's internal state, separate from the state of every service it was talking to, so none of that shows up when you inspect a checkpoint file.

This is where a managed integration layer earns its place. Composio, for example, handles OAuth and API-key management across more than 100 SaaS toolkits, keeping token refresh and connection state separate from the agent's own runtime. If the integration layer tracks token lifecycle on its own, a restarted agent reconnects to Gmail or Slack or GitHub without walking back through an authentication flow. It just picks the connection back up where it left off.

That matters more than it sounds like on paper. An agent that resumes and can immediately touch its tools again is a fundamentally different product experience than one that dumps the user back into a "please reconnect your account" screen mid-task. For anyone running this across many users, the record of which user authorized which tool has to be stored per-user and has to survive a restart, same as everything else. It's one more reason per-user isolation and durable storage aren't optional past a single test user.

How to evaluate whether your agent's state management is production-ready

One test tells you more than any architecture diagram: kill your agent mid-task, on purpose, and watch what happens. If that sounds nerve-wracking to try, that's the signal, and it isn't a reason to skip it.

A handful of questions surface the real gaps fast. Where does state actually get written, and does that location survive a process restart? If it's sitting in memory, the answer is no. What's the granularity of the checkpoints, per step, per task, or per session? Coarser checkpoints mean more wasted work every time something fails. Is memory retrieval-based, or is it a raw log reread from the top every single time, and is each user's state physically separated, or is there a shared store somewhere that could let one user's context bleed into another's?

Run the same audit on integrations. List every external service the agent touches and check, don't assume, whether token state, webhook subscriptions, and queued actions are actually tracked somewhere durable. "It was probably fine" doesn't hold up during an incident, and it never will.

For anyone running this across multiple customers, add one more question: when a new user signs up, does their agent get its own isolated state store automatically, or does someone on the team have to go set that up by hand?

There's a tell for when this has gone sideways. If a team spends more hours tuning checkpoints, debugging sandbox recovery, and chasing token refresh bugs than actually improving what the agent can do, that's the build-versus-buy decision announcing itself. Building that infrastructure yourself past that point isn't dedication, it's a sunk-cost habit dressed up as engineering rigor.

Good state management is invisible by design. The agent resumes at step 15, reconnects to Gmail and Slack without missing a beat, and keeps going, and the user never even knows a restart happened. That's the whole test: if you can tell, it isn't working yet.