---
title: "How to choose a memory system for AI agents"
description: "A rubric to choose a memory system for AI agents: the five tests to run on your own data, the criteria that separate architectures, and when to buy nothing."
canonical: https://past.dev/guides/choose-memory-system
last-updated: 2026-09-02
---
# How to choose a memory system for AI agents

Source: https://past.dev/guides/choose-memory-system

To choose a memory system for AI agents, run five tests on your own data before reading any vendor's numbers: change a fact and ask for both values with dates, backfill history with original timestamps, refer to one person three ways, ask a question the data cannot answer, and price the run at your volume. The tests take an afternoon, they separate architectures faster than feature lists, and the failures they surface are the ones that reach production.

## Start from the questions your agent must answer

Memory systems differ most on a few load-bearing behaviors, and which ones matter depends on the questions your agent will be asked. An agent that files reports needs current values after changes. A companion needs stable preferences. A compliance workflow needs evidence and dates. Write down ten real questions from your product before evaluating anything; they are the test set every candidate runs against.

- **Current-state questions.** "What is the seat count on the Acme contract?" requires [knowledge updates](/glossary/knowledge-update) to land: the newest value, with its date.
- **Historical questions.** "What was it before the renewal?" requires kept history: [supersession](/glossary/fact-supersession) rather than overwriting.
- **Cross-source questions.** "What has Bob reported this quarter?" requires [entity resolution](/guides/entity-resolution) across email, tickets and chat.
- **Unanswerable questions.** "What is the Meridian renewal date?" when no source states one requires [abstention](/glossary/abstention) rather than a guess.

## The five tests

Each test is one afternoon-sized script against a candidate system, using your data rather than a demo corpus.

1. **State a fact, change it, ask for the current value. Then ask what it was before.** Both answers should exist, with dates. Systems that overwrite fail the second question; systems that only append fail the first. [Facts that change over time](/guides/facts-that-change-over-time) explains the mechanics.
2. **Backfill a year of records with their original timestamps and ask a date question.** The answer must cite source dates rather than the import date. [Event time vs ingestion time](/guides/event-time-vs-ingestion-time) covers why systems fail this.
3. **Refer to the same person three ways: email signature, transcript name, chat handle. Ask a question that requires joining them.** [Testing entity resolution](/guides/testing-entity-resolution) has the full protocol.
4. **Ask something the data cannot answer.** The response should state that the evidence is insufficient, with an explicit [evidence status](/glossary/evidence-status) rather than a fluent guess.
5. **Price the memory layer at your write and read volume, including any model calls inside it.** Some architectures run a language model during ingestion; estimate that cost at your document rate before it surprises you.

## Criteria that actually separate architectures

| Criterion | The question to ask | Where the differences are |
| --- | --- | --- |
| Temporal model | Are facts dated, windowed, superseded? | Vector stores rank by similarity and recency; temporal stores keep validity windows |
| Entity model | Do sources join into one timeline per subject? | Resolution at ingestion versus none |
| Evidence | Do answers carry sources and dates? | [Provenance](/guides/data-provenance) built in versus reconstructed later |
| Uncertainty | Is there an explicit status for conflict and absence? | Status values versus always-answer |
| Deletion | Does erasing a source erase what only it supported? | [Deletion by source](/guides/gdpr-memory-deletion) versus best effort |
| Deployment | Managed, self-hosted, or library? | Where the data lives and who operates it |

Feature lists blur these differences because every product claims memory. The criteria stay separable only when tested; a system can advertise temporal support and still fail test two. For named head-to-heads, the [comparison pages](/vs/mem0) and [alternative pages](/mem0-alternative) walk specific products against these criteria with links to their documentation.

## When to buy nothing

A memory system is unjustified in three situations. A single-session tool whose context fits in the window needs [working memory](/glossary/working-memory) and nothing else. A read-only corpus that never changes is a retrieval problem, and a plain vector index serves it well. A prototype with ten users can re-send history and defer the decision; the arithmetic in [context window](/glossary/context-window) terms only bites at volume. Adopt a memory layer when facts change, sources multiply, or sessions accumulate, because those are the three pressures storage design actually answers.

## Where past.dev sits in this rubric

past.dev is built to pass the five tests as stated: facts carry event time, validity windows and supersession links; entity resolution runs at ingestion; recall returns dated, source-attributed evidence with one of four status values; deletion by source erases what only that source supported; deployment is managed or self-hosted in your own Postgres. The [quickstart](/docs/memory-api/quickstart) is the fastest way to run the tests, and the [benchmarks](/benchmarks) page documents how we evaluate recall on exactly these behaviors.

## Frequently asked questions

### What is the best memory system for AI agents?

The one that passes the five tests on your own data: current and previous values with dates, correct backfill by source timestamps, cross-source identity joins, explicit insufficient-evidence answers, and acceptable cost at your volume. Run the tests rather than comparing feature lists.

### Do I need a memory system or is a vector database enough?

A vector database retrieves similar text and serves static corpora well. You need a memory system when facts change and the current value matters, when sources must join into one timeline per person, or when answers need dates and evidence.

### How long does it take to evaluate an agent memory system?

The five core tests fit in an afternoon per candidate: they are scripts against the write and read API with assertions on the responses. Pricing at volume takes a spreadsheet and your real document counts.

## Related

- [Facts that change over time](https://past.dev/guides/facts-that-change-over-time)
- [Testing entity resolution](https://past.dev/guides/testing-entity-resolution)
- [Memory observability](https://past.dev/guides/memory-observability)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [How we evaluate recall](https://past.dev/benchmarks/methodology)