Memory is marketed as a capability: agents that learn your preferences, recall past tickets, build up context. In an enterprise it is also a database, and databases come with rules.
Kinds of memory, kinds of risk
- Working memory lives in the context window for one run. Risk: leaking into logs.
- Episodic memory stores past interactions. Risk: personal data persists beyond its purpose.
- Semantic memory holds distilled facts or embeddings. Risk: facts become stale, wrong, or poisoned.
- Procedural memory stores learned instructions or skills. Risk: a bad entry changes behavior for every future run.
Questions to answer before you store anything
- Whose data is it? Tag every memory with tenant, user, and source. Memories must never cross tenants.
- Why are we keeping it? A stated purpose lets you justify retention and delete when the purpose ends.
- How long? Set a time-to-live by default. Indefinite storage should require a decision.
- Who can read it? Retrieval must apply the *current* user's permissions, not the permissions of whoever created the memory.
- How do we delete it? Right-to-erasure requests must reach embeddings and summaries, not only raw transcripts.
Memory poisoning is real
If an agent writes memory from untrusted content, an attacker can plant a "fact" that influences later runs. Defend with provenance: store where each memory came from, prefer memories from trusted sources, and require review before promoting anything into procedural memory.
Keep memory inspectable
Give users and administrators a way to see, correct, and delete what the agent remembers. An agent that cannot explain what it knows about you will eventually be switched off by someone who is uncomfortable about it.
A pragmatic default
Start with no long-term memory. Add it per use case, with a written purpose, an expiry, and a deletion path. Most enterprise workflows get further on good retrieval from systems of record than on an agent's private notebook.