Memory Stores
The wrong store makes 'user.prefers_python' a 200ms vector search instead of a 2ms key lookup.
A filing cabinet, a search index, and a whiteboard — different jobs, different furniture.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Overview
Scroll inside the frame to explore · use + / − to zoom up to 200%
Scroll inside the frame to explore · use + / − to zoom up to 200%
A write
Scroll inside the frame to explore · use + / − to zoom up to 200%
Policy decides what to save. The store only persists it.
Key Takeaways
- 1.Pick a store for the query: KV for keys, vectors for meaning, graph for links. One product often uses more than one store.
- 2.The store is not memory policy — it only holds bytes. Latency and tenancy matter as much as recall quality.
- 3.KV for exact ids. Vectors for 'things like this'.
- 4.Graphs for 'related to'. Isolate tenants.
- 5.Measure p95 retrieve time. Memory logic lives in your code, not in the database brand.
Learn elsewhere
- →Vector databases — Phase 3
- →Long-Term Memory
Real Example
Scenario
User id → Redis prefs. Ticket recap → vector store. Org chart → graph. One agent, three stores.
What you would do
In Agent Memory, apply Memory Stores to this scenario: User id → Redis prefs. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
KV for exact keysVectors for similarityGraph for relationsPolicy ≠ database
Cheat Sheet
Quick recap
quick ref- •Furniture for the query
- •Often more than one
- •Tenant + latency
- •Policy sits above the store
Common Mistakes
- ✕One vector DB for every kind of memory
- ✕No per-user isolation
- ✕Letting the DB schema become the memory design