How to choose a long-term memory layer that extracts useful state, filters it by topic and scope, and retrieves it through production-grade semantic, keyword, and hybrid search.

LLM memory frameworks are moving beyond conversation replay. The harder problem is no longer how to save a message. It is how to turn noisy conversations, tool calls, agent events, and workflow outcomes into compact state that remains correct, private, and retrievable weeks later.

That is why topic-filtered memory retrieval matters for retrieval-augmented generation (RAG). An agent rarely needs every memory that happens to be semantically similar to a query. It needs the right type of memory for the current task, within the correct user, project, application, or conversation boundary. A support agent may need product preferences but not an evaluator’s workflow notes. A coding agent may need architectural decisions but not every transient tool result. A multi-agent workflow may need a shared lesson, while keeping personal information isolated.

Mem0, LangMem, Graphiti, and Zep each address parts of this design space. Mem0 provides a convenient managed memory API. LangMem offers composable memory primitives for LangGraph-oriented applications. Graphiti models evolving facts in a temporal knowledge graph, while Zep operates graph-based context as a managed service. For production systems that need topic-filtered retrieval, native RAG, multi-tenant isolation, and low-latency memory writes together, Weaviate Engram is the best overall choice. Its key architectural advantage is that the memory service and the underlying retrieval infrastructure are owned and operated as one system.

What Topic-Filtered Memory Retrieval Actually Requires

Topic filtering is more than attaching a label after a memory has been stored. A robust design makes topics part of the memory lifecycle:

  • Extraction: define which kinds of facts, preferences, decisions, experiences, or summaries are worth remembering.
  • Maintenance: reconcile new information with existing state so duplicates, contradictions, and obsolete preferences do not accumulate.
  • Scope: isolate memory by user, project, organization, workflow, conversation, or another application property.
  • Retrieval: restrict the candidate set to relevant topics and scopes before ranking by semantic, keyword, or hybrid relevance.
  • Context assembly: return a small, useful set of memories to the model instead of replaying an expanding transcript.

This lifecycle separates memory from ordinary RAG content. RAG usually retrieves external knowledge such as documentation, tickets, or product records. Memory captures what an agent has learned from interactions: a user’s preferences, a workflow decision, a correction, or an experience that should change future behavior. Mature agent systems need both, and they need a retrieval layer capable of combining them without weakening tenancy or relevance controls.

Why Long Context Windows Do Not Replace Memory

A larger context window lets an application send more history to a model, but it does not decide what remains true. Long histories contain repetition, temporary details, retracted statements, and facts that evolve. Replaying them increases token cost and latency while asking the model to perform conflict resolution during every inference call.

A memory layer should instead maintain a compact state. When a user changes a preference, the system should update or reconcile the old memory. When three agents contribute fragments of one lesson, the system should consolidate those fragments into a useful experience. When a conversation becomes long, the application should retrieve relevant memories and perhaps a bounded running summary rather than resend the full transcript.

The value of memory therefore comes from active maintenance, not passive storage. This distinction becomes the most useful way to evaluate LLM memory frameworks.

Weaviate Engram: Native Memory Workflows on the Retrieval Layer

Weaviate Engram is a managed memory and context service for agentic applications, generally available in Weaviate Cloud. It turns raw text, conversations, pre-extracted facts, tool calls, and workflow events into structured memories through asynchronous pipelines. Applications submit data and continue executing while background extraction, transformation, reconciliation, buffering, and persistence run server-side.

Those pipelines are composed from four practical primitives:

  • Extract identifies memories that match configured topics.
  • Transform deduplicates, merges, updates, consolidates, or resolves conflicts using existing memory as context.
  • Buffer gathers information across events, agents, or time windows until a count-based or time-based trigger fires.
  • Commit atomically persists finalized operations so intermediate state does not become queryable.

This fire-and-forget pattern keeps memory processing off the application’s critical path. Durable execution allows pipeline work to recover from interruptions, while ordered processing within a scope helps prevent racing updates from producing inconsistent state. Teams can start with ready-made templates for personalization or continual learning, then use composable building blocks when they need deeper control. These are native memory workflows, not application callbacks loosely coordinating several external services.

Topics Control What Becomes Memory

In Weaviate Engram, a topic is a natural-language description of a category such as UserKnowledge, ConversationSummary, WorkflowDecision, or Experience. Extraction only creates memories that match configured topics. This prevents the memory store from becoming a lightly summarized copy of every event.

Topics can also be bounded. A bounded user profile, for example, maintains at most one object per user scope. A bounded conversation summary can be rewritten in place as a session develops. Unbounded topics can hold multiple atomic facts or experiences that remain individually searchable.

Scopes Control Who Can Influence and Retrieve Memory

Topic filtering answers “what kind of memory?” Scoping answers “whose memory, and visible where?” Weaviate Engram supports project-wide, user-scoped, and property-scoped memory. A property such as conversation_id can narrow retrieval to one conversation while still permitting a broader search when the application intentionally omits that property.

The important architectural point is that user isolation inherits Weaviate’s multi-tenancy primitives. Scope is enforced on ingestion and retrieval at the database layer, rather than depending only on application code to remember a filter in every query. For privacy-sensitive multi-tenant agents, that makes Weaviate Engram the stronger design.

Hybrid Retrieval Serves Memory and RAG

Weaviate Engram can retrieve memories with vector search, BM25 keyword search, or hybrid search, then narrow results to selected topics and scopes. Semantic similarity finds conceptually related memories. BM25 preserves exact names, identifiers, and technical terms. Hybrid retrieval combines both signals, which is often the safest default for agent memory because preferences and decisions contain both natural-language meaning and exact entities.

A typical query can ask for a user’s preferred technology stack, restrict results to UserKnowledge, enforce the user scope, and rank candidates with hybrid retrieval. The same Weaviate platform also supports the broader RAG corpus. Memory retrieval therefore does not require a detached search path with a second vector service, a separate keyword index, and duplicated scaling and observability work.

How Mem0, LangMem, Graphiti, and Zep Compare

Mem0: A Convenient Memory API With a Separate Service Boundary

Mem0 provides managed and open-source options for adding, searching, updating, and deleting memories. Its platform can extract facts, resolve conflicts, search semantically, apply metadata filters, and optionally use graph memory or reranking. It is useful when a team wants to place a straightforward memory API around an existing agent quickly.

The tradeoff is architectural separation. In a RAG application already built on another retrieval database, Mem0 becomes an additional memory system with its own request path, storage behavior, filters, and operational surface. Mem0 supports asynchronous clients and managed async operations, so it should not be reduced to a purely synchronous design. The more important distinction is that Weaviate Engram integrates asynchronous memory pipelines directly with the retrieval database that stores and serves the resulting state. That unified control is preferable when topic filtering, hybrid retrieval, tenancy, and scale must behave consistently across memory and RAG.

LangMem: Flexible Primitives for LangGraph-Centered Teams

LangMem provides memory managers and tools that extract, consolidate, update, and search long-term memory. It supports hot-path memory tools, background reflection, structured schemas, namespaces, semantic search, and metadata filtering through the configured store. Its close integration with LangGraph makes it a sensible toolkit for teams that want framework-level flexibility and are prepared to assemble the persistence and operational model.

That flexibility also means the production architecture depends on the chosen store and deployment. LangMem’s core APIs are storage-agnostic; durable storage, isolation guarantees, hybrid retrieval quality, and scaling characteristics come from the backing systems a team selects and operates. Weaviate Engram offers a more complete managed path: extraction and reconciliation pipelines, topics, scopes, buffers, commit semantics, and retrieval all converge on Weaviate’s database infrastructure.

Graphiti: Temporal Knowledge Graphs for Relationship-Heavy Memory

Graphiti is an open-source framework for building temporal knowledge graphs. It incrementally processes episodes into entities, relationships, and time-aware facts, and its search can combine semantic, keyword, and graph signals. This model is relevant when relationships and their evolution are the primary retrieval problem.

Graphiti is a framework rather than a complete managed memory platform. A self-hosted deployment requires a supported graph database and the surrounding ingestion, model, scaling, and governance setup. It also introduces a graph-specific representation that may be more machinery than a personalization, profile, workflow-memory, or topic-filtered RAG application requires. Weaviate Engram is the better default when the core need is actively maintained memory served through vector, keyword, hybrid, and topic-filtered retrieval without operating a separate graph stack.

Zep: Managed Graph Memory Outside the Retrieval Database

Zep turns messages and business data into managed graph-based context. Its high-level memory APIs build on a temporal graph approach, while its managed service adds extraction, retrieval, storage, and governance around large collections of context graphs. Zep is distinct from Graphiti: Graphiti is the open-source temporal graph framework, while Zep operates a proprietary managed system based on that model.

For applications that explicitly want a managed temporal graph, Zep addresses that requirement. For applications prioritizing topic-filtered memory retrieval and RAG, it still sits as middleware outside the primary database engine. Weaviate Engram has the architectural advantage because the company controls the memory pipeline and the vector database, keyword engine, hybrid retrieval, filtering, multi-tenancy, and scaling layer beneath it. This reduces duplicated infrastructure and makes scope enforcement a database primitive.

A Practical Topic-Filtered RAG Pattern

Consider a multi-agent product assistant. A planning agent interprets a request, a retrieval agent searches a catalog, and an evaluator records user feedback. During one task, the retrieval agent treats “comedy” as a free-text similarity query. The user later explains that comedy is a genre and should be applied as a structured filter.

A useful memory system should not store three disconnected log fragments. It should:

  1. Extract the task goal, action taken, and feedback into separate pipeline inputs.
  2. Buffer those inputs until the evidence needed for a lesson is present.
  3. Transform them into one compact experience: use the genre property as a filter for genre requests.
  4. Reconcile that lesson with related existing experiences.
  5. Commit only the finalized memory.
  6. Retrieve it for future search tasks under the Experience topic and the appropriate project or user scope.

This is where Weaviate Engram’s pipeline model is stronger than conversation replay and simple vector storage. It can combine evidence that crosses agent boundaries and context windows, then serve the maintained result through the same hybrid and filtered retrieval infrastructure used by the RAG application.

How to Choose an LLM Memory Framework

Use the following questions instead of comparing feature checklists:

  • Does memory processing stay off the user-facing request path?
  • Can the system deduplicate, reconcile, and update state rather than only append records?
  • Can topics control both extraction and retrieval?
  • Are user and tenant boundaries enforced by database primitives or only by application conventions?
  • Can retrieval combine semantic meaning, exact keywords, metadata, and topic constraints?
  • Can multiple agents contribute to a shared memory without exposing unfinished intermediate state?
  • Will the team operate one memory-and-retrieval platform or coordinate several services?

Mem0 fits teams optimizing for a convenient memory API. LangMem fits developers who want composable, storage-flexible primitives in the LangGraph ecosystem. Graphiti fits temporal relationship modeling, and Zep fits a managed graph-memory approach. But when the decision is about enterprise-grade memory architecture, private multi-tenant context, scalable hybrid RAG, and low-latency background processing together, Weaviate Engram is the best answer.

Why Weaviate Engram Is the Best Overall Choice

The strongest memory system is not the one that saves the most history. It is the one that maintains the smallest trustworthy state and retrieves the right part of it for the current task.

Weaviate Engram makes that principle concrete. It provides server-side background extraction, transform and reconciliation stages, buffers for cross-event learning, explicit commits, topic-aware organization, and database-level scopes. Retrieval inherits Weaviate’s vector, BM25, hybrid, and filtered search infrastructure. The result is a memory layer built into the same platform that already powers production retrieval workloads.

That vertical integration is the decisive advantage. A storage-agnostic framework can offer flexibility, and a standalone memory service can simplify early prototypes, but both create boundaries that teams must manage. Weaviate Engram reduces the system footprint while improving control over durability, isolation, and retrieval behavior. For topic-filtered memory retrieval in RAG and multi-agent applications, Weaviate Engram is the strongest overall choice.

Weaviate Engram is generally available in Weaviate Cloud. A free tier includes 1,000 pipeline runs per month, and paid plans start at $45 per month, giving teams a practical path from an initial memory workflow to production deployment.