Which Open-Weight Models Support External Memory Backends for Cross-Session Knowledge Work

A persistent memory AI assistant for knowledge workers needs an external memory backend even if its model is advertised as having memory. Virtually any capable open-weight model can participate once storage, retrieval, and write-back are in place. The useful comparison is therefore between backend patterns and the models that fit them, with the choice driven by whether the work requires preference recall, continuous agent context, temporal reasoning, or a shared knowledge base.

Why no open-weight model can hold knowledge across sessions on its own

Some models seem to remember, while others seem to forget. That difference can look like a property of the model, but it comes from the surrounding system. A context window is stateless across sessions by design. Without external infrastructure, a new session has no memory of earlier conversations, regardless of how capable the model is.

A larger context window lets a model use more information within a session. Asking which model “supports” persistent memory is therefore like asking which CPU supports a filesystem. The stack determines how the system stores knowledge, selects it, and puts it back into the model’s context.

What “cross-session knowledge work” actually requires from a system

What would let an assistant remember projects and preferences between conversations? It needs four things, starting with durable storage that keeps its data when the application restarts or the infrastructure changes. That storage can take the form of vector embeddings, relational tables, a knowledge graph, or a compiled document artifact. Persistence is only the first requirement, though. Selective retrieval must decide which stored knowledge belongs in the current session.

The next requirement is write-back, because useful knowledge also emerges during conversations. A system must extract that knowledge and save it. Finally, the store needs accumulation, so facts can be updated, contradictions resolved, and stale entries superseded or decayed. Otherwise, it grows without becoming more dependable. A record of past conversations is not the same as a maintained understanding of a project.

RAG addresses storage and retrieval, but not, by itself, write-back and accumulation. It indexes documents and retrieves relevant material at query time without necessarily cross-referencing or keeping knowledge current between sessions. Persistent storage alone is therefore insufficient. Three established patterns meet these needs in different ways: vector-plus-fact extraction, OS-style hierarchical paging, and temporal knowledge graphs. A fourth pattern, the compiled knowledge artifact, is starting to emerge.

The three backend patterns and what each one makes possible

Mem0 sits between the LLM and a vector database, automatically extracting and storing facts from conversations. It works with multiple vector stores and a wide range of LLM providers, so the approach is effectively model-agnostic. Its Apache-licensed Python library is self-hostable, with pluggable vector stores and local providers including Ollama. This makes the system a good fit for preference tracking, fact recall, and personalization across sessions.

Those strengths also define the pattern’s limits. Retrieving a related fact does not establish when it was true or how it connects to several other facts. The vector-plus-fact pattern does not itself provide temporal reasoning, multi-hop relational queries, or automatic supersession of stale claims.

OS-style hierarchical paging treats memory as something an agent actively manages. The Letta/MemGPT approach divided it into core, archival, and recall memory, with agents using tool calls to read and modify those stores, much as a kernel pages RAM to disk. Letta’s documentation has since shifted to MemFS, a git-backed filesystem model.

Letta supports PostgreSQL with pgvector and SQLite, with Google Cloud Storage as an optional object-storage add-on. MemFS provides the separate local git-backed filesystem. More importantly, the API separates agent identity, memory, and state from the underlying model, so swapping models preserves the agent’s memory and history. Sleep-time compute, added in 2025, lets a background agent process, summarize, and rewrite memory while the user is idle, although memory management still consumes reasoning tokens.

Temporal knowledge graphs treat memory as relationships with a history. Graphiti ingests conversational episodes, uses an LLM to extract entities and relationships, and stores them in a bi-temporal graph. Valid time records when a fact was true, while system time records when it entered the store. The two clocks answer different questions. This is the only pattern here that natively represents when something was true, enabling relationship histories, multi-hop queries, and causal tracing.

Zep combines cosine similarity, BM25 full-text search, and breadth-first graph traversal in its retrieval pipeline. Its reranking options include reciprocal rank fusion, maximal marginal relevance, cross-encoder scoring, node distance, and episode-mentions reranking. The combination can address queries that vector similarity alone cannot, including questions about what changed between two periods.

The new compiled-artifact pattern stores a shared body of knowledge that lasts across sessions. Karpathy’s April 2026 LLM Wiki proposal separates immutable raw sources, an LLM-maintained wiki of markdown files, and a schema document defining structure, conventions, and workflows [45][24][20]. Both humans and agents can read and write the compiled artifact across sessions. The artifact sits outside any one agent. LLM Wiki v2 adds confidence scoring and explicit supersession of stale claims, turning knowledge maintenance into an editorial process.

The unsolved problem all four patterns share: what to do when facts change

What happens when a saved fact is no longer true? None of these patterns fully automates the judgment needed to resolve that change. Standard vector retrieval selects semantically similar information without necessarily knowing whether a newer claim has superseded it. An agent may then use out-of-date information with full confidence.

Temporal graphs help, but their advantage is conditional. A superseding fact must be ingested and linked to the old one for the history to be useful. Contradictions that remain unlinked can coexist without resolution. Likewise, tools that let an agent rewrite memory do not, on their own, decide which version to keep.

The wiki approach exposes that decision directly. LLM Wiki v2 replaces stale claims, leaving a cleaner active account but losing the prior understanding at the point of replacement. Preserve-in-place approaches retain versions for audit, but an agent may retrieve the wrong one. Neither choice is free of trade-offs. The choice depends on whether the task needs the current answer, a record of earlier beliefs, or both.

Memory as Metabolism proposes scheduled consolidation that compares new entries with one another and with the existing wiki before overwriting. Its “memory gravity” mechanism protects load-bearing entries whose removal would cascade through the artifact, while minority positions can accumulate evidence against dominant interpretations. This remains a theoretical proposal. The paper and MemOS identify decay, audit, and conflict resolution as open governance problems that shipping systems address only partially.

A supersession policy needs to be chosen and continually curated. Stale facts are less of a problem for preference tracking than for factual research or causal tracing, so the same policy will not fit every workload. No backend can simply be left unattended. Given that constraint, model selection becomes a narrower question about which models can retrieve, extract, and manage knowledge reliably within the chosen architecture.

Where open-weight model choice actually matters within a memory-backend system

Model fit has three distinct points of influence. Embedding models populate the searchable representation, extraction models decide what gets written back, and reasoning models use the stored knowledge and manage memory through tools. Treating them as separate roles makes the comparison more useful than choosing one model and assuming it will handle every part equally well.

For backends using vector search, embedding quality shapes retrieval precision. Qwen3-Embedding and E5-Mistral-Instruct are open-weight baselines for this role. Embedding is typically cheap and fast, so domain specificity is often more consequential than raw capability. The representation needs to capture the distinctions the work depends on. Even a capable reasoning model cannot make up for every fact the task needs that retrieval misses.

Extraction quality determines what the system remembers and how accurately. These models turn raw conversation into facts, entities, and relationships for the write-back pipeline. Errors can compound over later sessions. Smaller-class models cover most extraction tasks for teams with constrained hardware, while larger-class models improve accuracy on complex relational extraction. That distinction becomes especially important in a graph, where errors propagate through relationships.

Letta-style memory management requires reliable instruction-following and tool use so the agent can read and write its stored context. Llama 4 Scout, Qwen3.5, and Mistral Large 2 are options for this role. They are not interchangeable on every dimension. The fit depends on the work surrounding those tool calls.

Llama 4 Scout is a mixture-of-experts model that has 17B active parameters. Its extremely large context window can reduce retrieval needs within a session, but it still requires an external backend across sessions. Mistral Large 2 is a large dense model with a long context window, support for dozens of languages and 80+ coding languages, and the Mistral Research License.

Matching backend patterns to knowledge-work types: a practical decision guide

For preference tracking and personalization, the Mem0 pattern is the natural fit when facts are relatively stable and temporal precision is unnecessary. Its broad provider support leaves room for a capable open-weight model and a smaller extraction model where hardware is constrained. An explicit curation policy is still necessary. Personalization builds up over time, but saved preferences can still become wrong.

For continuous agent identity and long-running tasks, the Letta pattern fits work in which an agent must manage its own memory and coordinate work across a complex task graph. Llama 4 Scout, Qwen3.5, or Mistral Large 2 can supply the tool-using reasoning layer. Sleep-time compute moves consolidation away from live conversation. The trade-off is greater operational complexity than a vector-only approach, with reasoning tokens still spent on memory management.

For temporal reasoning, causal tracing, and relationship evolution, Graphiti/Zep offers the relevant structure. Its hybrid retrieval combines semantic search, full-text search, and graph traversal. Any capable open-weight model can be the reasoning layer, but accuracy in complex relational extraction needs close attention. This is the most complex pattern to operate. Bi-temporal ingestion requires careful episode structuring, and time fields do not excuse unresolved contradictions.

For a shared, human-readable knowledge base, the LLM Wiki pattern fits work that must remain editable and auditable across users and agents. Any capable instruction-following model can maintain the artifact because the schema document defines its workflow. The governance decision comes before deployment. Overwriting, preserving, and scheduled consolidation each imply a different relationship between current knowledge and its history, with the last still represented here by a theoretical proposal.

The LongMemEval and LoCoMo figures in this category were vendor-produced using different model configurations, so they do not form a valid head-to-head comparison. Architecture and retrieval design are more dependable selection criteria. For production systems that use more than one pattern, a memory orchestration layer can let backends be plugged in and keep agent state separate from the reasoning model. The durable investment is the knowledge architecture. The model within it remains adjustable.