Long-Term Memory Best Practices
Ten practices for deciding what to persist, how to store it, and how to keep it accurate as agents span many sessions.
Use this list when designing personalization, support continuity, or any agent that should "remember" without becoming a black hole of stale text.
How to Use This Checklist
- Walk top to bottom during design reviews; early items block later complexity.
- Tick only what is true in production paths, not in slideware.
- Re-run after enabling extraction or a new memory vendor.
- Pair with a short ADR: schema, scopes, TTL, delete path, budgets.
- Treat unchecked high-risk items (identity filters, forget, secrets) as launch blockers.
A - What to Persist
- 1. Persist durable re-usable facts, not full transcripts, as online memory. Logs can archive chats; the agent should load curated profile fields and selected episodes.
- 2. Prefer systems of record for live business state. Store pointers and preferences in LTM; query CRM, billing, and tickets for current truth.
- 3. Separate profile keys (upsert) from episodes (append). One current timezone beats five contradictory free-text notes.
B - Write Discipline
- 4. Default to explicit saves; gate LLM extraction behind schema, confidence, and risk rules. Unfiltered auto-memory invents false personalization.
- 5. Record provenance on every write. Source, timestamps, evidence, and optional TTL make conflicts and audits tractable.
- 6. Ship forget, correct, and delete-by-user with the first version. Memory without revocation destroys trust and compliance.
C - Read Discipline
- 7. Split always-on profile from top-k retrieval. Cap tokens; never dump the whole store into the system prompt.
- 8. Enforce principal and tenant filters on every read and write. Cross-user memory is a security incident, not a bugfix.
D - Lifecycle and Ops
- 9. Resolve conflicts with trust tiers and recency; soft-delete losers. Extraction must not overwrite user corrections.
- 10. Observe memory like a product surface. Log injected memory ids, write accepts/rejects, correction rate, and retrieval usefulness.
Applying the Habits in Order
| Stage | Habits | Exit criterion |
|---|---|---|
| Scope | 1-3 | Clear list of keys/episode types; SoR boundaries documented |
| Write path | 4-6 | Explicit tools + gated extraction + forget/correct APIs |
| Read path | 7-8 | Budgets + authz tests for isolation |
| Operate | 9-10 | Conflict policy + dashboards/alerts on memory quality |
Quick "Do Not Ship LTM" Signals
- No authenticated user or tenant key on rows.
- Memory is "whatever was in the last 50 messages" with no schema.
- No way for a user to see or erase what you stored.
- Secrets and tokens land in the same table as preferences.
- Nobody owns evals for wrong personalization.
FAQs
How many checklist items are mandatory?
Treat 6, 8, and secrets hygiene from 1-2 as mandatory. If 8 fails, do not store personal memory at all.
Can we start with a JSON file?
Yes for single-user prototypes if the interface still supports upsert, list-by-user, and delete. Plan the multi-tenant store before SaaS launch.
Does a vector database replace this checklist?
No. Vectors help retrieval rank episodes and docs. They do not define write policy, trust, or forget.
When is profile-only memory enough?
When continuity is a handful of stable prefs and defaults. Add episodic retrieval when past decisions matter and evals show the need.
Should product managers own memory keys?
Jointly with eng. PM defines user-visible preferences; eng defines schema, budgets, and isolation tests.
How often should we purge?
Run expiry jobs for TTL rows continuously; review inactive episodes on a quarterly product cadence; honor legal retention separately.
What is the most common production failure?
Stale or wrong prefs injected every turn with no forget path, so the agent confidently repeats a fixed error.
How does this relate to short-term memory?
Short-term carries the active session. These habits govern what crosses session boundaries. Use both deliberately.
Do multi-agent systems need extra rules?
Yes: one shared write policy and least-privilege namespaces per role so specialists cannot corrupt global profile state.
What metric proves LTM is helping?
Task success or user satisfaction lift on returning users, plus low correction rate on remembered facts - not raw memory count.
Should we disclose memory use in the product?
Yes for consumer trust and often for regulation. "What we remember" UIs pair well with habit 6.
Where do I go deeper next?
Use the architecture guide for tiering, extraction/retrieval articles for pipelines, and the vector section when search quality becomes the bottleneck.
Related
- Long-Term Memory: What Should Survive Between Agent Sessions - persistence criteria
- Long-Term Memory Basics - hands-on save/recall
- Memory Extraction: Deciding What's Worth Remembering - write-side filters
- Memory Retrieval: Surfacing the Right Fact at the Right Time - read-side budgets
- Memory Conflicts: Handling Contradictory or Stale Saved Facts - staleness and contradictions
- Architecture Guide: A Tiered Memory System for Production Agents - end-to-end tiers
- Short-Term Memory Best Practices - in-session counterpart
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.