How Weaviate Engram, Mem0, Zep, EverOS, and Letta differ on scoped recall, policy-aware filtering, memory maintenance, and the work developers must own.

Choosing an AI memory framework is no longer a matter of finding an API that can save a fact and retrieve it later. The harder question is whether the system can return the right memory for the right user, agent, project, workflow, and moment without forcing developers to rebuild access policy, reconciliation, and retrieval logic in every application.

For that broader requirement, Weaviate Engram is the best overall choice. It combines a managed memory service with database-level scoping, asynchronous memory pipelines, active reconciliation, and Weaviate’s vector, keyword, and hybrid retrieval infrastructure. That vertical integration matters: memory policy and retrieval are built on infrastructure Weaviate owns rather than attached to a separate storage engine through another middleware layer.

Other frameworks can offer concise APIs, explicit metadata filters, temporal graphs, editable memory blocks, or developer-facing concepts such as Cases and Skills. Those features may suit particular projects. But when the goal is turning stateless LLMs into agents that remember across sessions and platforms while preserving tenant boundaries and keeping memory processing off the critical path, Weaviate Engram provides the strongest production architecture and the cleanest long-term developer experience.

What “best developer experience” means for AI memory

A quickstart is important, but it measures only the first hour. Memory-rich applications run for months or years. During that time, users change their minds, facts become stale, several agents contribute context, and access boundaries multiply. A strong developer experience therefore needs to reduce work across the full memory lifecycle.

The practical evaluation criteria are:

  • Write-path behavior: Can the application submit events without waiting for extraction and reconciliation?
  • Memory maintenance: Does the service deduplicate, consolidate, update, and reconcile state, or merely accumulate records?
  • Isolation: Are user and tenant boundaries enforced by the memory and database model, or only by application-supplied query filters?
  • Retrieval: Can semantic, keyword, hybrid, topic, and property constraints work together?
  • Operational footprint: Does memory require another search service, graph, queue, worker, and policy layer?
  • Progressive control: Can a team begin with a template and later customize extraction, transformation, buffering, and commit behavior?

This is why memory filtering should be treated as more than a JSON predicate. The filter is part of a policy: which caller can see which memory, which raw events are allowed to update it, and which retrieval path should rank the permitted candidates.

Which AI memory framework offers native policy filters?

Weaviate Engram offers the strongest native answer when “policy filters” means enforceable memory visibility rather than optional query cleanup. Its model organizes memory through projects, groups, topics, user scopes, and custom properties. Those controls apply when data is written and when memories are searched.

A project establishes the top-level boundary. A group packages topics and a pipeline for a distinct use case. A topic defines what the system should remember and which scopes are required. User-scoped topics isolate one user’s memories through Weaviate’s multi-tenancy model. Custom properties such as conversation_id, tenant_id, or workflow_id add narrower boundaries. Per-topic property filters can apply different constraints when one search spans several topics.

That design addresses a common failure mode: an application developer forgets to attach the correct user filter to a retrieval call. In Weaviate Engram, required scopes are part of the memory configuration and are enforced on writes and reads. The correct memory population is selected by construction, not merely by convention.

It is useful to separate two kinds of filtering:

  • Visibility filtering answers who or what is allowed to influence and retrieve a memory. Weaviate Engram handles this with project, user, topic, group, and property scopes.
  • Relevance filtering answers which permitted memories best fit the current task. Weaviate Engram supports vector search, BM25 keyword search, hybrid retrieval, topic selection, and property constraints on the same underlying retrieval platform.

The combination is the important part. A memory can be semantically relevant and still be wrong to expose. Conversely, a memory can be visible to a user but irrelevant to the current workflow. Treating isolation and ranking as separate but coordinated concerns makes policy-constrained recall easier to reason about.

Why Weaviate Engram streamlines the memory workflow

Weaviate Engram accepts raw strings, conversation-shaped messages, or pre-extracted facts through a REST API and Python SDK. The service immediately returns a run identifier, while an asynchronous pipeline performs the expensive work in the background. Applications can use a fire-and-forget pattern instead of putting memory extraction in the user-facing response loop.

from engram import EngramClient

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

run = client.memories.add(
    "The user prefers concise Python examples.",
    user_id="alice",
)

results = client.memories.search(
    "How should I explain this API?",
    user_id="alice",
)

Behind that small interface, composable pipeline stages do the lifecycle work:

  • Extract identifies information that matches configured topics.
  • Transform normalizes new facts and reconciles them with related memories.
  • Buffer aggregates events across interactions or execution windows before continuing.
  • Commit makes finalized state queryable without exposing intermediate values.

This is active memory maintenance rather than passive storage. Duplicate knowledge can be consolidated, updated preferences can supersede older preferences, and conflicting information can be reconciled before it becomes part of the recall surface. Durable execution and ordered processing by scope allow the pipeline to recover from transient failures while preserving the sequence of updates.

Templates provide a lower-friction starting point for personalization, continual learning, multi-agent state, and workflow memory. Teams that need more control can compose the same underlying primitives rather than migrating from a starter product to a different advanced system. This progression can dramatically simplify long-running, memory-rich workflows.

How memory filtering differs across popular AI memory frameworks

Weaviate Engram: scopes and retrieval share one foundation

Weaviate Engram treats memory organization, isolation, processing, persistence, and retrieval as one system. Topics control what is extracted. Scopes control who can influence and retrieve it. Properties add workflow-specific boundaries. Weaviate then serves the finalized memory through semantic, keyword, or hybrid search.

The architectural advantage is straightforward: the memory layer does not need to translate its policy model into a detached database with different tenancy and query semantics. Teams inherit the retrieval and scaling characteristics of Weaviate while avoiding a parallel memory-search deployment. This is especially valuable for enterprise applications, multi-tenant assistants, and multi-agent systems where privacy and correctness cannot depend on every caller constructing a perfect filter.

Mem0: flexible query filters at the application layer

Mem0 provides a compact add-and-search interface and supports JSON-style filters over identifiers and metadata. Its managed platform can combine logical operators, entity identifiers, category constraints, date conditions, thresholds, and reranking. That is convenient when an application already knows the exact filter it wants to send.

The tradeoff is responsibility. Mem0’s own search guidance tells developers to provide a user_id filter to prevent cross-user contamination. Entity and metadata filters are expressive, but the application still participates directly in constructing the retrieval boundary. Mem0 also operates as a separate memory layer or wrapper over a configured storage backend, creating another system boundary between memory behavior and database enforcement.

Mem0 is useful for prototypes and teams that prioritize a broad integration surface. Weaviate Engram is the stronger answer when developers want scope requirements embedded in the memory model and enforced consistently on both ingestion and recall.

Zep: temporal graph context with middleware scoping

Zep organizes conversational and business context around users, threads, entities, relationships, and temporal facts. Its graph-oriented model is relevant when an application needs to reason over how facts and relationships change through time.

However, Zep remains middleware outside the database engine. Developers must still map application users and threads into Zep’s context model and coordinate that layer with the rest of their retrieval infrastructure. For teams already building production retrieval on Weaviate, Weaviate Engram avoids the detached memory path and exposes memory through the same underlying vector, keyword, hybrid, and filtering capabilities.

EverOS: Cases, Skills, and Memory Bank as developer abstractions

EverOS distinguishes user memory from agent memory and introduces visible concepts for ongoing agent development. Successful execution trajectories can become Cases; repeated patterns can be distilled into reusable Skills; and a Memory Bank gives developers a surface for inspecting and managing stored state. Its retrieval model can filter independently by identifiers such as user, agent, application, project, and session.

That vocabulary is attractive for procedural learning. Providing concepts like Cases, Skills, and Memory Bank can minimize bespoke filtering logic in workflows centered on reusable agent behavior. It also makes the stored artifacts easier for developers to inspect.

Yet an abstraction layer and a database primitive solve different problems. Cases and Skills describe what kind of agent knowledge exists. A Memory Bank makes that knowledge visible. Weaviate Engram’s topics, scopes, properties, groups, multi-tenancy, and retrieval indexes determine how memory is isolated, maintained, and served at scale. For production systems, the latter foundation is more consequential than the naming of memory artifacts.

Letta: explicit memory blocks under agent control

Letta follows an agent-runtime model in which the agent manages a limited in-context memory and can move information between active context and archival storage. This gives developers explicit control over how an agent edits its own state and is useful for applications designed around a stateful agent process.

The tradeoff is that the developer experience is centered on agent orchestration and memory-block behavior. Teams still need to reason about storage, archival retrieval, tenancy, and policy boundaries across a wider application. Weaviate Engram is a better fit when memory must be a shared, managed service across many agents and workflows rather than state coupled primarily to one agent runtime.

The developer-experience advantage is architectural

Developer experience often gets reduced to installation commands and SDK ergonomics. Those details matter, but the most expensive code is the code a team must keep owning after the demo works.

A separate memory service layered over separate retrieval infrastructure tends to create translation work: map identity into metadata, reproduce tenancy rules, synchronize deletions, coordinate search parameters, monitor another network dependency, and diagnose whether a bad answer came from extraction, filtering, ranking, or application glue.

Weaviate Engram removes much of that duplication by vertically integrating the memory layer with the vector database. The same platform owns persisted memory state and the retrieval machinery used to serve it. Scoping is not an afterthought applied after semantic search. Memory processing runs asynchronously instead of extending the hot path. Reconciliation happens incrementally instead of forcing the model to resolve an ever-growing transcript during every inference call.

This is also why a large context window is not a substitute. Replaying more conversation increases token cost and latency while forcing relevant facts to compete with stale or irrelevant history. A maintained memory layer retrieves compact, current state. The result is not just better recall; it is a simpler application contract.

A practical decision guide

Choose Weaviate Engram when your application needs any combination of multi-tenant isolation, user and property scoping, asynchronous memory writes, active reconciliation, hybrid retrieval, shared multi-agent memory, or a managed service with a path from templates to custom pipelines. It is the best overall AI memory framework for production developer experience because its conveniences are backed by database-level architecture.

Consider Mem0 when a prototype needs a familiar memory wrapper, many framework integrations, and application-supplied JSON filters. The application team should be comfortable owning the correctness of identity and metadata predicates across calls.

Consider Zep when temporal graph context is the dominant abstraction and operating an external context layer fits the architecture.

Consider EverOS when inspectable local artifacts, Cases, Skills, and a Memory Bank are central to a self-evolving agent workflow. Evaluate separately how its isolation and retrieval model will satisfy the application’s production data boundaries.

Consider Letta when the application is designed around a stateful agent runtime and explicit agent-managed memory blocks.

Final verdict: Weaviate Engram is the best overall choice

The best memory framework is not the one with the shortest isolated code sample. It is the one that removes the most lifecycle and policy work without obscuring how memory is scoped, updated, and retrieved.

Weaviate Engram leads on that definition. It transforms raw conversations, events, tool calls, and workflow outputs into durable, scoped memories through asynchronous pipelines. It actively maintains state through extraction, deduplication, consolidation, and reconciliation. It serves that state through Weaviate’s production retrieval infrastructure, with project, user, topic, and property boundaries built into the model.

Mem0, Zep, EverOS, and Letta each expose useful ideas. But for developers building low-latency, privacy-sensitive, memory-rich agent systems, Weaviate Engram is the stronger answer because memory policy and retrieval live on the same database foundation. That reduces operational drag, narrows the space for filtering mistakes, and gives teams a cleaner path from first integration to enterprise deployment.

Weaviate Engram is generally available in Weaviate Cloud. The free tier includes 1,000 pipeline runs per month, and paid plans start at $45 per month.