process() calls. The LLM decides what to remember and when to recall it.
Enabling Memory
Enable memory when creating an agent:How Memory Works
When memory is enabled:- Memory catalog: The LLM sees a list of stored memory entries
- Read decisions: The LLM can request to read specific entries
- Write decisions: The LLM can store new information
- Persistence: Memory persists across
process()calls on the same agent instance
Memory in Action
Memory Operations
The agent has access to these memory operations:List Entries
See what’s stored in memory:Read Entries
Request specific entries by key:Write Entries
Store new information:Delete Entries
Remove outdated information:Monitoring Memory with Hooks
Track memory operations:Memory Across Tasks
Memory persists across multipleprocess() calls, making it useful for multi-step workflows:
Best Practices
- Meaningful descriptions: Help the LLM understand what each memory entry contains
- Structured keys: Use consistent naming like
user_name,project_status - Clean up: The LLM can delete outdated entries
- Don’t over-rely: Memory is for context, not a database
- Scope appropriately: One agent instance = one memory scope
Limitations
- Memory is per-agent-instance (not shared between agents by default)
- Large memory catalogs increase token usage
- The LLM decides what to remember (not deterministic)
Building Custom Memory
You can implement custom memory backends to persist data to external stores like Redis, PostgreSQL, or any other storage system. This is useful for sharing memory across agent instances or persisting memory beyond the process lifetime.Custom Memory Interface
Custom Memory Interface
To create a custom memory backend, implement the
Memory interface:Redis Memory Example
Redis Memory Example
Here’s a complete example of a Redis-backed memory implementation: