AI agents with memory — how it actually works
AI agent memory is the difference between a session and a practice. There are three kinds — short-term, episodic, and procedural — and who owns them determines whether the agent is yours or the platform's.
The single feature that separates a toy agent from a production one is memory. Without it, every run is the first run. With it, the agent compounds — learning the user's preferences, avoiding prior mistakes, picking up context from weeks ago as if it were yesterday.
Three kinds of memory
Short-term (context window)
The transient memory of the current run — what the user said, what the agent has done so far in this session. Stored in the LLM's context window (100k–1M tokens depending on model). Lost the moment the session ends unless persisted elsewhere.
Episodic (session history)
What happened in prior sessions — user corrections, emergent preferences, outcomes of past work. Usually stored as a summary file or in a vector database. Loaded back into context when a new session starts, so the agent doesn't re-ask what it already knows.
Procedural (skills)
How to do a specific task — a reusable process definition the agent has internalized. Stored as structured skill definitions (Markdown files, YAML, or platform-native formats). Unlike episodic memory (which is 'what happened'), procedural memory is 'how I work.'
How implementations differ
No two AI platforms handle memory the same way. Some key differences:
- ChatGPT Memory stores global 'saved memories' and chat-history inferences. Opaque — you can't export or migrate.
- Claude Code uses CLAUDE.md files you control, loaded per project. Portable via git.
- Spawnlabs stores memory in MEMORY.md per agent, updated via a Haiku extraction pass after each session. Exportable, editable, and the agent moves with the expert.
- Custom agents on Anthropic SDK or LangChain manage memory manually — you decide what to persist and how.
Why ownership of memory matters
An agent without portable memory is a rental. When you leave the platform, the agent you trained goes with it.
This is fine for chat-style AI — few people care if their ChatGPT 'memory' doesn't move. It's not fine for an agent that represents you. If your recruiting agent has learned two years of your screening preferences, your reference check questions, your ATS tagging conventions — those are yours. Losing them when you switch tools is a tax you shouldn't pay.
This is why Spawnlabs built the MEMORY.md model. The agent is portable because the memory is exportable. Switch employers, switch firms, take the agent with you.
"An AI agent without portable memory is an agent on rent. Your work compounds on the platform's balance sheet, not yours.
— The Spawnlabs thesis on memory
Memory failure modes
What goes wrong when memory is bad:
- Memory drift — the agent's summaries of past sessions lose fidelity over time; it 'forgets' things it should remember
- Memory pollution — noise from one session contaminates another (cross-client leakage is the enterprise nightmare)
- Memory bloat — the memory grows until it doesn't fit in the context window, forcing lossy compression
- Memory confabulation — the agent 'remembers' things that never happened because the summary pass hallucinated
Good memory systems mitigate all four. Per-agent isolation (no cross-pollination), scheduled compaction (keep memory lean), and reliable summarizers (use stronger models for the extraction pass, not the cheapest ones) are the usual antidotes.
What to ask a vendor
If you're evaluating an agent platform for memory:
- Can I export the agent's memory?
- Does the agent remember things across sessions, or only within a project?
- Is memory isolated per agent / per client / per tenant?
- What's the compaction strategy as memory grows?
- Can I edit or delete memories?
If the answer to most of these is 'no' or 'it's proprietary,' the agent is a rental.