Long-term storage
Memory across tasks: what's worth persisting, retrieving it without re-injecting everything, and why most 'memory' should just be your database.
Short-term memory dies when the task ends. Long-term memory persists across tasks — so the agent resolving today's ticket from a customer knows about the refund it issued them last week. Powerful, oversold, and mostly a database problem wearing an AI costume.
What's actually worth persisting
- Facts with a home already — a customer's order history, prior tickets, past resolutions. These belong in your database, retrieved by a tool (
customer_history), not in some special 'agent memory'. The agent doesn't need to remember the last refund; it needs a tool to look it up. This covers 80% of real 'memory' needs. - Learned preferences — 'this customer prefers email over phone', 'this account is a VIP'. Structured fields on the customer record; a tool reads them. Still just data.
- Genuine episodic memory — 'a similar case last month was resolved this way'. This is the one case that resembles the AI-flavored version: embed past case summaries, retrieve similar ones by similarity when a new case arrives. It's RAG over your own history — the entire Building RAG pipeline, pointed at a resolution log.
Retrieval, not re-injection
The naive version — dump the customer's entire history into every agent's context — overflows the window and buries the relevant fact among fifty irrelevant ones (position effects again). The disciplined version: store richly, retrieve selectively. A tool call fetches the three relevant prior interactions when the agent asks, shaped and capped, exactly like any other tool result. Memory becomes retrieval, and you already know how to do retrieval well.
- Write memory deliberately, not automatically. An agent that persists everything creates a polluted store that retrieves noise. Decide what's worth remembering (resolutions, preferences, flags) and write only that — a
record_resolutiontool, not a background transcript dump. - Version and scope it. Memory is data: it has owners, retention limits, and privacy obligations. 'The agent remembers' is a data-governance statement — a customer's right-to-be-forgotten request must reach the agent's memory too.
- Stale memory is confidently wrong memory. A remembered 'VIP' who churned, a preference that changed — the same stale-truth failure from RAG, now steering actions. Memory needs the same freshness discipline as an index.
Products market 'the agent learns and remembers' as emergent intelligence. Under the hood it's writes to a store and retrievals from it — engineering you can reason about, test, and govern. Insist on that framing: an agent memory you can't query, audit, and delete from is a liability, not a feature.