Agent persistent session state, the rollover trap nobody warns you about

The trap

You build an agent. You give every conversation a session ID. You store messages in a row stamped with that session ID. You think you are done. The first month you run it against a live model, you watch a rate limit fire on someone’s conversation, and you watch the next reply come back as though the model never met them.

The reason is that the SDK you are running on top of did exactly what its docs said it would: it detected the session was unusable, rolled forward to a fresh session ID, and accepted a preamble of prior context. It just did not tell your message store that the rollover happened. Your priorContext lookup is filtering by the new session ID. The pre-rollover messages, stamped with the old one, are stranded in the same table, three rows away.

This is the rollover trap. It is the actual reason most agent persistent session state implementations look fine on a happy path and fall apart in a real production week. The fix is structural, not defensive: the upstream session ID is not the conversation’s identity. The conversation has its own identity, and the upstream ID is a transient handle the conversation has held.

What rollover actually looks like

Walk through one rate-limit scenario, two turns apart, on the same logical conversation. The host is a Swift app, the bridge is a Node process running the Anthropic Agent SDK, the model is Claude. The exact actors do not matter. The shape is what matters.

On turn 3, the host writes a message stamped with B. On turn 4, your priorContext lookup runs WHERE session_id = ? against the current upstream ID, which is B, and quietly leaves turn 1 (stamped A) out of the preamble. The model wakes up with the conversation half-amputated. It still replies, because models are good at filling in plausible context, but the user notices that the agent has somehow forgotten the thing it agreed to do four minutes ago.

The lookup is not wrong. The schema is not wrong. The data is all there, in the same table, on disk. The wrong thing is the assumption that the conversation and the upstream session share an identity. They do not.

The chain pattern

Once you accept the upstream ID as transient, the implementation is small. The conversation has a stable client-generated identity, written exactly once when the user opens a new chat. Alongside it, you keep an append-only list of every upstream session ID this conversation has ever owned. Every time the SDK hands the host a new upstream ID, you append. The chain does not care about the order of failures, only that it has them all.

// Desktop/Sources/Providers/ChatProvider.swift
private static let sessionChainMaxSize = 16
private static let sessionChainSuffix = "_chain"

private static func appendToSessionChain(_ id: String, storageKey: String) {
    let trimmed = id.trimmingCharacters(in: .whitespaces)
    guard !trimmed.isEmpty else { return }
    let chainK = chainKey(forStorageKey: storageKey)
    var chain = UserDefaults.standard.stringArray(forKey: chainK) ?? []
    if chain.last == trimmed { return }
    chain.removeAll { $0 == trimmed }
    chain.append(trimmed)
    if chain.count > sessionChainMaxSize {
        chain = Array(chain.suffix(sessionChainMaxSize))
    }
    UserDefaults.standard.set(chain, forKey: chainK)
}

private static func persistSessionId(_ id: String, storageKey: String) {
    guard !id.isEmpty else { return }
    UserDefaults.standard.set(id, forKey: storageKey)
    appendToSessionChain(id, storageKey: storageKey)
}

The chain is capped at sixteen entries because UserDefaults is not the right place for unbounded growth and a single conversation rarely owns more than two or three IDs in a normal week. If your storage is a real database, the cap can be larger, but it should still be there. The chain becomes the slow query in the priorContext path on the long-lived conversations you most want to be fast.

Reset only on explicit New Chat or sign-out. Never on a transient failure. The whole point of the chain is to outlive the failures.

PriorContext on every send, not on detected failure

The second part of the pattern is the rule that the host always sends a small preamble of recent messages with every turn, even when nothing appears to be wrong. The bridge ignores it on the happy path and only consults it for recovery: when the SDK reports a session resume failure, or when a prior turn returned empty text from a poisoned upstream session. Without unconditional priorContext, those recovery paths cannot replay history, and the recovery becomes a silent context loss.

// On every send, regardless of whether resume is being attempted:
let storageKey = "acpSessionId_\(key)_\(bridgeMode)"
var ids = Self.loadSessionChain(storageKey: storageKey)
if let head = UserDefaults.standard.string(forKey: storageKey),
   !head.isEmpty,
   !ids.contains(head) {
    ids.append(head)
}
let recent = await ChatMessageStore.loadMessages(
    context: ctx,
    sessionIds: ids.isEmpty ? nil : ids,
    limit: 20
)
// recent is forwarded to the bridge as priorContext on every turn.

One DB read of about twenty rows per send is microseconds. The cost of skipping it on the turn that silently rolled is a model that wakes up with no memory of the conversation, mid-task, and a user who decides the agent is broken. The tradeoff is not close.

The five rules, in source order

What this looks like in the storage layer

The shape of the message table itself is small. One row per message, with the conversation context as taskId, the upstream session as session_id, plus the usual id / sender / text / timestamps. The session_id column is indexed so the priorContext load is a fast lookup against the chain.

-- Desktop/Sources/AppDatabase.swift, fazmV5 migration
ALTER TABLE chat_messages ADD COLUMN session_id TEXT;
CREATE INDEX idx_chat_messages_session
    ON chat_messages(session_id);

-- Insert each message with the current upstream session id:
INSERT OR REPLACE INTO chat_messages
    (taskId, messageId, sender, messageText,
     createdAt, updatedAt, backendSynced, session_id)
VALUES (?, ?, ?, ?, ?, ?, 0, ?);

-- Read across the full chain on every send:
SELECT messageId, sender, messageText, createdAt
FROM chat_messages
WHERE taskId = ?
  AND session_id IN (?, ?, ?, ...)  -- the chain
ORDER BY createdAt DESC
LIMIT 20;

Nothing exotic. The whole pattern is one extra column, one extra index, and a deduped string list in durable storage on the client. The cleverness is in the discipline of always loading by the chain and always sending priorContext, not in the data model.

Why this matters more for a computer-use agent

A chat agent that loses session state has to re-greet the user. Annoying, not dangerous. A computer-use agent that loses session state can re-execute a destructive action it already executed: re-send an email, re-charge a card, re-write a file, re-post a Reddit comment. The model does not know it already did the thing, because the thing it did is gone from its preamble. The chain plus per-send priorContext is what lets the agent continue a multi-step task across an upstream rollover without doubling work.

Fazm is a macOS computer-use agent that drives the browser, edits documents, and operates Google Apps via accessibility APIs rather than screenshots. It runs against the Claude Agent SDK through a Node bridge. Every constraint above (rate limit on a live conversation, bridge OOM, OAuth token rotation) has fired in production, and the chain is the layer that made the difference between a continued conversation and an agent that re-sent the same email twice.

Adopting the pattern in five steps

Where this differs from the framework guides

The published guides for LangGraph, OpenAI Agents SDK, Microsoft Agent Framework, Google ADK, and Databricks all describe persistence as a backend choice plus a memory taxonomy. Pick your storage (file SQLite, async SQLite, Redis, SQLAlchemy, MongoDB, Dapr). Pick your memory layer (short-term, long-term, episodic). Pass your session ID back on resume.

All of that is fine. None of it addresses the case where the framework’s own session abstraction loses identity under it. The chain pattern is not a replacement for any of those layers. It is the layer above them. The framework handles the persistence of one session. The chain handles the continuity of one conversation across the framework’s sessions.

If you have built on top of any of those frameworks for more than a few months and have a real conversation that has survived a rate-limit afternoon, you have probably already invented something close to this in your own code. This page is a name for that thing, plus the line numbers in one shipping product where the discipline is enforced.