# Memory Best Practices
SUMMARY: How to structure memories for effective recall — categories, keys, tags, priorities.

Memory Best Practices
How you structure memories determines how useful they are. This guide covers
patterns for categorizing, tagging, and prioritizing memories so the LLM can
recall the right information at the right time.
Categories: Pick the Most Specific
| Category | Use For | Example |
|----------|---------|---------|
|  | User name, role, contact info |  |
|  | Likes, dislikes, working style |  |
|  | Verifiable facts |  |
|  | Project status, decisions |  |
|  | User's skills |  |
|  | Past errors to avoid |  |
|  | Session-relevant context |  |
|  | Misc notes |  |
> [!TIP]
> When in doubt, use  for verifiable info and  for everything else.
> Don't over-categorize — better to have a clear  than a confusing .
Keys: Meaningful Identifiers
The  field is the memory's identifier. Use meaningful, stable keys:
Good keys:
- 
- 
- 
- 
Bad keys:
-  (not meaningful)
-  (not descriptive)
-  (date doesn't help recall)
Key naming conventions
-  (lowercase with underscores)
- Prefix with category: , , 
- Use descriptive nouns, not verbs
- Keep under 50 characters
Tags: For Search and Filtering
Tags enable fast filtering and search. Add 2-5 tags per memory:
[CODE BLOCK]
Tag patterns
- Project names: , , 
- Topics: , , , 
- Status: , , 
- Priority indicators: , 
> [!NOTE]
> Tags are case-insensitive. Use lowercase for consistency.
Priorities: Be Realistic
| Priority | Use For | % of Memories |
|----------|---------|---------------|
|  | User identity, legal info, irreversible decisions | 5% |
|  | Active projects, important preferences | 20% |
|  | Most facts, notes, context | 65% |
|  | Ephemeral, nice-to-know | 10% |
> [!WARNING]
> Don't mark everything . If everything is critical, nothing is.
> Reserve  for things that would cause real harm if forgotten.
When to Store vs Not Store
Always store
- User identity (name, email, role)
- Long-term preferences
- Project decisions and rationale
- Past mistakes and lessons learned
- Commitments made to the user
Don't store
- Transient state (use variables instead)
- Verbatim conversation history (chat system handles this)
- Sensitive data (passwords, API keys)
- Easily derivable facts (current date, file contents)
- Ephemeral context (use  category with low priority)
Updating Memories
POST  with the same  +  updates the existing memory:
[CODE BLOCK]
> [!TIP]
> Use stable keys so you can update without creating duplicates. The LLM
> should re-POST the same key as info changes, not create new memories.
Memory Lifecycle
[CODE BLOCK]
- Create: POST /memory with full context
- Active: Recall frequently, update as needed
- Stale: Still relevant but not actively used (lower priority?)
- Archive: Set priority to , keep for historical reference
- Delete: DELETE /memory/:id when no longer relevant
Periodic cleanup
[CODE BLOCK]
Pattern: Memory Inheritance
For hierarchical context (project → subproject → task):
[CODE BLOCK]
The LLM can then search  to find all related memories.
Pattern: Decision Log
Store decisions with rationale so the LLM doesn't re-litigate them:
[CODE BLOCK]
Pattern: Mistake Avoidance
Store mistakes with specific avoidance instructions:
[CODE BLOCK]
Anti-Patterns to Avoid
> [!WARNING]
> - Storing conversation logs — chat system handles this
> - Storing entire files — use script store or external storage
> - Storing ephemeral state — use variables
> - Storing secrets — use environment variables
> - Duplicating memories — use stable keys
> - Over-tagging — 2-5 tags per memory is ideal
> - Everything is critical — be realistic with priorities
Next Steps
- Memory API
- Persistent LLM Agent
- Memory Tagging Strategy