Session Continuity Across Agent Restarts and Migrations

Tata Steel runs more than 300 agents in production. At that scale, an agent that cannot survive a restart does not just annoy the person waiting on it. It throws away work, state, and external effects that cost real time and money to rebuild. A 2026 enterprise survey found that a majority of respondents had already reversed an agent action, and a significant share reported real revenue loss tied to agent failures. The cost of a bad resumption is a line item, not a hypothetical design flaw to fix later.

Once an agent accumulates state, meaning open tasks, partial decisions, external actions already taken, restarting it from zero is not a clean slate. Treating continuity as something to patch over with a friendlier error message, a retry button, a "sorry, let's start over" message, misses the actual problem. Whether the system has a durable, structured record of what the agent was doing, and a clear path to resume into that record rather than a blank context window, is the actual architectural problem.

This isn't just about crash recovery, either. Even within a single running session, agents hit the limits of their context window and have to compact: condensing older turns into a summary to make room for new ones. That compaction can blur the agent's sense of its own role, its current task, and the commitments it already made. It is a softer version of the same failure a full restart produces. Both point to the same underlying gap: without a deliberate architecture for what persists and how it gets restored, every agent is one process boundary away from forgetting who it is.

The session/memory distinction that most agent designs blur

Most of the confusion around agent continuity starts with a basic vocabulary problem: session and memory are not the same system, and they don't do the same job.

A session is one bounded unit of work. If something the agent learned or decided needs to matter tomorrow, it has to be written somewhere else, because the session itself disappears when it closes. That somewhere else is memory.

The model underneath an agent is stateless. Real memory, the kind that survives past the current session, has to be built as a separate system on top of that.

| Trait | Session context | Memory | |---|---|---| | Lifespan | One bounded run, gone when it ends | Persists across runs | | Location | The context window fed to the model | External store (database, vector index, file) | | Cost | Cheap, fast, but limited by window size | Slower to retrieve, but durable | | Use | What the model needs for this inference | What the agent needs to remain itself tomorrow |

Session context governs what enters the model's finite context window for a single inference. It's operational and temporary. Neither one is session continuity. Both are the same design error wearing different symptoms.

What state needs to survive a restart

Knowing that memory and session are different systems settles the conceptual point. It doesn't answer the practical one: once you've built a place for memory to live, what actually belongs there?

Working context covers the current task, recent tool outputs, and decisions the agent is actively weighing. This needs to be retrieved fast, but it doesn't need to live forever. A fast in-memory store is the right home for it.

Audit record covers the complete run history: every tool call, every outcome, every step the agent took. This needs to be immutable and complete rather than fast; it's there for correctness and compliance, not for helping the agent decide its next move.

A lightweight version of this same discipline appears in a pattern some practitioners already use without calling it architecture: writing a session-end spec. Don't just carry forward everything that was said.

That curation step matters because the alternative, dumping raw transcripts into long-term storage, creates a signal-to-noise problem that gets worse over time. Persisting everything is a tax that compounds, not safety.

Checkpoint-and-restore as the foundational recovery primitive

Once state is stratified by durability, the question becomes mechanical: how does the agent actually save and reload it? Checkpoint-and-restore is the standard answer, and it's the right one. But a checkpoint that restores faithfully is not automatically a checkpoint that resumes safely, and that gap is where the uncomfortable part of this argument lives.

The basic model is simple. This fits naturally with workflows that have clear phases, with regulated environments that need an audit trail, and with any situation where restarting from a saved point is cheaper than untangling a complex recovery path by hand.

Most advice stops at adding checkpoints, resuming from the last good one, and moving on. The study identifies five fundamental failure modes, spanning incomplete or inconsistent internal state, stale external dependencies, nondeterministic replay, and unrecorded external effects. Its core finding is blunt: correct rollback does not guarantee secure recovery.

A checkpoint can restore an agent's internal state exactly as it was, byte for byte, and still resume the agent into a situation that never actually existed. The state, the assumptions, and the external effects that were true at checkpoint time might not form a coherent, valid history once the world has moved on around them. The checkpoint is faithful to a moment. It is not necessarily faithful to the moment the agent now finds itself in.

The study's researchers demonstrated this isn't a theoretical edge case. The checkpoint did its job. The security model around it didn't.

Checkpoint-and-restore remains the foundational recovery primitive for agent systems. It just can't be treated as a solved problem the moment it's implemented. The state it restores and the external dependencies required for that state to make sense are two different things, and closing that gap is architecture work, not a configuration flag.

Hybrid memory layers giving the agent a coherent history to resume into

A single storage tier can't carry all of this weight. Resuming an agent coherently after a crash means pulling from multiple memory layers at once, each one restoring a different piece of what the agent needs to pick back up correctly.

Picture an agent mid-task when it crashes. On restart, it needs its working context back first: the fast in-memory store holds the current task state and recent tool outputs, and that's the first thing reloaded. Once it's back up and running normally, it archives new results to durable storage and updates its long-term summaries, so the next crash (if there is one) has fresh material to restore from. This is the hybrid memory pattern in practice: fast store for the present moment, vector store for relevant past, durable store for the permanent record, each one doing a job the others can't.

Letta, formerly known as MemGPT, builds this idea directly into its architecture. The agent behaves as though it has effectively unlimited memory, even though the context window feeding the model is fixed and finite.

None of this works, though, if the memory layer just keeps growing. If this step is skipped, the vector store slowly turns into the same raw-transcript problem described earlier, just moved one layer deeper.

The in-session compaction problem connects back to architecture here. When a running session condenses older turns into a summary to fit the context window, the agent can lose its grip on its own role and its outstanding commitments. Tiered external memory is the structural answer to that same pressure. By keeping a curated, consolidated version of history outside the context window entirely, the agent has somewhere stable to pull from, rather than relying on an in-window summary that degrades every time it gets re-compressed.

The runtime layer's role in making state survive across process boundaries

None of the memory design in the last section matters if nothing is actually watching the process. That's the runtime's job, not the model's, and not the framework's.

An AI agent runtime is the execution layer that runs agents once they're in production. The runtime is infrastructure. It's the thing that has to be running correctly for everything built on top of it, the memory tiers, the checkpoints, to actually do their job when a process restarts.

Agent workloads behave unlike a typical web request: they're long-running and event-driven. Getting that right requires the runtime to persist and restore all of that state on its own, so an agent isn't paying the same startup cost every single time it wakes back up.

A couple of research efforts have tried to formalize what this layer should look like. AIOS proposes something like an operating system built for LLM agents: it pulls resource management and LLM-specific services, scheduling, context, memory, storage, access control, out of individual agent applications and into a shared kernel that manages multiple concurrent agents at once. Quine takes a different but related approach, treating agents as native POSIX processes: an agent's identity is its process ID, its lifecycle follows the familiar fork, exec, and exit pattern from operating systems, and its persistent state lives in the process's memory, environment variables, and filesystem, inheriting the isolation guarantees the kernel already provides.

What both approaches share is the belief that these lifecycle guarantees belong at the platform level, not bolted onto each agent individually. An agent that can't persist its context or reattach cleanly after a restart is an expensive chatbot that happens to call some tools, not a lightweight agent, and what separates the two is what the runtime underneath it guarantees.

The migration contract: what must remain continuous when the agent moves

Restarting an agent on the same host is one problem. Moving it, to a new runtime, a new host, a new harness, is a harder one, because migration adds an identity question that a simple restart doesn't have to answer: is the agent that resumes actually the same agent, or just a successor that inherited its transcript?

RIPA, short for Runtime-Independent Persistent Agents, formalizes this as a lifecycle contract. The framework ties logical-entity persistence, verified memory transfer, and authorized state activation together through six continuity invariants and a migration protocol that spans changes to the reasoner, the harness, the host, and the interaction layer.

What that looks like in practice is visible in a real implementation. A different agent, or a different host, does not inherit that session, even if it asks for it.

The test results attached to that PR give the clearest evidence available for what correct reattachment actually looks like. Using Claude Agent ACP 0.70.0 and Codex ACP 1.6.2, testers on September 26, 2026 planted a codeword, restarted the agent into a brand-new working directory, and confirmed it could still recall the codeword. Session continuity across a directory change is achievable with lineage scoping that's defined correctly from the start, but it isn't guaranteed by default.

That same work also surfaces a subtler failure mode: the session-ID and workspace can decouple. The memory is correct. The actions it produces aren't, because they're being taken against the wrong environment.

Identity across channels: the surface-portability dimension of continuity

Migration doesn't only happen between hosts and runtimes. It happens every time a user moves between channels, Slack to email, email to a CLI, and multi-channel agents run into their own version of the lineage break described above.

The complication starts with something mundane: different platforms identify users differently. Without it, sessions fragment every time someone switches surfaces.

Red Hat's multichannel IT self-service agent, deployed in February 2026, shows this working in production. The canonical UUID is what makes that resumption possible: it's the fixed point the system can anchor to no matter which surface-specific identifier shows up on any given turn.

Making this work depends on keeping two kinds of identity clearly separate. Collapse those two into one and the failure is predictable: a user who starts a conversation on Slack and continues it over email ends up starting a brand-new session, because the system has no way to recognize that the same person is on both ends.

Observability and silent failures: how to know when continuity has broken

The most expensive continuity failures are the ones that resume cleanly, pass every health check, and still hand the agent a stale or inconsistent view of the world, producing confident, wrong action from a system that looks, on paper, like it's working fine.

The checkpoint-rollback security study names this directly: unrecorded external effects as a fundamental failure mode. The agent's internal state restores perfectly. The external world, the one the agent is actually supposed to be acting in, has moved on without it. Double payments, unauthorized forwarding, and malware-verification bypass all trace back to exactly this gap between what the checkpoint restored and what had actually already happened in the real system.

FUJISOFT's experience deploying on AgentCore makes the same point from the operations side. What changed that was production trace analysis that ranked failure patterns by actual impact, giving the team a way to see which silent failures mattered before they became expensive ones.

That's the thread running through this entire argument. Session continuity is a set of decisions, about what state to keep, how to checkpoint it safely, how to layer memory so resumption is coherent, how a runtime enforces all of it across restarts and migrations, and how identity holds together across channels, that has to be made deliberately, at the architecture level, before an agent is trusted to run unattended, not a feature to bolt on once an agent is working. The agents already operating at the scale of Tata Steel's 300-plus or Cognizant's 200-plus aren't waiting for that architecture to mature.