Your agent needs a memory policy, not more memory
"Give it memory" reads like a feature request. It is closer to a data policy. What gets stored, how long it lasts, who can read it back, and what right a user has to delete it. Skip that step and the product breaks in two directions at once.
The short version
5 things that decide this
- 01Agent memory is a data retention decision before it is a technical one. Storage, scope and expiry need answers before a single record is written.
- 02A tool vendor selling 'memory' has already made these decisions for you, usually toward storing more, for longer, than your product needs.
- 03Memory that is never scoped to a user or a session leaks context across people it should never reach.
- 04Memory with no expiry date is a growing liability, not a growing asset. Old context goes stale and still counts as personal data.
- 05A deletion request only works if you built a path for it. Retrofitting deletion into a memory store that was not designed for it is expensive.
"Give it memory" skips four decisions
A stakeholder asks for an agent that remembers the customer between sessions. That sentence hides four separate decisions. What gets written down, how long it stays, who can read it, and how it gets removed. Treat memory as one feature and a team builds whichever of those four is easiest, not whichever the product needs.
Most tooling vendors answer the question by shipping a memory store and calling it done. That is a product decision dressed up as infrastructure. It usually stores everything by default, keeps it indefinitely, and exposes deletion as an afterthought endpoint nobody tests until a user asks to use it.
Not every fact earns a permanent record
Most of what an agent sees in a conversation is disposable. A preference stated once, in passing, is not the same as a preference confirmed twice. Storing both at equal weight means the agent eventually acts on something the user never meant to stick.
- What is storedConfirmed facts, inferred facts, and task state are not the same category.
- How long it lastsEvery record needs an expiry, not a default of forever.
- Who can read itScoped to one user, one account, or shared across a team — decided, not assumed.
- How it gets deletedA user's delete request has to reach every place the fact was copied to.
Skip any one of these and the gap shows up later as a bug report or a data request the team cannot fulfil.
Scope is the setting that gets skipped
A memory store keyed only by 'the current chat' or 'the account' looks fine in a demo with one user. It breaks the moment two people share an account. A support agent's memory of one customer's issue can bleed into the next conversation when the key was never narrowed past the shared workspace.
The fix is naming the scope before writing the first record: user, session, account, or team. Each is a different key, and a fact stored under the wrong one is a fact the wrong person can eventually see.
No expiry date is a decision, not an oversight
Storage is cheap enough that nobody has to justify keeping a record. That is exactly the trap. A fact from a conversation six months ago still counts as personal data, even after it stopped being useful. Every day it sits there is a day a breach or a subpoena can reach it.
Give each memory category its own expiry. Task-scoped facts can expire with the task. Inferred preferences can expire faster than confirmed ones, because they were never verified. A record with no expiry field was designed by omission, not on purpose.
Questions this raises
01What should an AI agent actually remember?
Facts the user confirmed on purpose, task state that expires with the task, and inferred preferences labeled as inferred rather than stated. Treating all three the same is the most common design mistake.
02How long should agent memory persist?
As long as the category needs and no longer, set per category rather than as one global default. Task-scoped facts expire with the task. Confirmed preferences can last longer than facts the agent only inferred.
03Does giving an agent memory create a privacy risk?
Yes, if scope and deletion were not designed in from the start. A record with no owner, no expiry and no delete path is a liability the moment a user asks what the system knows about them.
Related
- What is a context window? →The model's working memory for one call, distinct from the persistent memory this post covers.
- AI agent development →How we design and build agents that hold state safely across sessions.
- How to connect an AI agent to your CRM →Where an agent's memory often needs to live once it touches customer records.
