A user tells an assistant that a supplier contact has changed. Months later the agent still recalls the old name, because a summary extracted from an earlier conversation became persistent memory. The error is not necessarily in retrieval. The stored fact may no longer deserve to exist.
Memory is useful when information should survive a single prompt or conversation. It also creates a data lifecycle: deciding what to store, who may use it, when to refresh it, and how to correct or delete it.
Separate the kinds of memory
A conversation transcript, a thread checkpoint, an extracted preference, and a verified customer record have different meanings. A transcript records what was said; it does not certify that every statement was true. A checkpoint helps resume a workflow. A long-term store may hold selected facts across threads.
LangGraph's memory overview makes a useful distinction between short-term and long-term memory. Keep that engineering distinction separate from product claims about what an agent “knows.” The memory object needs its own source and authority.
Attach provenance to the fact
For a synthetic supplier contact, store the entity identifier, field, value, source record, observation time, validity period if known, and verification state. “The user mentioned a new contact” is weaker than “the approved supplier directory lists this contact effective today.”
A summary that removes the source, date, or qualification can turn tentative information into an apparently permanent fact. Keep the original evidence accessible under the same permission boundary when it is needed to resolve disagreement.
Extraction can introduce a new error
The Mem0 paper investigates extracting and maintaining information for scalable long-term memory. Its benchmark results concern particular datasets and evaluation choices. They do not prove that extracted memories are accurate for every enterprise entity or permission model.
Evaluate the memory writer as well as the reader. Did it identify the right person? Preserve negation? Distinguish a suggestion from a committed preference? Avoid merging two similarly named suppliers? A retrieval test cannot repair a wrong fact that was already stored.
Choose what expires
Different fields need different freshness policies. A temporary delivery address should not inherit the lifetime of a stable interface preference. A project-specific instruction should not silently apply to another project. Expiry can trigger deletion, re-verification, or exclusion from automatic use, depending on the data and obligation.
There is no universal time-to-live for agent memory. Use the task's meaning, source authority, retention policy, and consequences. An expired fact may remain in an audit record while being excluded from operational retrieval; those are different stores with different access rules.
Make correction and deletion real
When a source is corrected or permission is revoked, follow the derived data: summaries, embeddings, caches, exported briefings, and replicated stores. Removing one row is not complete removal if a stale summary still enters the next prompt.
Test a deletion request and then query through ordinary and alternate paths. Record what is actually removed and what must remain under a separate retention obligation. Do not promise erasure from a trained model when the system only deletes a retrieval-store entry.
Compare memory with a simpler baseline
A short approved profile or direct record lookup may solve the task more reliably than automatic conversation mining. Compare task success, stale-fact use, cross-user leakage, correction effort, latency, and storage cost. Include adversarial and contradictory updates, not just questions about facts the system correctly remembered.
The useful product claim is selective persistence under a clear data policy. Remembering more is not automatically understanding more, and forgetting appropriately is part of reliable behavior.