Agent memory needs correction, expiry, and deletion
Design persistent AI memory as an editable data lifecycle, with clear scope, evidence, conflict handling, and limits on what should be remembered.
An assistant that remembers a useful preference can save effort. An assistant that remembers a mistaken assumption can repeat it for months. Persistence makes both outcomes more likely unless memory has a clear lifecycle.
The design question is not simply whether an agent can store information. It is what qualifies for storage, who can correct it, how long it remains relevant, and whether later actions are allowed to rely on it.
Separate conversation state from durable memory
LangChain's memory overview distinguishes thread-scoped state from information retained across conversations. That distinction is useful beyond any one framework. A draft plan for today's task and a lasting preference about writing style have different scopes and different reasons to exist.
Do not automatically promote every conversation summary into a permanent user profile. A summary can contain guesses, temporary constraints, or facts about someone other than the account owner. Treat promotion as a deliberate application decision.
A scheduling example
Imagine a fictional assistant that helps a designer organize work. In one conversation, the designer says mornings are unavailable this week. If the system stores that as a permanent scheduling preference, future plans will be wrong even though the original statement was accurate.
A useful memory record would distinguish the fact, its scope, its source, and its expiry condition. The application might store a temporary constraint for a specified date range. It should not silently generalize one week into the person's usual availability.
Another statement, such as a preference for concise summaries, may be suitable for longer retention. Even then, the person should be able to change it. A preference is not an immutable identity attribute.
Define a write policy
Decide which types of information the product benefits from remembering. Prefer a small set of purposeful fields over an unbounded collection of personal observations. Exclude secrets and unnecessary sensitive details from ordinary memory.
Separate an explicit user instruction from an inferred preference. If the system infers something useful, consider asking for confirmation before making it persistent. Store enough provenance to explain why the record exists without retaining an entire private conversation unnecessarily.
Validate updates on the server. A model-proposed memory write should not be able to change another user's profile or rewrite application policy. Memory tools need the same authorization discipline as other database writes.
Resolve conflicts without silently combining them
Suppose the designer later says mornings are preferred. The system needs to determine whether this replaces a standing preference, applies to a specific project, or conflicts with a still-active temporary constraint.
Represent those scopes explicitly. A latest-message-wins rule is simple but can be wrong when statements refer to different periods. If the conflict affects an important action, request clarification rather than manufacturing a blended interpretation.
Preserve an understandable change history where the product needs auditability. The user should see the current effective memory, while an authorized operator can investigate how it changed. Avoid exposing unrelated past details just to explain one preference.
Retrieve memory selectively
Persistent storage does not mean every record belongs in every prompt. Retrieve only memories relevant to the task and permitted for the current context. Sharing a device or workspace should not automatically merge personal profiles.
Test with two users who have contradictory preferences. Then test a shared project where some facts belong to the project and others remain personal. These cases reveal accidental scope mixing more clearly than a long single-user demonstration.
Treat retrieved memory as data with provenance, not as a higher-priority instruction that can override the application's rules. A corrupted or malicious memory entry should not be able to grant new tool permissions.
Make forgetting testable
Provide ways to inspect, correct, and remove stored information. A deletion workflow needs to address the active store and relevant derived copies, such as retrieval indexes or cached summaries. Document any retention constraints that still apply to operational backups.
After deletion, test whether a new conversation still receives the removed fact through another route. The system might have deleted one record while retaining a duplicate in a summary. Verify behavior, not merely a successful delete response.
Memory earns trust when it remains accurate, scoped, and controllable. A smaller collection of useful, editable facts can serve people better than a large profile that the assistant cannot explain or reliably forget.