How to choose memory for smarter LLM agents

Agent memory is a modeling decision

A larger context window does not solve the memory problem for an AI agent. Context windows are finite, while useful facts, documents, and conversations may need to persist across sessions. Retrieval-augmented generation (RAG) can bring information back into an LLM’s context. Persistent memory creates another design question: what should the system remember, and how should that information behave later?

The answer shapes the architecture. Graphiti, Hindsight, Mem0, and Supermemory all extend memory beyond a model’s immediate context, but they represent it differently. Choosing an approach starts with the memory behavior the application requires.

Four systems show how differently “memory” can be defined

Graphiti puts temporal knowledge graphs at the center of its design. A temporal knowledge graph represents entities and their relationships while tracking how those relationships change over time. Graphiti bills itself as “the open-source temporal knowledge graph framework” and is available on GitHub or as the underpinning of the Zep agent memory service. Graphiti says it re-evaluates stored information over time so its context remains appropriately framed.

That model fits applications where relationships and their evolution matter. Graphiti supports Anthropic, Azure OpenAI, Google Gemini, Groq, and Ollama and OpenAI-compatible APIs, along with connectors for sources including GitHub, Gmail, OneDrive, and Notion.

Hindsight uses a different model. Available as a cloud service and a locally hostable project, Hindsight divides information from agent sessions into four memory types, each with its own storage and retrieval strategy. It exposes those memories through three programmatic interfaces: retain stores anything from a fact to a complete conversation; recall retrieves stored content; and reflect runs an agentic loop over a query using prior data.

For example, Hindsight’s Continue integration can add long-term memory to interactions with a locally hosted LLM in Visual Studio Code. A user can invoke relevant memory with the @hindsight keyword or configure editable auto-injection rules. Persistence becomes part of how the agent retrieves and reasons over prior information.

Mem0 also defines four basic kinds of memory, organized differently from Hindsight’s. Mem0 says each added memory goes through a distillation process and is routed to a vector DB, graph DB, or SQL DB according to its intended use. A vector database stores numerical representations of content so similar material can be retrieved by meaning. Mem0’s architecture ties the storage strategy to what a memory represents and how the application expects to retrieve it.

Supermemory starts with heterogeneous content. It says it ingests plaintext, structured data, PDF and Microsoft Office documents, video and audio, and images, then uses that material to build a context graph for agent conversations. Supermemory also promotes content extraction as a feature. Its model makes ingestion across multiple media and file formats part of the architectural choice.

“Persistent memory” can therefore mean several concrete models: temporally maintained graph knowledge, four typed memories exposed through retain, recall, and reflect, distilled memories routed among three database categories, or a context graph assembled from heterogeneous content.

Time and sharing turn persistence into a more specific requirement

Persistence means information survives. A memory architecture must also define what happens as information ages and circumstances change.

Graphiti says it explicitly treats time as part of its memory model. Stored information is re-evaluated over time to keep its context properly framed. Mem0 uses a different mechanism: older data is deprecated while remaining available, preserving larger long-term context. Hindsight also uses deprecation.

That creates a concrete choice about history. An agent dealing with changing facts may need previous information to remain available while its current status changes. Restoring an old session alone does not define that behavior.

Scope creates another requirement. Mem0 includes a separate type called organizational memory, designed for data shared among multiple agents or different teams. In Mem0’s model, memory ownership can extend beyond one agent to a shared organizational scope.

Teams can define two properties early: how changing information should behave over time, and who should be able to share it.

The memory model determines the infrastructure you inherit

The representation chosen for memory also determines what a team has to operate.

Graphiti’s graph-centered design requires a graph database for local use. Graphiti lists Neo4j as the default and most broadly supported option, while Amazon Neptune, FalkorDB, and KuzuDB also work. Postgres with pgvector is not listed as an option. Selecting Graphiti’s temporal graph model therefore brings graph infrastructure with it.

Local Mem0 has different requirements. Mem0 says it needs a Python instance and a vector database. Postgres with the pgvector extension is described as a common and simple choice and can be installed inside a Python venv. Mem0 supports Anthropic, Google Gemini, OpenAI, and self-hosted options including LangChain, LiteLLM, LM Studio, and Ollama.

Supermemory offers another deployment model. Its open-source edition is described as a single, self-contained binary, with no external database that needs separate provisioning.

Supermemory also distinguishes between its editions. The open-source version lacks the scaling services and third-party service connectors, including Gmail, Google Drive, and Notion, provided with the enterprise edition. Teams need to evaluate deployment structure and required operating capabilities separately.

Choose requirements before convenience

Start with the behavior the application requires. Determine whether it needs temporal knowledge, typed storage and recall with reflection, shared organizational memory, or heterogeneous and multimodal context.

Then define how history should be treated and who can share memory. Evaluate the infrastructure needed to implement that model. Graph databases, vector stores, SQL databases, Python environments, connectors, local binaries, and hosted services impose different operating requirements.

This sequence prevents deployment convenience from becoming an implicit memory-model decision.

Key takeaways for leaders

• Define what memory means first: Graphiti, Hindsight, Mem0, and Supermemory use different models for persistent memory. Choose based on required behaviors such as temporal relationships, typed recall, storage routing, or heterogeneous content ingestion.
• Plan for time and sharing: Persistence alone is not enough when facts change or memories need to cross agent and team boundaries. Define how historical information should be retained and who can access shared memory before selecting a system.
• Account for infrastructure requirements: Memory models bring different operational dependencies, from Graphiti’s graph databases to Mem0’s vector stores and Supermemory’s self-contained open-source binary. Evaluate those requirements alongside deployment and integration needs.
• Prioritize requirements over convenience: Start with memory behavior, history, and sharing requirements before comparing deployment options. This prevents infrastructure convenience from dictating an application’s long-term memory architecture.