For anything that spans sessions you need retrieval.
Vector stores are the current default. Embed past steps, tool results, and user feedback. Retrieve the top-k relevant chunks when the agent starts a new step.
They are good for semantic similarity. They are bad at exact sequences and time.
Episodic memory
Store the actual trace: "on June 20 at step 4 I called the pricing API and got 429, then retried with backoff".
This is gold for debugging and for the agent to avoid repeating the same mistake.
A simple JSONL file or a small SQLite table works on consumer hardware. No fancy embedding required for the first version.
Persistent state
Some agents need durable facts.
- "The user's preferred region is eu-west-1"
- "Last successful backup was at 2026年06月23日T14:12Z"
Put this in a key-value store or a small Postgres. Update it explicitly when the agent learns something trustworthy.
Do not trust the LLM to remember it correctly inside the context.
When to add each layer
Start with good system prompts and short context.
Add vector retrieval when the agent needs to reference past research or documentation.
Add episodic traces when you see it repeating the same errors across runs.
Add persistent facts when user preferences or long-running state actually matter.
The goal is not maximum memory. The goal is the smallest memory surface that makes the agent reliable for the job.
Most production agents I have shipped use two or three of these stores. Never all of them at once until the pain was real.
If you are building agents that run for days or weeks, memory design is the difference between a demo and something you can trust overnight.
Ready to build your own reliable AI agents with proper memory? Start with AgentGuard: https://bmdpat.com/tools/agentguard
Originally published on bmdpat.com. I run a one-person AI agent company and write about what actually works.
Want these in your inbox? Subscribe to the newsletter - no spam, unsubscribe anytime.