---
title: "Memory for CrewAI"
description: "CrewAI's unified Memory class stores scoped, ranked records in LanceDB. Its documented limits, and a custom tool that adds temporal memory with dated evidence."
canonical: https://past.dev/integrations/crewai
last-updated: 2026-09-02
---
# Memory for CrewAI agents

Source: https://past.dev/integrations/crewai

CrewAI provides one unified Memory class that replaced the separate short-term, long-term, entity and external memory types. Records are stored in LanceDB under hierarchical scopes, and recall ranks them by semantic similarity, recency and importance. The documented system tracks no fact validity or supersession, and recall returns no evidence status. This page states what CrewAI memory covers and shows a custom tool that adds temporal, evidence-backed memory over HTTP.

## What CrewAI memory covers

CrewAI documents one unified memory system. The [memory guide](https://docs.crewai.com/en/concepts/memory) describes a single `Memory` class that replaced the separate short-term, long-term, entity and external memory types of earlier releases. A crew enables it with `memory=True`, or with a configured `Memory` instance for custom behavior. Records are stored in LanceDB under `./.crewai/memory` by default; a custom backend can implement the storage protocol.

Records are organized into hierarchical scopes shaped like filesystem paths, such as `/project/alpha` or `/agent/researcher`, and the system can infer a scope from content. `memory.recall()` returns ranked matches scored by a blend of semantic similarity, recency decay and importance, at a shallow depth (vector search only) or a deep one (multi-step, LLM-assisted, the default). A `MemorySlice` exposes a view across several scopes, optionally read-only.

- **Storage is local by default.** The default backend writes LanceDB files inside the project directory. A crew and your product, or two deployed services, share memory only through a backend you build and operate.
- **Recency is a ranking weight rather than a time model.** A newer record outranks an older one at recall. Neither record carries a validity window or a supersession link, so the store cannot state which value is current, what replaced it, or what was true on a date.
- **Recall has no evidence status.** Matches come back ranked by score. A thin result does not distinguish missing knowledge from a retrieval miss, and sources that disagree are not surfaced as a conflict.

Scope paths organize one deployment's records; the documented examples are project and agent scopes. Per-user isolation is a convention the application builds from scope paths and read-only slices.

## The integration: a custom tool per endpoint

CrewAI tools are Python classes or decorated functions. The [custom tools guide](https://docs.crewai.com/en/learn/create-custom-tools) documents both forms: subclass `BaseTool` with a `name`, `description`, `args_schema` and `_run` method, or wrap a function with the `@tool` decorator. Two small tools connect any agent to past.dev; the [API reference](/docs/memory-api/api-reference) documents all four endpoints.

```python
import os, requests
from crewai.tools import tool

BASE = "https://api.past.dev/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['PAST_API_KEY']}"}

@tool("Remember")
def remember(text: str, happened_at: str) -> str:
    """Store a durable fact with the time it actually happened (ISO 8601)."""
    r = requests.post(f"{BASE}/ingest", headers=HEADERS,
                      json={"content": text, "timestamp": happened_at}).json()
    return r.get("sourceId", "stored")

@tool("Recall")
def recall(question: str) -> str:
    """Return ranked, dated evidence and a status value for a question."""
    r = requests.post(f"{BASE}/recall", headers=HEADERS,
                      json={"query": question}).json()
    return str(r)
```

Attach both tools to the agents that work with history (`tools=[remember, recall]` on the `Agent`). Keep `memory=True` for the crew's own working context. Route durable facts through `remember` with the time they happened, and instruct agents to call `recall` before answering questions about people, decisions or commitments.

## Routing on recall status

Applications can route on `status`. `Supported` means the evidence establishes the answer. `Conflicted` returns evidence from credible sources that disagree. `NoKnownSupport` means the stored evidence does not establish an answer. `UnknownBecauseDegraded` means retrieval could not complete and should be treated as an unknown result.

A crew can act on the value instead of guessing. `Supported` evidence becomes an answer with its date and source. `Conflicted` evidence can be escalated to a person with both sides attached. `NoKnownSupport` becomes a stated gap. `UnknownBecauseDegraded` is a signal to retry or to fall back.

## When to use which

| Requirement | CrewAI Memory | past.dev via tool |
| --- | --- | --- |
| Recall inside one project's runs | Yes | Yes |
| Current value of a fact that changed | Newer records rank higher | Supersession with history kept |
| What was true on a date | No documented query | Point-in-time recall |
| Same customer across email, tickets and chat | Scope paths the app chooses | Entity resolution with evidence |
| Signal for insufficient evidence | No | Status value on every recall |
| Memory shared beyond one machine | Custom storage backend | One API for every caller |

The [quickstart](/docs/memory-api/quickstart) reaches a first recall in four calls. The [benchmarks](/benchmarks) document how recall quality is measured. [Facts that change over time](/guides/facts-that-change-over-time) covers the temporal model the table refers to.

## Frequently asked questions

### Does CrewAI have long term memory?

Yes. Current CrewAI documentation describes one unified Memory class that persists records in LanceDB and ranks them at recall by similarity, recency and importance. It replaced the earlier separate short-term, long-term, entity and external memory types.

### Do I keep CrewAI memory when adding a memory API?

Yes. Crew memory serves working context inside the project that runs the crew. Use the API for facts that need dates, sources and supersession, and for memory shared across products, machines and teams.

### Can two crews share what they learned?

CrewAI stores memory locally in the project directory by default, so each deployment keeps its own records unless you operate a shared backend. Behind the past.dev API, every crew and product holding a key for the same project queries one memory.

## Related

- [Memory for LlamaIndex](https://past.dev/integrations/llamaindex)
- [Memory for LangChain](https://past.dev/integrations/langchain)
- [Memory for the OpenAI Agents SDK](https://past.dev/integrations/openai-agents-sdk)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)