Skip to main content
Multi-tiered memory with short-term, long-term, entity, and user-specific storage — enhanced by quality scoring and automatic extraction.
The user chats across turns; multi-tier memory stores and scores context for later retrieval.

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.
On the default rag provider, resetting short-term also clears long-term — Chroma stores both tiers in one collection. Use DakeraMemoryAdapter if you need tier isolation.
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.

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
MemoryBackend options:
redis, valkey, and postgres are not memory backends — passing them raises ValueError. See Unimplemented Backends Raise below. For Redis/Postgres state persistence use db(state_url=...) / db(database_url=...).
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:
See Dakera Memory for the full guide including self-hosted deployment, tier mapping, and delete/reset operations.

Graph Memory Configuration

Requires the optional memory extras:

Unimplemented Backends Raise

Requesting a backend that has no registered adapter raises a ValueError — there is no silent fallback to a local file store.
redis, valkey, and postgres are not memory adapters. Earlier releases accepted them but silently stored to a local file, so data never reached Redis/Postgres. Requesting one now raises:
Use Redis persistence (db(state_url=...)) instead.
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.
Pass a live store via db(state_url=...) for Redis (or db(database_url=...) for Postgres):
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 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.
Before PR #3855, user_id and metadata_filter were silently absorbed into **kwargs and never applied — per-user scoping was broken on the class-body path. Pass them explicitly, not inside a memory={...} dict.

Cache-Optimised Context

Memory results are deterministically ordered for prompt caching effectiveness. Use build_context_for_task() with explicit output control for manual prompt assembly.
See Prompt Caching for the full guide.

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

  1. Semantic Reranking: Re-scores results based on semantic similarity
  2. Context-Aware Ranking: Considers current context when ranking
  3. 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

Use min_quality=0.8 for critical information retrieval. Use lower thresholds (0.5–0.7) for exploratory searches where recall is more important.
Always pass user_id for user-specific memories, agent_id for agent-scoped shared knowledge, and run_id for ephemeral session context.
Set use_embedding=True in the memory config for semantic (not just keyword) retrieval. Use text-embedding-3-small for cost efficiency.
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 manual store_* calls needed.

How It Works

AutoMemory wraps FileMemory 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

Use MemoryConfig.auto_memory to enable AutoMemory as part of the consolidated memory parameter:

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