If you've worked with an AI agent across more than one session, you've probably had to bring it back up to speed: what was decided, what's already done, and what's changed. For the agent to pick up where you left off without that recap, your application needs to retain that context, keep it current, and retrieve the relevant parts for the next task.

Agent memory tools handle those responsibilities in different ways. Some provide APIs for extracting and retrieving facts; others build memory into the agent runtime. The choice shapes how you manage changing information, preserve its sources, and connect memory to the rest of your application.

We compare seven agent memory solutions, explain where each fits, and show what to test before choosing one for your application.

Why agent memory matters

Agent memory is the part of an application that retains useful information from earlier work, updates it as circumstances change, and retrieves it when a later task needs it. That includes deciding what to keep, update, or forget, as well as where to store it.

Here is what that looks like in practice. Suppose your team is launching a new API. On Monday, you decide not to launch until the security review is done. On Thursday, the security team's ticket confirms the review passed. On Friday, you open a new agent session and ask for the launch checklist.

The agent's answer should reflect that the review has passed. The memory system should also retain Monday's decision and Thursday's ticket, so the team can trace why the launch was blocked and what cleared it.

Illustrative workflow: carry forward the latest status while keeping the original dependency and its source.

In the launch example, the agent needs to retrieve the review result before drafting the checklist and reflect the updated status in its answer. The agent harness, the software surrounding the model, determines when to retrieve that result and how to include it in the context used to draft the checklist. Our practical guide to harness engineering explains how to design that workflow, from preserving task state to checking outputs, so memory can inform what the agent does next.

Agent memory solutions compared

Use this comparison to narrow your shortlist based on how each solution manages memory and where you can deploy it.

1. Cognee

Cognee brings company knowledge and agent session history into a shared memory layer. It helps agents resume work with context drawn from conversations, documents, and systems such as Slack, GitHub, and Linear. Its SDK provides remember, recall, improve, and forget operations. Cognee also offers HTTP access and MCP tools for remembering, recalling, and forgetting. Teams can use the open-source package (Apache 2.0) or managed Cognee Cloud.

For permanent memory, its architecture combines three stores: a relational store for documents, chunks, and provenance; a vector store for semantic search; and a graph store for entities and relationships. Its short-term session cache stores interaction records without the permanent-memory extraction and embedding pipeline. Together, the stores support connected, source-linked retrieval alongside recent session context.

Consider it when: you want to connect company knowledge and agent session history through a shared memory API accessible from application code and MCP clients.

2. Mem0

Mem0 adds a memory layer to an existing AI application. In its quickstart, you pass a conversation to add with a user_id. The example stores extracted facts as individual memories and retrieves matching memories with a search scoped to that user.

That gives teams a concrete starting point for personalization, such as retaining customer preferences across support conversations. Mem0 comes as a managed Platform and an open-source engine with the same core operations. In its current v3 architecture, the Platform adds graph memory, memory decay, temporal reasoning, and webhooks that are not available in the open-source engine. The open-source version runs on the vector store, LLM, and embedder you choose.

Consider it when: your application already controls the agent loop and needs add/search memory scoped by user, agent, or run, with hosted and self-managed deployment options.

3. Zep

Zep organizes conversations and business data into Context Graphs that represent facts, relationships, source episodes, and changes over time. Facts sit on graph edges linked to their source episodes. Their timestamp fields record when Zep considers a fact valid and when it learned or invalidated it. For example, a contact might change employers in March, while the system only receives that update in April.

Zep also develops Graphiti, the open-source framework it uses to derive temporal graph data. You can use Graphiti independently of the Zep service, running it on Neo4j, FalkorDB, or Amazon Neptune and managing the infrastructure yourself. Zep provides managed storage, ingestion, retrieval, and governance, with cloud and bring-your-own-cloud (BYOC) deployment options.

Consider it when: you need relationship-based retrieval with explicit timestamps for both fact validity and when the system learned about a change, plus links to source episodes.

4. Letta

Letta approaches memory through stateful agents, each with a persistent identity, memory, model configuration, tools, and message history. Choosing Letta means evaluating its agent runtime as well as its memory features. Agent state can be stored in Letta Cloud or locally. Its self-hosting options include a local CLI runtime and an App Server that applications can connect to.

Letta agents use MemFS, a git-backed memory filesystem they can inspect and edit. Its configurable "dreaming" process uses background subagents to review recent conversations and consolidate lessons.

Consider it when: you want an agent runtime with persistent identity, versioned memory files the agent can inspect and edit, and background consolidation of lessons from conversations.

5. Supermemory

Supermemory combines document retrieval with extracted memories. From the same document, it keeps source chunks for grounding answers and derives facts for personalization.

Its user profiles separate long-term, stable facts from recent context. Its graph memory links facts that update, extend, or derive from one another and can preserve links to earlier facts. With the default dynamic dreaming mode, document chunks can be searchable before extracted memories are ready. The optional instant mode makes those memories available when that document finishes processing.

Supermemory also offers a self-hosted local binary with the Memory API, including profiles and graph memory, using an extraction model you supply. The managed platform adds hosted connectors and Supermemory MCP.

Consider it when: you want document chunks, a fact graph, and automatically maintained static and dynamic profiles from the same ingestion pipeline.

6. Engram-Locus

Engram describes Engram-Locus as a memory product with three tiers: episodes (timestamped records of interactions, decisions, and outcomes), abstractions (compressed summaries of patterns across episodes), and anchors (high-salience state that persists across agent lifecycles).

According to Engram, Locus creates new memories when incoming experience deviates meaningfully from expectation, using surprise-gated writing, and handles consolidation and pruning automatically. Engram advertises managed cloud and self-hosted deployment. Its SDK page says access is available to partners and enterprise customers, so confirm availability for your use case. These are vendor-described capabilities rather than independently tested results.

Consider it when: your design calls for novelty-based write decisions and explicit tiers for episodes, summarized patterns, and persistent state. Validate the vendor-described behavior on your data.

7. Weaviate Engram

Weaviate Engram, launched in April 2026, is a separate product from Engram.org. It is a fully managed memory service whose API accepts conversations, text, or pre-extracted facts.

Its processing pipeline transforms and commits memories asynchronously. Raw text and conversations undergo extraction; pre-extracted inputs skip LLM extraction. Transform steps support deduplication, merging, and conflict resolution. Enterprise plans support configurable pipelines, including optional buffering. Topics define what to extract and the required scopes, such as a user or conversation. Accepted ingestion requests return a run ID; completed runs report committed memory changes. Retrieval supports vector, keyword (BM25), and hybrid search.

Consider it when: you want managed extraction organized by topic, per-topic user or conversation scopes, and processing runs that show which memories were created, updated, or deleted.

Using GLiNER2.5 to build agent memory

Structured memory often starts with identifying the entities and relationships mentioned in documents or conversations. Our open-source encoder model, GLiNER2.5, extracts them according to a schema you define. The 194M-parameter base model is released under Apache 2.0 and can run locally on CPU, CUDA, or Apple MPS. You can also use GLiNER2.5 through Fastino's hosted API; the hosted inference guide includes extraction examples using GLiNER2.5 Multi.

To use these outputs in a memory system, define the entity and relationship types your application needs, then validate the extractions before storing them with source references and dates. For a knowledge graph, map the accepted entities and relationships to nodes and edges. The surrounding application handles identity resolution, updates to stored facts, access control, and retrieval.

Cognee provides a concrete example of GLiNER2.5 integration. Its local extraction demo defaults to GLiNER2.5. This extraction step needs no LLM key; the wider pipeline still needs an embedding provider. Cognee's auto mode selects the demo when no usable LLM key is configured. Cognee distinguishes the demo from its enterprise extraction offering.

Illustrative pipeline: GLiNER2.5 proposes candidate facts; the surrounding system manages their lifecycle.

To build an extractor for your memory pipeline, follow the local examples or the hosted API guide, then evaluate the extracted entities and relationships against labeled examples from your own data.

How to evaluate an agent memory solution

Start with your application's workload and define acceptable quality, freshness, latency, and cost. Use source-grounded test cases to make the comparison repeatable.

1. Build a small evaluation set from application sessions. Use representative conversations, documents, and tool outputs. Record the expected answer, required facts, or task outcome for each case. Review generated cases against their sources, and reserve some cases for testing after tuning.

2. Include updates and missing information. Cover corrections, superseded decisions, and questions the history cannot answer. Replay histories in order into isolated test state. For asynchronous products, score quality after processing completes and measure the delay until new facts become retrievable separately.

3. Compare against your current context pipeline. Run the same cases with consistent response models and context budgets where possible. Record configuration differences, task quality, tokens, latency, and cost, including writes. Inspect individual regressions as well as aggregate scores.

4. Inspect retrieval and the full agent. Capture traces of memory writes, retrieved context, tool calls, and final outputs where available. Check retrieval and answer quality separately to locate failures. Then evaluate the full agent integration, including multi-turn flows where relevant and whether it retrieves and uses the right information.

5. Verify applicable deployment requirements. Test user or workspace isolation and deletion through the integration you plan to ship. Include derived memories where relevant and check behavior against your access and retention requirements.

For broader test coverage, LongMemEval evaluates information extraction, reasoning across sessions, knowledge updates, temporal reasoning, and recognizing when the history does not contain an answer. Use it alongside examples from your own workload.

Add confirmed production failures to the regression dataset. Use the results to assess whether a solution meets your quality and operating requirements, and expand the evaluation as you learn more about the workload.

Conclusion

Memory is useful when it helps an agent build on earlier work: carry a decision forward, apply a correction, or trace an answer to its sources. Choose an integration your team can operate, then measure whether it helps on your own tasks.

Start with a small shortlist that fits your architecture and compare it with your current context pipeline. Use task quality, freshness, latency, and cost to decide which solution to adopt and which memory responsibilities to keep in your application.