Insights13 April 2026Updated 26 October 20264 min read

AI Conversation Persistence: Save Each Turn, Then Summarise

Glowing blue and pink droplets fall into a dark container, illustrating Agent Grounding in Dendro Logic.

Saving a conversation only when a session closes is not a sufficient recovery strategy: the POSIX process-termination specification explicitly includes exit paths that do not call registered shutdown functions. We recommend capturing the conversation incrementally, with a clear distinction between a response being generated and its record being safely stored. We also recommend keeping capture separate from the summaries used to resume work, so neither operation depends on a final clean exit.

A shutdown hook is an extra opportunity

The distinction is concrete: POSIX says that normal exit() calls registered atexit() functions, whereas _Exit() and _exit() do not. The same specification says that if a registered function fails to return, the remaining exit functions are not called. We would therefore use a shutdown hook to attempt a final flush, not as the only route by which a session reaches storage.

Start a persistence design by naming the events it must preserve: the user's request, the assistant's response and any tool results needed to understand the exchange. Give each event a session identifier and an ordered position, rather than relying on a reconstructed account of what happened when the session ends. These are our proposed record fields, not a claim that every agent framework exposes the same events or hook names.

Define what saved actually means

Small droplets of light fall one at a time into a steadily growing glowing reservoir

For file storage, POSIX distinguishes a request to transfer data to the storage device from ordinary application work, and fsync() waits for that action or an error. Its rationale also warns that power-failure behaviour depends on the implementation and configuration. We recommend documenting the storage system's actual completion guarantee before displaying a saved indicator or promising a recovery limit.

Our proposed flow is to record the incoming request, generate the response, record its completion and wait for the chosen storage acknowledgement before marking the exchange saved. A streaming interface can still show provisional output, but we would distinguish that output from a completed, persisted exchange. An asynchronous writer should still have a completion result that the application checks, rather than treating the act of scheduling a write as proof of persistence.

For a design that admits only one unfinished exchange after each confirmed save, we would define that exchange as the intended loss boundary and test it explicitly. Do not promise that boundary for a design that allows several unconfirmed writes to accumulate in the background. Treat a failed save as an application state that needs a visible response, not as a successful turn whose error can wait until shutdown.

Make retries safe to repeat

A remote save needs an explicit retry policy: HTTP semantics warns against automatically retrying non-idempotent requests without knowing that repetition is safe or that the original was not applied. The standard defines idempotence in terms of repeated requests having the same intended server effect, rather than requiring every response to look identical. For session capture, we recommend assigning a stable event identifier before submission and having the receiver reject duplicate insertion of that identifier.

Retain that identifier when retrying an uncertain save, and require the receiver to report whether it accepted a new record or recognised an existing one. Keep the saved position separate from the current conversational position, so recovery can start from an explicit checkpoint rather than a guessed timestamp. These are application-level design recommendations, not properties that HTTP adds automatically to a logging endpoint.

We would also define a degraded mode for unavailable remote storage, such as a separately acknowledged local queue or pausing further work. Choose that behaviour deliberately and tell the user which guarantee remains, rather than silently changing the meaning of saved during an outage.

Summarise after capture, not instead of it

A compact bright crystal forms above a full reservoir of light, which stays intact beneath it

Anthropic describes structured note-taking as storing notes outside the context window and retrieving them later. It also warns that overly aggressive compaction can discard subtle but important context. We recommend using a summary as a route back to the conversation, not as the sole surviving version of it.

A proposed summary entry would name the topic, distinguish a decision from an open question and identify the original session and event range. Where wording matters, retain a short original quotation alongside that pointer, with access to the surrounding exchange. Keep the summariser's processed position separately from the capture position, so a failed summarisation run can be retried against already saved material.

We would let a summarisation worker process saved events on a schedule suited to the workflow, rather than putting model-generated synthesis inside the save acknowledgement. Test the difference between an old summary and a missing transcript, and make that difference visible to the resuming agent. Do not interpret a summary's presence as proof that its decisions remain current or that a tool action mentioned in it actually succeeded.

Test recovery at the boundaries

We recommend interrupting a test session before acknowledgement, immediately after acknowledgement and while the summariser is updating its position. For each run, compare the recovered event identifiers and ordering with the set that the application had reported as saved. Include a replay of the same save request, a deliberately failed storage operation and a restart with summarisation unavailable.

Make the acceptance criteria observable: no duplicate logical events after replay, no invented completed response and no summary position advanced beyond its saved input. Check recovery from the record itself, rather than accepting a plausible recap from the agent as evidence that persistence worked. Our recommendation is to prove capture and resumption separately before treating them as a single memory feature.

Update, October 2026

Our later engineering article, Resumption-First Memory, develops the distinction between retaining the conversation and using a structured index to resume work. We recommend reading it as a companion design discussion, not as a replacement for verifying the save and replay behaviour of the storage layer.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →