Memory is not one thing
| Kind | Example | Main risk |
|---|---|---|
| Working context | The current task and tool results | The context window fills or becomes noisy |
| Conversation history | Earlier turns in a support chat | Old or incorrect assumptions persist |
| Saved memory | A user’s preferred format | A private fact is stored without clear consent |
| External knowledge | A searchable policy or document set | Stale or unauthorized data is retrieved |
A real example
An agent helping a content team might remember that a client prefers short LinkedIn posts during the current project. It should not permanently remember a private customer detail just because that detail appeared in one transcript. Good memory has a scope, an owner, a reason to exist, and a way for someone to inspect or delete it.
What memory should not do
Memory should not quietly become a second database of everything a user has ever said. Store only what improves a repeated task, make its source and age visible, and give users a way to correct it. Retrieval from approved documents is often safer than unconstrained personal memory.
The design question
Before adding memory, ask whether the same benefit can come from an explicit project brief or saved workflow. If a person cannot understand why a fact was remembered or how it changes the next action, the feature is probably storing too much.