How a Conversation Becomes Durable Memory

OpenViking’s session system explains the write side of an agent’s context: how a conversation moves from live messages to an archive, then—when policy and extraction justify it—to durable memory. The important distinction is between preserving what happened and deciding what should influence future work. Following that transition shows why OpenViking’s memory is selective, asynchronous, identity-aware, and not a magical replay of every previous turn.

A session has two lives

A session begins as an active conversation. It receives user and assistant messages, and those messages can contain more than plain text: an image, a reference to a retrieved context item, or a tool call and its output. While the session is active, those parts form the immediate working record for the task.

When the conversation reaches a useful boundary, the session can be committed. OpenViking describes the lifecycle as Create → Interact → Commit. The commit moves the current batch into an archive, clears the live message state, and returns an accepted task result. The archive is a durable record of the conversation segment. It can later be summarized, searched, or used as the input to memory extraction.

That archive is not the same thing as long-term memory. The archive answers, “What messages and tool interactions occurred in this session?” A durable memory answers a narrower question: “What information from those interactions is worth carrying into a future context?” Keeping both records matters. If extraction makes a poor choice, the original conversation remains available for inspection. If every message were immediately collapsed into a memory, the system would lose the distinction between evidence and interpretation.

The commit is split because the work has different latency and reliability characteristics. Writing the archive and clearing the active batch should not require the user to wait for every model call involved in summary generation and memory extraction. Those later stages can run as background work, return a task identifier, and be retried or observed independently. The practical consequence is that “commit accepted” means the session batch has entered the archival workflow; it does not necessarily mean that new memories are already searchable.

sequenceDiagram participant A as Agent and user participant S as OpenViking session participant H as Session archive participant X as Memory extractor participant M as Self or peer memory participant V as Semantic and vector index A->>S: Add messages and tool parts A->>S: Commit current batch S->>H: Persist archive messages H-->>S: Return archive and task acceptance S-->>A: Clear live batch and return task id X->>H: Read archived batch X->>M: Compare and apply memory operations M->>V: Queue semantic and vector refresh X->>H: Write memory diff and completion marker

The diagram separates the durable conversation record from the later memory update. It also shows why memory can become visible after the commit boundary rather than at exactly the same instant.

The archive preserves context; the extractor selects meaning

The background phase can generate a structured summary for the archived segment. The documented format includes a one-line overview, analysis, the user’s primary request and intent, key concepts, and pending tasks. This summary is useful as a compact description of the session, but it still belongs to the session archive.