Concept · Memory architecture

What is an AI memory layer?

An AI memory layer is the part of an agent stack that decides what to remember, what to surface, and what to let go — so a model's knowledge of you survives past the end of a single conversation. This is the category primer: what the three operations actually mean, the architectures in production use today, and the honest tradeoffs between them.

Why models need one

A context window is not memory.

Large language models are stateless between calls. The context window is working memory for a single request: everything in it is gone the moment the response returns, and nothing in it crosses from one application to another. That is fine for a one-shot task and useless for a relationship — an assistant that forgets your name, your project, and last week's decision every time you open a new tab.

A memory layer is the durable store that closes that gap. It sits beside the model and does three things: it writes facts worth keeping to persistent storage, it reads the relevant ones back into the prompt at inference time, and it manages their lifecycle so the store stays useful as it grows. Every memory product — however it is marketed — is some arrangement of those three operations. The interesting differences are in how each is done.

The three operations

Store, recall, forget — what the words actually mean.

StoreExtract the durable facts from a conversation and write them to persistent storage — as embeddings, graph nodes, or both. The hard part is not writing; it is deciding what is worth keeping and how it relates to what is already there. Store everything and recall drowns; store too little and the memory is thin.
RecallAt inference time, find the memories relevant to the current turn and inject them into the prompt. Quality is set here, not at write time: a fact you saved but cannot surface at the right moment is functionally forgotten. Recall is a retrieval problem before it is a storage one.
ForgetLet stale, contradicted, or irrelevant memories lose priority — or be removed — so recall stays sharp as the store grows. A memory layer with no forgetting degrades into a junk drawer where the signal is buried under everything you ever said.
Architectures

Three ways to build one.

Almost every memory system in production is one of three shapes — or a blend of them. They differ mainly in how recall works and in what they can and cannot reason about.

ArchitectureRecall mechanismStrong atTradeoff
Vector storeNearest-neighbour similarity over embeddingsFast, simple, language-agnostic retrieval of similar textNo model of relationships or time; contradictions coexist silently
Temporal knowledge graphGraph queries over timestamped entities and relationsFacts that change over time; auditing when something was trueHeavier ingestion; graph construction leans on an LLM
Causal graphSimilarity fused with graph connectivity and reactivationExplaining why a memory surfaced; principled forgettingRicher write path; needs a scoring function that can be wrong

Vector stores

The simplest and most common shape. Memories are embedded as vectors and stored in a vector database; recall is a nearest-neighbour search for the memories most similar to the current query. It is fast, cheap, and works across languages. Its limits are structural: a vector store has no idea that two memories are about the same person, that one supersedes another, or that a fact was true last year but not now. Contradictions simply coexist. Mem0 is a widely used example — vector-first, with an optional knowledge graph layered on top for relationship queries.

Temporal knowledge graphs

Here memories are entities and the relationships between them, each carrying time. Recall is a graph query that can chain facts across sessions and respect when each fact was valid. This is the right shape when facts change — a job, an address, a preference — and you need to answer “what was true then” without losing history. Zep builds on Graphiti, a temporal knowledge graph that annotates every relationship with both when a fact was true and when it was first observed. The cost is a heavier ingestion path: constructing the graph usually leans on an LLM to extract entities and edges.

Causal graphs

A causal graph keeps a single graph of memory nodes joined by typed causal edges — this caused that, this updates that, this is contextfor that. Recall fuses similarity with graph connectivity and how recently each memory was reactivated, so the answer to “why did this surface?” is a real chain, not a guess. The same structure makes forgetting principled: a node can be pruned only when it is irrelevant, disconnected, and not pinned at once. The tradeoff is a richer write path and the need for a scoring function — which, like any model, can be wrong. This is the shape Genesys uses.

Honest tradeoffs

No architecture is free.

The choice is not about which architecture is smartest in the abstract; it is about which failure you can most afford. Vector stores are the cheapest to run and the hardest to keep clean — precision decays as unrelated-but-similar memories pile up. Temporal graphs handle change and contradiction gracefully but pay for it in ingestion cost and a dependence on the LLM that builds the graph. Causal graphs add explainability and disciplined forgetting, but they only pay off if the scoring function is good, and a scoring function is one more thing that can be tuned wrong.

The honest way to compare them is to fix a protocol and measure — same dataset, same answering model, same judge — and to publish what you lose as well as what you gain. Cross-vendor numbers quoted under different setups are not comparable, and a memory system that claims to only ever add correct answers has not measured carefully. See the LoCoMo benchmark page for how these systems score under one frozen protocol, and the methodology dossier for the full ledger, including the negative results.

A worked example

Where Genesys fits.

Genesys is an open-source causal-graph memory layer. There is one graph per user; the “layers” other systems keep as separate stores are just status tags on nodes, so edges never break as a memory ages. Recall scores every memory multiplicatively — relevance × connectivity × reactivation — and forgetting is conjunctive: a memory is pruned only when it is simultaneously irrelevant, orphaned, and unpinned. Because the whole thing is a graph you can open, every recall can explain itself.

Measured under the strictest published protocol, Genesys scores 85.55 ± 0.37 on LoCoMo, the mean of ten runs under a frozen gpt-4o-mini answerer and judge at temperature 0 (n=1,540, categories 1–4; evaluated July 2026) — published together with its ceiling, its run-to-run churn, and the questions it loses as well as the ones it gains. It speaks the Model Context Protocol, so the same memory is readable by any assistant that supports MCP connectors.

FAQ

Common questions.

What is an AI memory layer?

An AI memory layer is the part of an agent stack that persists facts across conversations, retrieves the relevant ones at inference time, and manages their lifecycle so recall stays useful as the store grows. It is what lets a model's knowledge of you survive past the end of a single chat. Large language models are stateless between calls; the memory layer is the durable store the model reads from and writes to.

What is the difference between a vector store and a knowledge graph for memory?

A vector store keeps memories as embeddings and recalls them by similarity search — fast and simple, but with no built-in notion of how facts relate or when they were true. A knowledge graph keeps memories as entities and relationships, so it can answer questions that require chaining facts or reasoning about time, at the cost of a heavier write path. Many systems combine both: Mem0, for example, is vector-first with an optional knowledge graph, while Zep builds on Graphiti, a temporal knowledge graph where event time is a first-class dimension.

What does forgetting mean in an AI memory system?

Forgetting is letting stale, contradicted, or irrelevant memories lose priority — or be removed entirely — so retrieval stays sharp instead of degrading into a noisy junk drawer. Good forgetting is conservative and legible: it should down-rank or prune only memories that are simultaneously irrelevant, disconnected, and not explicitly kept, never delete something a user still depends on.

Do I still need a memory layer if the model has a long context window?

A long context window is working memory for a single request; it does not persist anything after the response returns, and it does not span applications. A memory layer is durable and shared: it carries facts from one session to the next and, over a protocol like MCP, from one assistant to another. The two are complementary — the memory layer decides what is worth putting into the context window in the first place.

Which memory architecture is best?

There is no universal winner; the right architecture follows the workload. Vector stores are cheapest to run and hardest to keep clean. Temporal knowledge graphs model change over time well but pay for it in ingestion cost. Causal graphs add explainability and principled forgetting but need a scoring model. Genesys uses a causal graph and publishes its measured tradeoffs rather than claiming to have escaped them.