The agent memory category changed quickly.
In 2024, "memory" usually meant one of three things: keep more chat history, summarize old messages, or retrieve chunks from a vector database.
By 2026, that is not enough. The state of the art in AI agent memory has moved toward structured, scoped, temporal, self-editable context systems. The interesting question is no longer only "what did the user say before?" It is:
What should the agent know right now, where did that knowledge come from, is it still true, who is allowed to see it, and how should it be assembled into context for this task?
That distinction is the whole category.
This article is a 2026 survey of AI agent memory frameworks - Mem0, Supermemory, Membase, Memory Store, Zep, Graphiti, LangMem, Cognee, CrewAI, LlamaIndex, and Graphlit - but it is also an argument: memory and context are related, but they are not the same layer.
Graphlit is focused on the context layer.
We have been writing about this distinction in a few recent pieces: the operational context layer AI agents actually need, the event clock for temporal facts, and context graphs as organizational memory. This survey puts the current agent memory landscape around that thesis.
The Short Version
There is no single "best" AI agent memory framework in 2026. The category has split into several different jobs:
- Memory APIs, where applications store and retrieve user, agent, session, or organization memories.
- Universal memory layers, where many AI tools share one personal or team memory.
- Temporal knowledge graphs, where facts and relationships evolve over time.
- Framework-native memory, where memory is part of LangGraph, CrewAI, LlamaIndex, or another agent loop.
- File or workspace memory, where coding and research agents save durable notes outside the context window.
- Context platforms, where agents retrieve source-grounded operational context from real systems.
Use a memory API when you need personalization.
Use a universal memory layer when users want memories to follow them across Claude, ChatGPT, Cursor, and other agent tools.
Use temporal graph memory when facts change and historical validity matters.
Use framework-native memory when you are still iterating inside one orchestration stack.
Use a context platform when the agent needs to reason across Slack, GitHub, Gmail, Jira, Linear, Notion, PDFs, meetings, tickets, code, and the web with provenance and permissions.
That last problem is where Graphlit fits.
Memory and Context Are Not the Same Thing
The words are often used interchangeably, but they describe different layers.
Memory is durable information the system can preserve across turns, sessions, tasks, users, or agents.
Context is the selected working set the model receives for a specific task. It includes instructions, recent messages, retrieved evidence, tool schemas, user state, organization facts, permissions, citations, intermediate results, and sometimes memories.
Put differently:
The model does not use memory directly. It uses context. Memory becomes useful only when the right pieces are retrieved, ranked, filtered, transformed, and inserted into the active context window at the right time.
This is why "agent memory" is becoming "context engineering." Anthropic's context management work, for example, separates active context editing from a memory tool that stores information outside the context window. OpenAI's Agents SDK sandbox memory similarly treats memory as durable workspace information that can be distilled and reused across runs.
The pattern is clear: durable memory is not the destination. The destination is better context assembly.
What Changed Since 2025
Five shifts matter.
1. Chat History Stopped Being Enough
Old memory systems mostly stored transcripts. Newer systems separate memory into facts, preferences, entities, episodes, procedures, files, plans, and tool outcomes.
Mem0 exposes memory operations such as add, search, update, and delete across user, agent, and session memory. Supermemory describes learned user context, graph memory, user profiles, and RAG over the same context pool. Membase stores memories as episodes, extracts entities, and links related entities and episodes in a knowledge graph. LlamaIndex memory now uses long-term memory blocks such as static memory, fact extraction memory, and vector memory rather than treating chat history as the whole story.
That is progress. But it also makes the category more confusing because "memory" can now mean several incompatible abstractions.
2. Temporal Memory Became Central
Agents fail when they cannot reason about change.
"Alice owns the account" is not useful if Alice moved teams last month. "The customer is blocked" is not useful if the issue was fixed yesterday. "The contract is worth $500K" is dangerous if the final renewal came in at $420K after a pricing exception.
This is why temporal knowledge graphs have become one of the strongest patterns in agent memory. Zep's graph overview describes a temporal knowledge graph with entities, relationships, facts, episodes, and validity dates. The Zep paper frames Graphiti as a temporally aware graph engine for dynamic conversational and business data.
We have been calling this the event clock: the layer that records not just what is true now, but how it became true, when it changed, and which source asserted it.
3. Self-Editing Memory Became Table Stakes
High-end memory systems increasingly let agents or background processes write, consolidate, correct, and prune memory.
LangMem provides hot-path memory tools and background memory managers for agents to extract, consolidate, and search long-term memory. CrewAI's current memory model uses a unified memory API with LLM-assisted scope, category, and importance inference. Cognee's remember operation can write to permanent graph memory or session memory, then bridge short-term content into longer-term graph structures.
This is a real advance over append-only logs. But it introduces a harder product question: who is allowed to update memory, which source wins when memories conflict, and how do you audit the result?
4. Benchmarks Moved Past Simple Recall
The research surface also changed.
The Mem0 paper evaluates long-term conversational memory across single-hop, temporal, multi-hop, and open-domain questions. The BEAM benchmark tests long conversations up to 10 million tokens and finds that long-context models still struggle as dialogues grow. LongMemEval-V2 evaluates whether agents can acquire environment-specific experience, like an experienced colleague who knows workflows, interface affordances, gotchas, and dynamic state. MemoryBench pushes toward continual learning from accumulated user feedback.
The important takeaway is not that one benchmark crowns one winner. It is that the field is fragmenting around different memory abilities: temporal reasoning, multi-session continuity, user feedback learning, workspace experience, long-horizon recall, and procedural improvement.
5. Context Engineering Became the Product
The best production systems do not simply store more. They decide what belongs in context.
That means:
- Selecting the right source evidence.
- Filtering by user, tenant, project, or permission.
- Resolving entity identity across systems.
- Preferring current facts without deleting historical ones.
- Keeping citations and provenance attached.
- Compressing or omitting stale tool results.
- Loading memories only when they are relevant.
Memory is the durable substrate. Context engineering is the act of turning that substrate into a useful prompt.
A Practical Taxonomy of Agent Memory
Most debates about AI agent memory are really debates about which memory type matters most for the application.
The last row is the one most "agent memory" conversations eventually run into. A memory layer that only knows what the agent discussed with a user is useful, but it is not enough for agents that need to operate inside an organization.
The organization already has memory. It lives in Slack, email, documents, meetings, issues, pull requests, support tickets, CRM notes, customer calls, and prior agent runs. The hard problem is turning that into reliable context.
The 2026 Agent Memory Landscape
Supermemory: Memory API and Graph Memory
Supermemory is one of the newer memory API platforms to watch. It combines learned user context, user profiles, graph memory, and RAG over the same context pool.
The product is explicitly trying to separate memory from plain RAG. Its Memory vs RAG guide argues that RAG is good for static documents, while memory needs user state, relationships, temporal context, and invalidation. Its graph memory docs describe facts connected to other facts through update, extend, and derive relationships.
Use Supermemory when:
- You want a hosted memory API for user context.
- You need memory and RAG in the same developer platform.
- You want automatic fact extraction, updates, forgetting, and user profiles.
- You need a fast integration surface for AI apps rather than a full source-ingestion platform.
The boundary is organizational context. Supermemory is moving beyond simple personalization, but its center of gravity is still learned user context and memory/RAG APIs. If the agent needs governed, multimodal operational context across many enterprise systems, you still need a broader context layer.
Membase: Universal Personal Memory
Membase positions itself as a personal memory layer for AI agents. The core idea is universal memory: instead of each agent keeping isolated notes, connected agents share one persistent memory layer.
Membase separates personal context from reference knowledge. Its docs describe Memory as personal context - preferences, decisions, habits, meetings - stored as a knowledge graph, while Knowledge Wiki stores factual reference material such as docs, specs, stable notes, and Obsidian-style markdown.
Use Membase when:
- You want memory to follow one person across many agent tools.
- You need cross-agent continuity for long-running personal work.
- You want a split between personal memory and reference/wiki knowledge.
- You are optimizing for Claude, Cursor, ChatGPT, and similar daily agent workflows.
The boundary is team and enterprise data modeling. Membase is strongest as a universal personal or small-team memory hub. For production apps that need API-first ingestion, workflows, entity extraction, multimodal content processing, and source-cited retrieval across tenants, it is a different layer.
Memory Store (memory.store): Shared MCP Memory
Memory Store is another new entrant in the universal memory category. It runs as an MCP server inside the agents people already use, so users can record and recall memories across Claude, ChatGPT, Cursor, Slack, and related tools.
Its user guide describes a simple tool shape: checkin loads active context, record stores facts/preferences/events/notes, and recall searches past conversations by topic, time, or entities. The product is aimed at context that follows a person or team across AI tools.
Use Memory Store when:
- You want an MCP-native memory layer for existing AI tools.
- You need lightweight cross-app continuity.
- You want humans and agents to record, recall, and reflect on shared memories.
- You care more about fast adoption than deep platform integration.
The boundary is the same: this is shared memory for AI tools, not a complete operational context platform. It is very relevant to the category, but it is closer to personal/team AI memory than to full content ingestion, knowledge graph infrastructure, and production retrieval APIs.
Other New Entrants Worth Watching
The memory category is moving fast enough that any survey will go stale quickly. A few other names are worth tracking:
- Hindsight by Vectorize focuses on agents that learn, not only agents that recall. Its cloud docs describe retain, recall, and reflect operations over dedicated memory banks.
- mem9 is aimed at persistent cloud memory for coding and agent stacks, with hybrid recall, a hosted dashboard, and an open-source/self-hostable path.
- Kumiho positions itself around graph-native, auditable memory with immutable revisions, typed reasoning edges, and background consolidation.
- Memora is a lighter-weight memory system for agents with a Python-facing developer surface and persistent memory primitives.
I would not treat all of these as equivalent to Mem0, Zep, Supermemory, or Graphlit yet. Some are early, some are focused on coding agents, and some are research-heavy. But they show where the category is going: memory is becoming graph-shaped, source-aware, multi-agent, inspectable, and increasingly delivered through MCP or agent-native tools.
Mem0: Managed Memory API
Mem0 is a dedicated memory engine for AI agents. It gives developers memory operations and hosted infrastructure around user, agent, and session memory, with graph memory and integrations in the broader platform.
Mem0 is attractive because it answers a very practical product question: how does my app remember what matters about this user or conversation without stuffing everything into the prompt?
Use Mem0 when:
- You need persistent personalization.
- You want a simple add/search/update/delete memory API.
- You have clear user, agent, and session scopes.
- You want hosted memory infrastructure rather than building your own.
- Most of the memory is produced by interactions with your AI app.
The boundary is operational context. A memory API can store extracted facts, but the hard enterprise work is often upstream: connecting sources, normalizing content, resolving identities, preserving provenance, enforcing permissions, and deciding which source is authoritative when facts conflict.
Zep and Graphiti: Temporal Knowledge Graph Memory
Zep and its open-source Graphiti engine have pushed temporal knowledge graphs into the center of the agent memory conversation.
This is one of the most important shifts in the category. If a memory system cannot distinguish "true now" from "true last quarter," it will eventually hand an agent stale or contradictory context.
Use Zep or Graphiti when:
- You care about changing facts and relationships.
- You need time-aware memory for users, entities, and business data.
- Conversation-derived facts matter.
- You want graph search, semantic search, and temporal validity in the memory layer.
The boundary is broader content infrastructure. Temporal graph memory is powerful, but production context usually also needs source connectors, workflow processing, multimodal extraction, access control, content lifecycle management, citations, and developer APIs around the graph.
LangMem and LangGraph: Framework-Native Memory
LangMem sits naturally inside the LangChain and LangGraph ecosystem. It gives agents tools to manage memory in the hot path and background processes to extract, consolidate, and update memory outside the main interaction.
This is the right level of abstraction for many teams. The framework should help decide when memory is written, when it is searched, and how the result enters an agent workflow.
Use LangMem or LangGraph memory when:
- Your agent is already built in LangGraph.
- You want memory as part of a graph workflow.
- You want explicit namespaces and storage control.
- You are experimenting with memory policy and agent behavior.
The boundary is that framework memory is a building block, not a complete knowledge platform. Once memory spans many sources, teams, permissions, and product surfaces, the storage and retrieval layer becomes infrastructure in its own right.
Cognee: Open-Source Graph Memory Pipeline
Cognee is one of the more interesting open-source graph memory projects. Its remember, recall, improve, and forget operations reflect a memory lifecycle rather than a simple vector-store wrapper.
Cognee's model is closer to a knowledge-engine pipeline: ingest data, build graph structures, enrich them, then retrieve from the resulting memory.
Use Cognee when:
- You want open-source graph memory.
- You want to own or customize the memory pipeline.
- You are comfortable operating graph, vector, and relational infrastructure.
- You want memory that can sit near LangGraph, MCP-compatible tools, or custom agents.
The boundary is product completeness. With open-source graph memory, you get control, but you also own deployment, scaling, permissions, evaluations, integrations, and the application APIs around it.
CrewAI: Multi-Agent Framework Memory
CrewAI memory is framework-native memory for crews, agents, flows, and standalone scripts. Its current docs describe a unified Memory class with semantic, recency, and importance scoring, plus hierarchical scopes.
Use CrewAI memory when:
- You are already building with CrewAI.
- Memory is scoped to a crew, agent, flow, or project.
- You want the framework to extract memories from task outputs.
- You need practical recall inside a multi-agent workflow.
The boundary is that CrewAI memory is not trying to be the canonical operational context layer for the whole company. It is a useful memory primitive inside the CrewAI execution model.
LlamaIndex: RAG and Agent Memory Blocks
LlamaIndex memory is strongest when memory is close to document-heavy RAG and agent workflows. Its memory blocks separate static information, fact extraction, and vector-based message retrieval.
Use LlamaIndex memory when:
- Your application is already built around LlamaIndex.
- Your agent needs memory tied to RAG workflows.
- You want configurable memory blocks and vector store integration.
- You need a practical bridge between short-term and long-term memory.
The boundary is again the data plane. LlamaIndex gives you strong components for indexing, querying, and agent memory, but teams still need to design source sync, identity resolution, governance, and operational context if the agent spans real business systems.
Anthropic and OpenAI: Memory as Context Management
The model platforms are also shaping the category.
Anthropic's context management work pairs context editing with a file-based memory tool. The goal is not just remembering more; it is keeping active context focused while preserving durable insights outside the context window.
OpenAI's sandbox memory points in a similar direction for agents that work in isolated environments: prior run information can be distilled into durable workspace memory instead of relying only on live transcript state.
This is important because it reframes memory as runtime infrastructure. The agent does not need every prior detail loaded all the time. It needs the right detail, retrieved at the right moment, in a form the model can use.
Comparison Matrix
Where Graphlit Fits
Graphlit is not an agent runtime. It is not primarily a chat personalization API. It is not trying to replace LangGraph, CrewAI, LlamaIndex, Mem0, Supermemory, Membase, or Memory Store.
Graphlit is the context layer underneath agents.
The starting point is different: memory is not only what happened inside the agent. The most valuable memory usually already exists in your operational systems.
That includes:
- Slack and Microsoft Teams messages.
- Gmail and Outlook threads.
- GitHub and GitLab issues, pull requests, commits, and files.
- Jira, Linear, Notion, Confluence, Zendesk, and Intercom.
- PDFs, Office documents, images, audio, video, meeting recordings, and web pages.
- RSS feeds, websites, Tavily, Exa, and other research sources.
Graphlit ingests that content, processes it through workflows, extracts entities and observations, builds searchable context, and makes the result available through search, RAG conversations, knowledge graphs, and MCP-native agent workflows.
The data model matters here. In Context Graphs, Honestly, we described Graphlit's durable shape as content, entities, facts, and conversations over time. In The Context Layer AI Agents Actually Need, we argued that agents need operational context before they can produce useful decision traces. In Building the Event Clock, we described facts as temporal assertions with validity periods and source evidence.
That is the difference between memory and context:
- Memory says: "The user mentioned Acme pricing before."
- Context says: "Acme is a customer, their renewal is in June, the pricing exception was approved by finance on March 12, the current ARR is $420K, the support escalation was resolved last week, and here are the source emails, tickets, and meeting excerpts that prove it."
The second answer requires ingestion, identity resolution, temporal facts, source provenance, permissions, ranking, and retrieval. It is not just a memory entry.
Recommended Architecture for Production Agents
For serious agent products, separate the agent runtime from the context layer.
The agent runtime owns:
- Task planning.
- Tool selection.
- Reasoning loops.
- Short-term working memory.
- When to retrieve context.
- When to write back memories, notes, or decisions.
The context layer owns:
- Source connectors and continuous sync.
- Multimodal ingestion and extraction.
- Entity resolution.
- Temporal facts and observations.
- Search, ranking, and graph traversal.
- Permissions and tenant isolation.
- Citations and provenance.
- Durable APIs for many agents and applications.
This lets you change models, orchestration frameworks, and agent patterns without rebuilding the organizational memory substrate.
For example:
- LangGraph, CrewAI, LlamaIndex, a coding agent, or a custom runtime handles the agent loop.
- Graphlit handles continuous context from data connectors, knowledge graphs, hybrid search, and source-grounded content workflows.
- The agent asks Graphlit for relevant context, then acts through MCP tools or application APIs.
That architecture matches where the category is going. Memory is not a monolith inside the agent. It is a set of durable stores, retrieval policies, context assembly steps, and write-back paths.
How to Choose an Agent Memory Layer
Ask these questions before choosing a framework or platform.
1. Is the memory personal, agentic, or operational?
If the memory is mostly user preferences, a memory API may be enough.
If the memory is mostly the agent's own state, use a stateful runtime or framework memory.
If the memory comes from real work systems, use a context platform with ingestion and provenance.
2. Does time matter?
If facts change, you need temporal modeling.
Storing "Alice owns Project Phoenix" is not enough. You need to know when that became true, whether it is still true, and which source says so.
3. Does provenance matter?
For consumer personalization, "the user likes concise answers" may be sufficient.
For enterprise and developer workflows, agents need citations:
- Which Slack thread?
- Which pull request?
- Which customer email?
- Which PDF page?
- Which meeting timestamp?
- Which prior agent run?
Without provenance, memory becomes a confident rumor.
4. Does access control matter?
If the memory layer blends private emails, engineering channels, support tickets, customer documents, and executive discussions, permissioning is not optional.
The context layer must respect who can read what.
5. Is memory a feature or infrastructure?
If memory is a feature in one app, choose a memory API or framework primitive.
If memory is the substrate for many products, agents, and workflows, choose infrastructure that can ingest, process, retrieve, govern, and audit context.
The Honest Conclusion
Agent memory in 2026 is not one category.
Mem0 is strong for managed long-term memory and personalization. Supermemory is strong for memory plus RAG over learned user context. Membase and Memory Store are strong for universal memory that follows users across AI tools. Hindsight, mem9, Kumiho, and Memora show how much experimentation is happening around learning, coding-agent memory, graph-native provenance, and lightweight persistent memory. Zep and Graphiti are strong for temporal graph memory. LangMem, CrewAI, and LlamaIndex are strong when memory belongs inside the framework loop. Cognee is strong for builders who want open-source graph memory infrastructure.
Graphlit is focused on a different layer: the operational context that agents need before memory becomes useful.
The most durable agent architectures will combine these layers. The agent runtime decides what to do. The memory layer preserves what should persist. The context layer assembles the right evidence, facts, entities, permissions, and citations for the task at hand.
That is the shift from "remember my last chat" to "understand the work."
If you are building agents over real organizational data, start with the context layer:
- Getting Started with Graphlit
- Building Knowledge Graphs
- Data Connectors
- Complete Guide to Search
- Graphlit Pricing
Memory matters. But context is what the model actually uses.