How It Works
Key Features
Separate short-term and long-term memory systems
4-metric quality assessment for stored memories
User, agent, and run-specific memory scoping
Automatic entity extraction and storage
Optional Neo4j/Memgraph for relationships
Quality-based filtering and relevance ranking
Quick Start
1
Simple — enable with True
2
With config
Direct Memory Access
Memory Tiers
Short-term Memory (STM)
Short-term memory is cleared between sessions and used for immediate context.memory.reset_short_term() / .reset_long_term() now work on the default rag / chroma provider, not just sqlite / in_memory and dakera. On sqlite / in_memory providers, reset_* / delete_* delegate to the active adapter (mirroring search_short_term), so they operate on the adapter-created short_term_memory / long_term_memory tables.
Adapters that don’t implement
reset_short_term / reset_long_term now log a warning stating the tier was NOT cleared, instead of silently succeeding — check logs after upgrade.Since PraisonAI PR #4020, Chroma-backed memory (the default) supports reset. On earlier releases,
Memory().reset_short_term() / .reset_long_term() was a documented, callable, exception-free API that quietly did nothing.Long-term Memory (LTM)
Long-term memory persists across sessions and stores important information.Metadata types (ChromaDB / RAG backend)
ChromaDB only stores primitives — PraisonAI sanitises yourmetadata dict before writing so Chroma writes never fail.
ChromaDB itself rejects non-primitive metadata values; PraisonAI coerces them to strings so writes never fail. If you need to filter or round-trip complex metadata, keep it as JSON in a
str field (e.g. metadata={"tags_json": json.dumps(tags)}) so it survives untouched. The mem0, mongodb, and dakera adapters do not apply this coercion — they accept richer metadata natively.Entity Memory
Entity memory stores information about specific people, places, or things.User Memory
User memory stores personalised information and preferences.Configuration Options
MemoryConfig SDK Reference
Full parameter reference for MemoryConfig
MemoryConfig parameters:
RAG Configuration (Default)
Mem0 Configuration
Requires the optional memory extras:If the package is missing, configuring"provider": "mem0"raises:
Dakera Configuration
Requires the optional Dakera extra:If the package is missing, configuring"provider": "dakera"raises:
Graph Memory Configuration
Requires the optional memory extras:
Unimplemented Backends Raise
Requesting a backend that has no registered adapter raises aValueError — there is no silent fallback to a local file store.
All registered adapters route
store_*, search_*, reset_*, and delete_* through memory_adapter.*. See Custom Memory Adapters.
A registered adapter whose optional dependency is missing logs a
logger.warning and the memory layer degrades gracefully — this is distinct from requesting an unimplemented backend, which raises ValueError.Keep using Redis or Postgres
Keep using Redis or Postgres
Pass a live store via
db(state_url=...) for Redis (or db(database_url=...) for Postgres):Register a custom adapter (escape hatch)
Register a custom adapter (escape hatch)
Register an adapter for the name you want, then
backend="redis" is accepted:Quality Scoring System
Quality Metrics
Completeness
Measures how complete and comprehensive the information is
Relevance
Measures how relevant the information is to the context
Clarity
Measures how clear and understandable the information is
Accuracy
Measures the factual accuracy of the information
Quality Calculation
Advanced Features
Scoped search with user_id and metadata_filter
search_short_term and search_long_term accept user_id and metadata_filter as first-class kwargs to scope results per tenant.
user_id is now enforced twice on every search — once at the Memory layer (existing) and again inside SearchMixin.search_short_term / SearchMixin.search_long_term as of PraisonAI PR #4819. The lower layer auto-derives the same user_id metadata filter, so adapters that accept user_id but ignore it in their own query (Chroma/RAG, SQLite, in-memory) still isolate per-tenant results. If a caller passes both an explicit user_id and a conflicting metadata_filter["user_id"], the explicit user_id always wins — a caller cannot widen scope to another tenant’s data.
user_id takes precedence over any metadata_filter["user_id"], so a route can never widen scope to another tenant. Applied across every backend — Mem0, MongoDB (with and without vector search), ChromaDB, memory-adapter, and the SQLite fallback. When a metadata_filter is present, each backend over-fetches by 10× so results ranked beyond limit still survive the post-filter, then truncates back to limit.Direct
SearchMixin use (subclassing or embedding in a custom store) previously depended on the adapter to filter by user_id. If you have such code, no change is required — the filter is applied automatically now — but you may safely remove any duplicate post-filtering you added as a workaround.Cache-Optimised Context
Memory results are deterministically ordered for prompt caching effectiveness. Usebuild_context_for_task() with explicit output control for manual prompt assembly.
Context Building
Build comprehensive context for tasks:Task Output Finalisation
Store task results with quality assessment:Memory Citations
Automatically cite memory sources:Memory Reranking
Enhance search results with intelligent reranking based on relevance scores:Reranking Features
- Semantic Reranking: Re-scores results based on semantic similarity
- Context-Aware Ranking: Considers current context when ranking
- Quality-Weighted Ranking: Combines relevance with quality scores
Custom Reranking Logic
Implement custom reranking strategies:Reranking Performance
Optimize reranking for large result sets:Performance Optimisation
Complete Example
Best Practices
Set quality thresholds for search
Set quality thresholds for search
Use
min_quality=0.8 for critical information retrieval. Use lower thresholds (0.5–0.7) for exploratory searches where recall is more important.Scope memories per user and agent
Scope memories per user and agent
Always pass
user_id for user-specific memories, agent_id for agent-scoped shared knowledge, and run_id for ephemeral session context.Enable embeddings for semantic search
Enable embeddings for semantic search
Set
use_embedding=True in the memory config for semantic (not just keyword) retrieval. Use text-embedding-3-small for cost efficiency.Use AutoMemory for automatic extraction
Use AutoMemory for automatic extraction
Enable
MemoryConfig(auto_memory=True) to automatically extract preferences, facts, and entities from conversations without manual store_* calls.AutoMemory
AutoMemory automatically extracts structured information from conversations using configurable patterns — no manualstore_* calls needed.
How It Works
AutoMemory wrapsFileMemory with a pattern-based extraction engine. After each agent interaction, it scans the conversation for matching patterns (preferences, facts, dates, etc.) and stores them automatically.
Quick Start
Custom Patterns
MemoryConfig Integration
UseMemoryConfig.auto_memory to enable AutoMemory as part of the consolidated memory parameter:
Related
Knowledge
Integrate with document knowledge bases
Prompt Caching
Optimise memory context for prompt caching
Vector Store
Store and query embeddings with a pluggable, namespace-aware backend

