Memory Scopes
Fibonacci provides four memory scopes, each with different visibility and lifecycle:| Scope | Visibility | Use Case |
|---|---|---|
workflow | Single workflow | Execution history, intermediate results |
user | Single user across workflows | Preferences, conversation history |
organization | All users in organization | Shared knowledge bases, company data |
global | All workflows and users | Application-wide settings |
Basic Usage
Storing Memory
Retrieving Memory
Deleting Memory
Memory in Nodes
Nodes can read from and write to memory using template variables and thememory parameter:
Reading Memory in Prompts
Writing Memory from Nodes
Building Stateful Applications
Conversational Chatbot
Build a chatbot that remembers conversation history:User Preference Learning
Track and apply user preferences over time:Progress Tracking
Track multi-step process progress:Memory Patterns
Caching Expensive Operations
Rate Limiting
Session Management
Memory Configuration
Default Memory Backend
By default, Fibonacci uses an in-memory store. For production, configure a persistent backend:Memory Encryption
Enable encryption for sensitive data:Best Practices
Use appropriate scopes
Use appropriate scopes
Match memory scope to data sensitivity and sharing requirements:
workflow: Temporary execution datauser: Personal preferences, historyorganization: Shared resources, team dataglobal: Application configuration
Set TTLs for temporary data
Set TTLs for temporary data
Always set TTL for caches, sessions, and temporary data to prevent unbounded growth:
Use structured keys
Use structured keys
Use consistent, hierarchical key naming:
Handle missing data gracefully
Handle missing data gracefully
Always provide defaults when reading memory:
Limit history size
Limit history size
Cap array-based memory (like chat history) to prevent unbounded growth: