Agent Memory Is a Data Modelling Problem

Look at who wins the single-hop column: not a memory system, but a model reading the entire history in its context window. When the whole conversation fits, the model can see both the old fact and the new one and work out which came later. Put a memory layer in between, and the question “which of these is current?” has to be answered by the data model — and most memory layers don’t model it at all.

The bigger 2026 benchmark says the same thing louder. MemoryArena, presented at ICML 2026, runs agents through 701 multi-session tasks where later sessions depend on decisions from earlier ones — plan a group trip across several conversations, finish a shopping bundle started last week (He et al., ICML 2026). On group travel planning, no method completed a single task — a success rate of 0.00 across all 13. The best on bundled shopping was 0.12. And the authors’ headline: agents “with near-saturated performance on existing long-context memory benchmarks like LoCoMo perform poorly in our agentic setting.”

So here is the claim this article defends:

1. Agent memory is a write-path problem. Extraction, reconciliation, supersession and forgetting decide what the agent can know. Retrieval can only return what the write path left behind.
2. The write path is a data-modelling problem. Scope, provenance, validity windows, lifecycle state and expiry are fields and indexes, not prompts. They are designed from access patterns — the same discipline as any other document schema.

That second point is home turf. In But Does MongoDB Support Transactions? I argued that document modelling is a design space driven by how the application reads and writes, not a single normal form. Agent memory is that argument with an LLM as one of the writers — a writer that is fast, tireless, and occasionally wrong about what it just heard.

Frameworks use different words for the same split. LangGraph’s documentation names semantic memory (“facts about a user”), episodic memory (“past agent actions”), and procedural memory (the agent’s own instructions) (LangChain, 2026). MongoDB’s LangGraph integration adds a fourth, associative — entities and the relationships between them (MongoDB, 2025). They map cleanly:

Working memory gets its own discipline — what goes into the prompt, in what order, at what cost. That is context engineering, covered in Prompt Engineering, and the cost side lives in Inference and Serving: every remembered token you inject is a token you pay prefill for on every turn.

Parametric memory is what Fine-Tuning writes to. It is tempting as a memory layer — no retrieval step, no prompt bloat — and it is the wrong place for anything about a specific person. The European Data Protection Board’s 2024 opinion on AI models sets a high bar for claiming a trained model holds no personal data, and notes that remedying unlawful processing can extend to deleting the training set or the model itself (EDPB, Opinion 28/2024). A fact in a document can be deleted with one query. A fact in the weights needs a retrain.

The rest of this article lives in the two middle layers — factual and experiential — because that’s where memory becomes a database design problem.

A few of these fields deserve a sentence each, because they’re the ones teams skip.

slot with cardinality. This is the Buddy-and-Scout fix. Declaring that city holds one value and pets holds many turns a judgement call the LLM gets wrong into a rule the reconciler enforces. Keep a small predicate registry — city: one, contact_channel: one, pets: many, allergy: many — and let free-text memories without a slot fall back to LLM judgement.

text and embedding embed the rendering, not the raw turn. “We moved to Rotterdam last week” embeds close to moving-house chatter. “Sanne’s team is based in Rotterdam” embeds close to the questions you’ll actually ask. This is the same point What Are Vector Embeddings? makes about chunking — what you embed decides what you can find. LongMemEval’s authors found the same lever from the benchmark side: “fact-augmented key expansion” — indexing memories under extracted facts rather than raw sessions — improved recall (Wu et al., ICLR 2025).

source.trust. A fact the user stated about themselves, a value a tool returned, and a sentence inside a forwarded email are three different grades of evidence. Record which one you have. §08 shows what happens when you don’t.

recorded_at separate from valid_from. Sanne moved on 26 May and mentioned it on 2 June. Those are different facts about the fact, and §05 needs both.

Everyone converged on this shape

The strongest argument that memory is a data-modelling problem is that every platform vendor, working independently, shipped a data model:

Scope, unit, history, expiry. Nobody shipped “a vector index with a prompt on top”. If you’re building on a general-purpose database rather than one of these services, these four columns are your minimum schema.

1. Hard expiry with TTL indexes

Some data has a known shelf life. Raw episodes are evidence for extraction and audit; after the reconciler has processed them and your audit window has passed, they should go. MongoDB’s TTL indexes delete documents automatically: a background task “runs every 60 seconds”, and deletion isn’t instantaneous at the expiry moment (MongoDB Docs, “TTL Indexes”).

The pattern that fits memory best is a per-document expiry date: index an expireAt field with expireAfterSeconds: 0, and each document expires at whatever time you wrote into it. Documents that lack the field, or hold a non-date value, never expire (MongoDB Docs, “Expire Data from Collections”). That gives you pinning for free: a safety-critical memory like Sanne’s peanut allergy simply has expireAt: null. A partial TTL index can go further and expire only documents matching a filter — only quarantined memories, say.

Two constraints to design around: TTL indexes can’t be compound, and they can’t sit on _id. So expireAt is its own single-field index, and the worker that decides retention writes the date.

2. Soft decay with scores

Most memories don’t have a known shelf life — they have declining relevance. That’s what the Generative Agents paper modelled in 2023, and its formula is still the reference. Each memory gets three scores, each min-max normalised to [0, 1]: recency, an exponential decay since the memory was last retrieved with a “decay factor [of] 0.995” per game hour; importance, an LLM rating from 1 (“purely mundane (e.g., brushing teeth, making bed)”) to 10 (“extremely poignant (e.g., a break up, college acceptance)”); and relevance, cosine similarity to the current query. The final score is their weighted sum, with “all α’s set to 1” (Park et al., UIST 2023).

Decay is the forgetting mechanism hiding inside that retrieval formula. Memories that stop being retrieved drift down the ranking; memories that keep being useful get their clocks reset. Push the same idea into storage and you get archival: when a memory’s standalone strength (importance × recency, without a query) falls below a threshold, mark it archived so it drops out of the default retrieval filter — and set an expireAt a few months out so it’s deleted if nobody revives it.

Tune the rules below and watch which of Sanne’s memories survive to September. Then switch off pinning.

Look at the dogs. At the defaults, Buddy is archived by April and Scout by August — importance 3, never recalled. Whether an agent should forget a pet’s name is a product decision, and it’s one you make with the importance scale and the pinning rules, not by nudging the half-life until the allergy happens to survive.

3. Consolidation

The third mechanism turns many memories into fewer, better ones. Generative Agents did this with reflection: when the summed importance of recent events passed 150, the agent wrote higher-level insights, which happened “roughly two or three times a day” (Park et al., 2023). Google’s Reflective Memory Management paper, which Google cites as the basis of Vertex AI Memory Bank, summarises at utterance, turn and session granularity and reports more than 10% accuracy improvement on LongMemEval over no memory management (Tan et al., ACL 2025).

In document terms, consolidation is a background job that reads a cluster of related memories, writes one new memory with source.memory_ids pointing at the inputs, and marks the inputs superseded. That’s the export-timeout lesson in the timeline above becoming a runbook entry. It’s the same job as sleep-time compute, and it belongs in the same background worker as reconciliation.

The one-timestamp trap

One detail from reading the LangGraph MongoDBStore source matters because it’s so easy to copy. The store’s TTL index sits on updated_at, and with refresh_on_read enabled, reading an item bumps that same updated_at (langchain-mongodb source). That’s a reasonable default for a generic key-value store — access keeps things alive. For memory it conflates two facts you’ll want separately: when did this change? (audit, reconciliation) and when was it last useful? (decay). Keep recorded_at, access.last_accessed_at, and expireAt as three fields, and let the decay worker compute the third from the other two.

And importance shouldn’t only rank memories — it should gate whether they’re eligible to decay at all. An allergy, a legal hold, an explicit “never contact me by phone” are not memories you want an exponential curve deciding about.

Pre-filter, then search exactly

In MongoDB, steps 1–3 are one $vectorSearch stage. Any field you filter on must be declared as a filter field in the vector index, and the filter supports the usual comparison and logical operators — $eq, $in, $gte, $and, $or and friends (MongoDB Docs, “$vectorSearch”). Filter types include strings, booleans, dates, numbers, ObjectIds and UUIDs (MongoDB Docs, “Index fields for vector search”).

Here’s the non-obvious bit. A single user’s memory set is tiny — Sanne has 38 memories, and even a heavy user of a support agent rarely passes a few thousand. After the scope filter, an approximate HNSW search is solving a problem you don’t have. MongoDB’s own multi-tenancy guidance says as much: for many tenants (up to 1 million) with fewer than 10,000 documents each, use a flat index instead of the default HNSW (MongoDB Docs, “Multi-tenant architecture”). A flat index does an exhaustive search — 100% recall, with latency that grows linearly in the filtered set, which here is 31 documents. The same logic applies to exact: true at query time.

vectorSearchScore is normalised to 0–1, so it can be added directly to the other two components. Cosine is the right similarity here for the reasons in Euclidean, Cosine, or Dot Product? — you care about direction of meaning, not vector magnitude.

Tune the blend for your workload, not the paper’s

The Generative Agents weights — all three components at 1 — are a reasonable default. The decay constant is not. That paper’s 0.995 per game hour ran in a simulated town whose entire study covered two in-game days. Carried into wall-clock time it gives a half-life of about 138 hours, just under six days: a customer who contacts support once a month would find every memory about them faded to near zero between visits. The pipeline above uses an 8-week half-life instead. The right number comes from how often your users return — measure it before you pick it.

Try it on Sanne’s offsite question. The playground switches archival off and scores eight of her memories, so the ranking alone does the forgetting — the same 8-week recency curve as §06, applied at read time instead of in storage. Its context budget is three — tighter than the pipeline’s five — so you can see the cut. Then set importance to zero and watch what falls out of context.

Load late, not early

The last decision is when memories enter the context. Anthropic’s context-engineering guidance argues for “just in time” retrieval: keep “lightweight identifiers (file paths, stored queries, web links, etc.)” in context and let the agent pull details through tools when it needs them (Anthropic, 2025). Letta’s filesystem result is the same idea from the benchmark side — agents are good at searching files because post-training for coding taught them to be (Letta, 2025).

The document design supports both modes. At session start, load the small computed profile from §04 — a few hundred tokens of pinned, high-importance, single-valued facts. Everything else is available through a recall(query) tool that runs the pipeline above. You pay for five memories when they’re relevant, not fifty on every turn.

Two write patterns carry most of the load. Idempotent capture: agent loops retry, so capturing an episode must not duplicate it. Key it by session and turn number and use $setOnInsert, so a retry is a no-op:

A unique index on { session_id: 1, turn: 1 } makes that safe under concurrency. Reinforcement on read: when recall returns a memory, bump its access fields — and only its access fields:

Then make provenance non-optional. A $jsonSchema validator that requires scope.tenant, scope.user_id, status, source.trust and source.episode_ids on every memory means the database refuses a memory it can’t scope, trust-grade, or erase. That’s the same move as the schema-validation section of the SQL-engineers article: the rules you care most about belong where no code path can skip them.

How to know it works

Public benchmarks tell a clear story about what’s hard, and a murky one about who’s best.

The murky part first. Mem0’s paper ran Zep on LoCoMo and reported 66.0%. Zep reran itself, called the setup wrong — both speakers assigned the user role, timestamps pasted into message text — and reported 75.1%, later correcting its headline margin over Mem0 to 10% (Zep, 2025). Letta’s filesystem agent scored 74.0% (Letta, 2025). All three are vendors measuring their own products, on a benchmark whose conversations — about 300 turns and 9K tokens on average — now fit comfortably in a context window (Maharana et al., ACL 2024). Treat any single LoCoMo number as marketing.

The clear part is the direction of travel. The 2024 benchmarks asked can you recall it? The 2026 ones ask can you update it, forget it, and act on it? — and that’s where scores fall.

• LongMemEval (ICLR 2025) added knowledge updates and abstention as scored abilities, and found commercial assistants and long-context LLMs lose about 30% accuracy across sustained interactions (Wu et al., 2025).
• MemoryAgentBench (ICLR 2026) made conflict resolution — now called selective forgetting — its own competency — the ≤ 28% multi-hop result from §01 (Hu et al., 2026).
• MemoryArena (ICML 2026) made memory a decision prior across sessions, and found external memory and RAG “not universally beneficial” — adding them to GPT-5.1-mini did not consistently beat its own full history (He et al., 2026).
• LongMemEval-V2 (May 2026 preprint) moved from chat to agent experience — workflows, environment gotchas, state that changes — over histories up to 115M tokens. The best method reached 72.5%; the strongest RAG baseline 48.5% (Wu et al., 2026).

None of these replace testing your own store. The eval discipline from Evaluation and Benchmarks applies, but memory needs probes that plain RAG evals don’t have. Most of them are deterministic assertions against the database, not LLM-as-judge:

Every row tests a field or an index from this article.

The vector store is the easy part. Pick the schema first.