# Choosing agent memory _Updated 2026-08-21._ Memory is the layer most teams add too early and evaluate least rigorously. Before choosing a product, be precise about which problem you have: session state that survives a restart, facts about a user that should persist across months, or a corpus of documents you need to search. Those are three different problems and only the second is what memory products are for. ## Start with Postgres, not a memory product A messages table and a summaries table solves more cases than most teams expect, is trivially auditable, and imposes no new vendor on your compliance review. Move to a dedicated memory product when you can name the specific query it makes fast that your own schema does not. That is not a dismissal of the category — it is the order that avoids buying an abstraction before you understand the problem it abstracts. In the registry: [Postgres (rolled by hand)](https://newagent.build/c/postgres-memory), [pgvector](https://newagent.build/c/pgvector) ## Read the benchmark numbers sceptically Agent memory has an unusually unreliable benchmark culture. Most headline scores are produced by the vendor being measured, and independent re-runs have disagreed sharply. On LoCoMo, a long-conversation question-answering benchmark, one vendor's published figure is 92.5% while an independent evaluation of the same system reports 62.47%. Another vendor's 84% claim was corrected to 58.44% in a public re-evaluation of its own paper. The lesson is not that any particular product is bad. It is that a single vendor-published number tells you almost nothing, and that the spread between evaluations is larger than the spread between products. Ask who ran the benchmark and with which judge model before you weight the result at all. In the registry: [Mem0](https://newagent.build/c/mem0), [Zep](https://newagent.build/c/zep), [LangMem](https://newagent.build/c/langmem), [Letta](https://newagent.build/c/letta) ## Retrieval and reasoning are different models of memory Most memory products embed conversation history and retrieve the nearest chunks — fast, familiar, and prone to returning things that are similar rather than things that are true. A newer approach treats memory as a reasoning problem: a model extracts preferences, beliefs and contradictions in the background, and you query it in natural language rather than searching a vector store. Pick by question shape. If you need 'what did the user say about X', retrieval is right. If you need 'what does this user actually want', a user-modelling approach fits better. In the registry: [Honcho](https://newagent.build/c/honcho), [Supermemory](https://newagent.build/c/supermemory), [Cognee](https://newagent.build/c/cognee) ## Common questions ### What is the difference between agent memory and RAG? RAG searches a corpus you own — documents, tickets, code. Memory persists what the agent learned from interacting with a particular user or over a particular task, so it still knows it tomorrow. They solve different problems and most production agents need both. ### Are agent memory benchmarks reliable? Treat them with caution. Most published LoCoMo and similar scores are produced by the vendor being measured, and independent re-runs have differed from vendor claims by as much as 30 points on the same benchmark name. Always check who ran the evaluation. ### Do I need a memory product to build an agent? No. A messages table and a summaries table in Postgres covers a large share of real cases and keeps the system auditable. Adopt a memory product when you can name the query it makes fast that your own schema cannot. ## Machine interfaces - `GET https://newagent.build/api/registry` — every component as JSON - `GET https://newagent.build/api/vendors` — vendors, with the repo and releases feed to watch - `GET https://newagent.build/api/advise?q=` — recommended stack for a description - `GET https://newagent.build/api/stack?=&format=sh|json|md|yml|agents|env` — a stack as files - `GET https://newagent.build/llms.txt` — the whole registry in one fetch Any page here also returns markdown if you send `Accept: text/markdown`.