Skip to main content
Without careful configuration, memory can lead to unexpected token consumption, behavioral issues, and high costs. This guide shows you what to watch out for and how to optimize your memory usage for production.

Quick Reference

  • Default to automatic memory (update_memory_on_run=True) unless you have a specific reason for agentic control
  • Always provide user_id. Don’t rely on the default “default” user
  • Use cheaper models for memory operations when using agentic memory
  • Implement pruning for long-running applications
  • Monitor token usage in production to catch memory-related cost spikes
  • Test with realistic data: 100+ memories behave very differently than 5 memories

The Agentic Memory Token Trap

The Problem: When you use enable_agentic_memory=True, every memory operation triggers a separate, nested LLM call. This architecture can cause token usage to explode, especially as memories accumulate. Here’s what happens under the hood:
  1. User sends a message → Main LLM call processes it
  2. Agent decides to update memory → Calls update_user_memory tool
  3. Nested LLM call fires with:
    • Detailed system prompt (~50 lines)
    • ALL existing user memories loaded into context
    • Memory management instructions and tools
  4. Memory LLM makes tool calls (add, update, and delete if enabled on the MemoryManager)
  5. Control returns to main conversation
Real-world impact:
As memories accumulate, each memory operation gets more expensive. With 200 memories, a single memory update could consume 10,000+ tokens just loading context.

Mitigation Strategy #1: Use Automatic Memory

For most use cases, use automatic memory. Each run still triggers one memory manager call that loads all existing memories, but the call runs in a background thread and keeps memory instructions and tool calls out of the main conversation context:

Mitigation Strategy #2: Use a Cheaper Model for Memory Operations

If you do need agentic memory, use a less expensive model for memory management while keeping a more capable model for conversation:
This cuts the cost of each nested memory call while maintaining conversation quality.

Mitigation Strategy #3: Guide Memory Behavior with Instructions

Add explicit instructions to prevent frivolous memory updates:

Mitigation Strategy #4: Implement Memory Pruning

Prevent memory bloat by periodically cleaning up old or irrelevant memories:

Mitigation Strategy #5: Set Tool Call Limits

Prevent runaway memory operations by limiting tool calls per run:

Common Pitfalls

The user_id Pitfall

The Problem: Forgetting to set user_id causes all memories to default to user_id="default", mixing different users’ memories together.
Best practice: Always pass user_id explicitly, especially in multi-user applications.

The Double-Enable Pitfall

The Problem: Using both update_memory_on_run=True and enable_agentic_memory=True doesn’t give you both. Agentic mode overrides automatic mode.

Memory Growth Monitoring

Track memory counts to catch issues early:

Developer Resources