Skip to main content

Overview

CrewAI provides a unified memory system — a single Memory class that replaces separate short-term, long-term, entity, and external memory types with one intelligent API. Memory uses an LLM to analyze content when saving (inferring scope, categories, and importance) and supports adaptive-depth recall with composite scoring that blends semantic similarity, recency, and importance. You can use memory four ways: standalone (scripts, notebooks), with Crews, with Agents, or inside Flows.

Quick Start

Four Ways to Use Memory

Standalone

Use memory in scripts, notebooks, CLI tools, or as a standalone knowledge base — no agents or crews required.

With Crews

Pass memory=True for default settings, or pass a configured Memory instance for custom behavior.
When memory=True, the crew creates a default Memory() and passes the crew’s embedder configuration through automatically. All agents in the crew share the crew’s memory unless an agent has its own. Without a custom embedder, memory uses OpenAI text-embedding-3-large embeddings. After each task, the crew automatically extracts discrete facts from the task output and stores them. Before each task, the agent recalls relevant context from memory and injects it into the task prompt.

With Agents

Agents can use the crew’s shared memory (default) or receive a scoped view for private context.
This pattern gives the researcher private findings while the writer reads from the shared crew memory.

With Flows

Every Flow has built-in memory. Use self.remember(), self.recall(), and self.extract_memories() inside any flow method.
See the Flows documentation for more on memory in Flows.

Hierarchical Scopes

What Scopes Are

Memories are organized into a hierarchical tree of scopes, similar to a filesystem. Each scope is a path like /, /project/alpha, or /agent/researcher/findings.
Scopes provide context-dependent memory — when you recall within a scope, you only search that branch of the tree, which improves both precision and performance.

How Scope Inference Works

When you call remember() without specifying a scope, the LLM analyzes the content and the existing scope tree, then suggests the best placement. If no existing scope fits, it creates a new one. Over time, the scope tree grows organically from the content itself — you don’t need to design a schema upfront.

Visualizing the Scope Tree

MemoryScope: Subtree Views

A MemoryScope restricts all operations to a branch of the tree. The agent or code using it can only see and write within that subtree.

Best Practices for Scope Design

  • Start flat, let the LLM organize. Don’t over-engineer your scope hierarchy upfront. Begin with memory.remember(content) and let the LLM’s scope inference create structure as content accumulates.
  • Use /{entity_type}/{identifier} patterns. Natural hierarchies emerge from patterns like /project/alpha, /agent/researcher, /company/engineering, /customer/acme-corp.
  • Scope by concern, not by data type. Use /project/alpha/decisions rather than /decisions/project/alpha. This keeps related content together.
  • Keep depth shallow (2-3 levels). Deeply nested scopes become too sparse. /project/alpha/architecture is good; /project/alpha/architecture/decisions/databases/postgresql is too deep.
  • Use explicit scopes when you know, let the LLM infer when you don’t. If you’re storing a known project decision, pass scope="/project/alpha/decisions". If you’re storing freeform agent output, omit the scope and let the LLM figure it out.

Use Case Examples

Multi-project team:
Per-agent private context with shared knowledge:
Customer support (per-customer context):

Memory Slices

What Slices Are

A MemorySlice is a view across multiple, possibly disjoint scopes. Unlike a scope (which restricts to one subtree), a slice lets you recall from several branches simultaneously.

When to Use Slices vs Scopes

  • Scope: Use when an agent or code block should be restricted to a single subtree. Example: an agent that only sees /agent/researcher.
  • Slice: Use when you need to combine context from multiple branches. Example: an agent that reads from its own scope plus shared company knowledge.

Read-Only Slices

The most common pattern: give an agent read access to multiple branches without letting it write to shared areas.

Read-Write Slices

When read-only is disabled, you can write to any of the included scopes, but you must specify which scope explicitly.

Composite Scoring

Recall results are ranked by a weighted combination of three signals:
Where:
  • similarity = 1 / (1 + distance) from the vector index (0 to 1)
  • decay = 0.5^(age_days / half_life_days) — exponential decay (1.0 for today, 0.5 at half-life)
  • importance = the record’s importance score (0 to 1), set at encoding time
Configure these directly on the Memory constructor:
Each MemoryMatch includes a match_reasons list so you can see why a result ranked where it did (e.g. ["semantic", "recency", "importance"]).

LLM Analysis Layer

Memory uses the LLM in three ways:
  1. On save — When you omit scope, categories, or importance, the LLM analyzes the content and suggests scope, categories, importance, and metadata (entities, dates, topics).
  2. On recall — For deep/auto recall, the LLM analyzes the query (keywords, time hints, suggested scopes, complexity) to guide retrieval.
  3. Extract memoriesextract_memories(content) breaks raw text (e.g. task output) into discrete memory statements. Agents use this before calling remember() on each statement so that atomic facts are stored instead of one large blob.
All analysis degrades gracefully on LLM failure — see Failure Behavior.

Memory Consolidation

When saving new content, the encoding pipeline automatically checks for similar existing records in storage. If the similarity is above consolidation_threshold (default 0.85), the LLM decides what to do:
  • keep — The existing record is still accurate and not redundant.
  • update — The existing record should be updated with new information (LLM provides the merged content).
  • delete — The existing record is outdated, superseded, or contradicted.
  • insert_new — Whether the new content should also be inserted as a separate record.
This prevents duplicates from accumulating. For example, if you save “CrewAI ensures reliable operation” three times, consolidation recognizes the duplicates and keeps only one record.

Intra-batch Dedup

When using remember_many(), items within the same batch are compared against each other before hitting storage. If two items have cosine similarity >= batch_dedup_threshold (default 0.98), the later one is silently dropped. This catches exact or near-exact duplicates within a single batch without any LLM calls (pure vector math).

Non-blocking Saves

remember_many() is non-blocking — it submits the encoding pipeline to a background thread and returns immediately. This means the agent can continue to the next task while memories are being saved.

Read Barrier

Every recall() call automatically calls drain_writes() before searching, ensuring the query always sees the latest persisted records. This is transparent — you never need to think about it.

Crew Shutdown

When a crew finishes, kickoff() drains all pending memory saves in its finally block, so no saves are lost even if the crew completes while background saves are in flight.

Standalone Usage

For scripts or notebooks where there’s no crew lifecycle, call drain_writes() or close() explicitly:

Source and Privacy

Every memory record can carry a source tag for provenance tracking and a private flag for access control.

Source Tracking

The source parameter identifies where a memory came from:

Private Memories

Private memories are only visible to recall when the source matches:
This is particularly useful in multi-user or enterprise deployments where different users’ memories should be isolated.

RecallFlow (Deep Recall)

recall() supports two depths:
  • depth="shallow" — Direct vector search with composite scoring. Fast (~200ms), no LLM calls.
  • depth="deep" (default) — Runs a multi-step RecallFlow: query analysis, scope selection, parallel vector search, confidence-based routing, and optional recursive exploration when confidence is low.
Smart LLM skip: Queries shorter than query_analysis_threshold (default 200 characters) skip the LLM query analysis entirely, even in deep mode. Short queries like “What database do we use?” are already good search phrases — the LLM analysis adds little value. This saves ~1-3s per recall for typical short queries. Only longer queries (e.g. full task descriptions) go through LLM distillation into targeted sub-queries.
The confidence thresholds that control the RecallFlow router are configurable:

Embedder Configuration

Memory needs an embedding model to convert text into vectors for semantic search. By default, Memory() uses OpenAI text-embedding-3-large embeddings, which produce 3072-dimensional vectors. Set OPENAI_API_KEY for the default path, or configure a custom embedder in one of three ways.
Existing local memory stores created with 1536-dimensional embeddings, such as text-embedding-3-small or text-embedding-ada-002, may not be compatible with the text-embedding-3-large default. This applies to both the OpenAI and Azure OpenAI providers — Azure’s default embedding model also changed from text-embedding-ada-002 to text-embedding-3-large. If local testing fails with an embedding dimension mismatch, reset memory with crewai reset-memories -m, delete the local memory storage directory, or explicitly configure the older embedder model until you migrate.

Passing to Memory Directly

Via Crew Embedder Config

When using memory=True, the crew’s embedder config is passed through:

Provider Examples

Provider Reference

LLM Configuration

Memory uses an LLM for save analysis (scope, categories, importance inference), consolidation decisions, and deep recall query analysis. You can configure which model to use.
The LLM is initialized lazily — it’s only created when first needed. This means Memory() never fails at construction time, even if API keys aren’t set. Errors only surface when the LLM is actually called (e.g. when saving without explicit scope/categories, or during deep recall). For fully offline/private operation, use a local model for both the LLM and embedder:

Storage Backend

  • Default: LanceDB, stored under ./.crewai/memory (or $CREWAI_STORAGE_DIR/memory if the env var is set, or the path you pass as storage="path/to/dir").
  • Custom backend: Implement the StorageBackend protocol (see crewai.memory.storage.backend) and pass an instance to Memory(storage=your_backend).

Discovery

Inspect the scope hierarchy, categories, and records:

Failure Behavior

If the LLM fails during analysis (network error, rate limit, invalid response), memory degrades gracefully:
  • Save analysis — A warning is logged and the memory is still stored with default scope /, empty categories, and importance 0.5.
  • Extract memories — The full content is stored as a single memory so nothing is dropped.
  • Query analysis — Recall falls back to simple scope selection and vector search so you still get results.
No exception is raised for these analysis failures; only storage or embedder failures will raise.

Privacy Note

Memory content is sent to the configured LLM for analysis (scope/categories/importance on save, query analysis and optional deep recall). For sensitive data, use a local LLM (e.g. Ollama) or ensure your provider meets your compliance requirements.

Memory Events

All memory operations emit events with source_type="unified_memory". You can listen for timing, errors, and content. Example: monitor query time:

Troubleshooting

Memory not persisting?
  • Ensure the storage path is writable (default ./.crewai/memory). Pass storage="./your_path" to use a different directory, or set the CREWAI_STORAGE_DIR environment variable.
  • When using a crew, confirm memory=True or memory=Memory(...) is set.
Slow recall?
  • Use depth="shallow" for routine agent context. Reserve depth="deep" for complex queries.
  • Increase query_analysis_threshold to skip LLM analysis for more queries.
LLM analysis errors in logs?
  • Memory still saves/recalls with safe defaults. Check API keys, rate limits, and model availability if you want full LLM analysis.
Background save errors in logs?
  • Memory saves run in a background thread. Errors are emitted as MemorySaveFailedEvent but don’t crash the agent. Check logs for the root cause (usually LLM or embedder connection issues).
Embedding dimension mismatch?
  • Existing local memory stores may have been created with a different embedding model. The default OpenAI memory embedder is now text-embedding-3-large (3072 dimensions), while older stores commonly used 1536-dimensional embeddings. For local testing, run crewai reset-memories -m, delete the local memory storage directory, or configure the previous embedder model explicitly.
Concurrent write conflicts?
  • LanceDB operations are serialized with a shared lock and retried automatically on conflict. This handles multiple Memory instances pointing at the same database (e.g. agent memory + crew memory). No action needed.
Browse memory from the terminal:
Reset memory (e.g. for tests):

Configuration Reference

All configuration is passed as keyword arguments to Memory(...). Every parameter has a sensible default.