Part 1: The User Profile & Writing and Updating Memory
Key Points
- Long-term memory is an external, deletable store that sits alongside the context window (sensory memory) and short-term session history — not inside the model's weights.
- A user profile is a layered store: facts (stable), preferences (drift), episodic history (grows), and procedural rules (evolve slowly) — each retrieved and updated differently.
- Structured profiles give cheap, editable current-state snapshots; free-form collections give rich recall but need active reconciliation. The 2026 state of the art is a hybrid (vector + knowledge graph + key-value).
- Every memory ties to a stable
user_id so it follows the user across devices, sessions, and channels.
- Prefer background extraction, then reconcile each candidate via ADD / UPDATE / DELETE / NOOP rather than blindly appending; treat forgetting (decay + consent) as a first-class part of the write path.
The memory hierarchy
The mental model is a memory hierarchy that mirrors human cognition. The context window is sensory memory — immediate, finite, expensive, and prone to the "Lost in the Middle" failure where buried information becomes inaccessible. Short-term memory is the transient session history discarded when the session ends. Long-term memory is persistent context spanning sessions and devices — an external store you read from and write to.
flowchart TD
A["Context window (sensory memory) - finite, expensive, 'Lost in the Middle'"] --> B["Short-term memory - current session history, discarded at session end"]
B --> C["Long-term memory - persistent external store, spans sessions and devices"]
C -->|"read into prompt"| A
C -->|"write / update"| C
Facts, preferences, history, and procedural rules
A useful profile is not one undifferentiated blob. Facts are stable, verifiable statements ("Allergic to penicillin"). Preferences are softer tastes and defaults ("Prefers morning workouts"). History (episodic memory) is the record of past interactions, retrieved on similar situations. A fourth category, procedural memory, encodes behavioral rules in the system prompt ("stop apologizing so much") that evolve via feedback.
| Memory type | Volatility | Example | Retrieval trigger |
|---|
| Fact | Low | "Allergic to penicillin" | Almost always inject |
| Preference | Medium | "Prefers morning workouts" | Inject when topically relevant |
| History (episodic) | Grows continuously | "Solved a tax question this way last April" | Retrieve on similar situations |
| Procedural | Evolves slowly | "Keep answers concise" | Fold into system prompt |
Analogy. Think of the profile like a doctor's chart: the allergy list at the front is a fact (always consulted), "prefers first name" is a preference, the visit history is episodic memory you skim when the complaint resembles a past one, and the clinic's greeting protocol is procedural. Memory stores keep these separated for the same reason: they are consulted at different times and updated by different rules.
[Animation slot: Doctor's-chart profile with four labeled panels — Facts, Preferences, Episodic History, Procedural — each lighting up at its own retrieval trigger.]
Structured profiles vs. free-form collections
A profile is a task-specific schema with strict structure — ideal for a current-state snapshot that is cheap to load and trivial for a user to edit. A collection is an unbounded set of free-form documents searched at runtime via embeddings; it captures nuance a schema cannot anticipate but risks accumulating stale, contradictory entries unless actively reconciled. The trade-off is snapshot versus archive. The 2026 state of the art does not force a choice: leading systems use a hybrid architecture combining vector stores ("hippocampus"), knowledge graphs / GraphRAG ("association cortex"), and key-value / episodic storage, plus a reflection mechanism that synthesizes raw observations into higher-level insights.
Identity and multi-device continuity
None of this works unless you can answer "who is this?" Memory systems key retrieval on a stable identifier — Mem0's loop begins by querying with a user_id (and optionally an agent_id) plus the current input. That user_id is the anchor tying every device and channel back to one profile. Resolve two devices to two IDs and you fracture the user's memory; resolve two people to one ID and you leak one person's data into another's context.
Writing memory: the four operations
Once you extract a candidate memory, you cannot just append it — people move cities, change diets, and revise opinions. Systems reconcile new information against prior beliefs using semantic similarity, converging on four discrete operations.
| Operation | When it fires | Effect |
|---|
| ADD | New information with no existing match | Create a new memory |
| UPDATE | New information revises/contradicts an existing memory | Overwrite or consolidate the existing memory (refresh timestamp) |
| DELETE | Information is invalidated or revoked | Soft-delete / invalidate the memory |
| NOOP | Nothing new or durable to store | Do nothing |
Worked example. Given a stored memory "User lives in Chicago," the user says: "We moved to Lisbon in April. I'm still vegetarian. I no longer want restaurant recommendations near my old address. Nice weather today!" The extractor produces an UPDATE (Chicago → Lisbon), a NOOP (vegetarian already stored), a DELETE (revoked recommendation preference), and an ADD (new "no location-based recs" preference). "Nice weather today!" produces no operation — it is neither durable nor reusable.
flowchart TD
A["Raw conversation"] --> B["Extract candidate memory"]
B --> C{"Durable, specific, reusable?"}
C -->|"No"| N["NOOP: drop it"]
C -->|"Yes"| D{"Compare to existing memories"}
D -->|"No existing match"| ADD["ADD: create new memory"]
D -->|"Revises / contradicts a match"| UPD["UPDATE: overwrite or consolidate, refresh timestamp"]
D -->|"Invalidated or revoked"| DEL["DELETE: soft-delete the memory"]
D -->|"Identical to a match"| N
ADD --> S["Memory store"]
UPD --> S
DEL --> S
Forgetting, decay, and consent
A store that only grows becomes slow, expensive, and stale. Forgetting is a feature. It happens naturally, modeling the Ebbinghaus Forgetting Curve (traces decay unless reinforced by recency/frequency), and actively, when a user withdraws consent or exercises a deletion request. This is why retrieval relevance blends semantic similarity with importance and strength rather than raw age.
flowchart TD
A["Consolidated long-term memory"] --> B{"How is it forgotten?"}
B -->|"Naturally"| C["Ebbinghaus decay: influence fades over time unless reinforced"]
B -->|"Actively"| D["Consent withdrawn or erasure request"]
C --> E{"Reinforced by recency / frequency?"}
E -->|"Yes"| F["Strength restored, memory retained"]
E -->|"No"| G["Influence diminishes, fades from retrieval"]
D --> H["Targeted deletion of specific memories"]
[Animation slot: A memory's "strength" bar decaying along the Ebbinghaus curve, then snapping back up each time it is reinforced — contrasted with an instant "consent-withdrawn" deletion.]
Part 2: Reading Memory Into Prompts & Privacy and Governance
Key Points
- Reading memory is a RAG problem: retrieve the top-relevant memories by blending semantic similarity + importance + recency (strength), then inject them as a compact "Known user context" block.
- Always inject safety-critical facts (like allergies) and directly saved memories, bypassing relevance scoring entirely.
- Prefer structured summaries over raw transcripts to keep the injected block small and beat "Lost in the Middle." When memories conflict, recency wins — timestamps make this possible.
- Governance is a design constraint: redact PII at ingest (NER/regex, masking, tokenization/vaulting) and encrypt storage.
- Keep memory in an external, deletable store — never fine-tuned into weights, which cannot honor the right to erasure. Gate everything behind revocable consent and record per-memory provenance for auditability.
Selecting relevant memories
The context window is finite and expensive, and stuffing it with the entire profile triggers "Lost in the Middle." So you retrieve selectively. Mem0's runtime loop is the canonical pattern: at each interaction start, query the store with user_id, agent_id, and the current input; format retrieved memories into a "Known user context" section; let the LLM reason; then extract new facts and write them back (the ADD/UPDATE loop).
flowchart LR
A["Memory retrieval - query store with user_id, agent_id, input"] --> B["Prompt injection - format into 'Known user context'"]
B --> C["Agent reasoning - LLM processes enriched prompt and tools"]
C --> D["Memory extraction - identify storable facts"]
D --> E["Writeback - ADD / UPDATE existing memories"]
E -->|"next interaction"| A
Selection scores each candidate by blending semantic similarity to the query with importance and strength (recency/frequency). Some memory types bypass scoring: saved memories are always injected, and safety-critical facts like "Allergic to penicillin" deserve the same always-on treatment. For the query "suggest a dinner recipe," top matches like "vegetarian" (0.91) and "training for half-marathon" (0.68) are pulled, "Allergic to penicillin" is always injected, and "prefers morning workouts" (0.12) is excluded as off-topic.
Summarizing the profile for the window
Even selected memories can be too bulky if carried as raw transcripts. The remedy is to inject structured profiles and summaries rather than full conversation history. This is why the structured-profile shape pays off at read time — a current-state snapshot injects in a handful of tokens. A well-formed block is compact, human-readable, and cheap:
[Animation slot: A bloated raw transcript collapsing into a four-line "Known user context" block, with a token counter dropping from thousands to a handful.]
| Known user context (injected) |
|---|
| Diet: vegetarian |
| Allergies: penicillin (safety-critical) |
| Style: concise, bulleted answers |
| Current goal: training for a half-marathon (Oct 2026) |
Freshness and recency
When two memories conflict at read time, recency usually wins — a profile describes a moving target. Retrieval scoring folds in strength as a recency/frequency signal so newer, more reinforced memories outrank stale ones. Every memory object stores timestamps precisely to support this. When the UPDATE operation overwrote "Chicago" with "Lisbon," it also refreshed the timestamp, ensuring the read path surfaces the current truth.
PII handling and encryption
A store of durable personal facts is a liability as much as an asset, placing it squarely under regulations like GDPR. PII should be handled defensively at ingest: scrub input via token replacement or masking, using regex or pre-trained NER models to detect and redact sensitive values before storage. Complementary techniques include anonymization/pseudonymization (anonymized data is not "personal data" under GDPR, shrinking compliance scope), encryption of stored data and interactions, and strict access controls. Vendors like Skyflow and Lasso push further with tokenizing/vaulting: the raw value lives in a secure vault, and the memory layer handles only a token that stands in for it.
User control, deletion, and the erasure argument
GDPR requires clear, informed, revocable consent — an explicit opt-in users can withdraw at any time, enforced via consent-management APIs. ChatGPT models this well: users can turn off referencing saved memories or chat history, edit what the assistant knows, or use Temporary Chat to interact without using or updating memory at all.
The right to erasure ("right to be forgotten") drives the chapter's decisive argument: honoring erasure is straightforward for an external store — you delete the record — but nearly impossible once data is absorbed into an LLM's weights during training. Models have an "indelible memory" with no practical unlearning mechanism and no "delete button." This is the decisive reason to keep user memory in an external, deletable store (vector DB, knowledge graph, key-value) rather than fine-tuning it in. This also connects to data minimization and retention: TTL auto-deletion maps directly onto memory-decay mechanisms — good decay design is good retention design.
Auditability
Complying with erasure must be operationally feasible: systems must trace data origins so a request can be honored end to end. Every memory object should carry provenance — which conversation it came from, when, under what consent — so that when a user says "forget everything I told you last March," you can actually find and delete it.
| Governance requirement | Concrete mechanism |
|---|
| Consent | Explicit opt-in, revocable; consent-management API; Temporary Chat |
| PII protection | NER/regex redaction, masking, tokenization/vaulting, encryption |
| Right to erasure | External deletable store, not trained-in weights |
| Data minimization / retention | TTL auto-deletion, decay |
| Auditability | Per-memory provenance and origin tracing |