---
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-10-17
---
# 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. This page states what CrewAI memory covers and shows a custom tool that adds temporal memory over HTTP, with recall that returns ranked documents with dates and verbatim source excerpts.

## 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 returns scored records.** Matches come back ranked by score, each with the stored record. Whether they support an answer is for the application to decide.

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 public operations.

```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']}"}

def make_past_tools(user_id: str):
    """Build the memory tools for one signed-in user. The model never sees user_id."""

    @tool("Remember")
    def remember(text: str, happened_at: str) -> str:
        """Store timestamped source text, readable by the whole project, authored by the current user."""
        r = requests.post(f"{BASE}/ingest", headers=HEADERS,
                          json={"content": text, "timestamp": happened_at,
                                "identity": user_id}).json()
        return r.get("sourceId", "stored")

    @tool("Recall")
    def recall(question: str) -> str:
        """Return ranked documents with source excerpts for the current user."""
        r = requests.post(f"{BASE}/recall", headers=HEADERS,
                          json={"query": question, "identity": user_id}).json()
        return str(r)

    return [remember, recall]
```

`make_past_tools` builds the two tools for one request. They close over the signed-in user's id, so the model never sees it. Attach them to the agents that work with history (`tools=make_past_tools(user_id)` on the `Agent`) when you build the crew for that user. 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.

> **Identity**
>
> The application sets the identity. The model never chooses it. Recall returns what the identity in the request may read, so take the identity from the signed-in user in code, and keep it out of every value that the model fills.

## Or connect the MCP server

A CrewAI agent takes MCP servers in its `mcps` field. `MCPServerHTTP` from `crewai.mcp` connects to a remote server, with `streamable=True` for Streamable HTTP ([MCP overview](https://docs.crewai.com/en/mcp/overview)). The project's end-user MCP server then gives the agent `recall`, `answer` and `who_am_i`, plus `remember` while the project's write toggle is on, with no tool code to write.

1. Turn on the project's end-user MCP server on **Build › MCP server** in the console.
2. Mint an access link there, or with the account server's `create_mcp_access_link` tool. The link has the form `https://api.past.dev/mcp/<handle>/link/<secret>`. It is one URL that is one identity, and the server answers it with no sign-in step.
3. Keep the link in a secret store, such as the `PAST_MCP_URL` environment variable that the code below reads. The secret in its path is the credential.

```python
import os
from crewai import Agent
from crewai.mcp import MCPServerHTTP

analyst = Agent(
    role="Account analyst",
    goal="Answer questions about customers from their dated history",
    backstory="You call recall before you answer questions about people, decisions or commitments.",
    mcps=[MCPServerHTTP(url=os.environ["PAST_MCP_URL"], streamable=True)],
)
```

Every call through the link runs as its identity, with that identity's audiences. Mint one link per install, so that a revoked link stops one agent only. When the agent serves several people, mint one link per end user, and connect each request with the link of the user who makes it. Never share one link between users. `remember` writes to the identity's own private audience, and only that identity recalls it. Send data that the whole project must recall through the ingest call. The [end-user server documentation](/docs/mcp/serving-your-own-users) describes the tools, the links and revocation.

## Routing on recall results

Recall returns ranked documents with dates and source excerpts. The application decides whether those documents support an answer, contain a disagreement, or are insufficient; HTTP failures are handled separately.

A crew can act on the returned documents instead of guessing. It can answer with dates and source excerpts, escalate documents that disagree, state a gap when support is insufficient, and retry or fall back when recall fails.

## 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 |
| Recall result | Task context | Grouped documents with dated source excerpts |
| Memory shared beyond one machine | Custom storage backend | One API for every caller |

The [quickstart](/docs/memory-api/quickstart) shows how to ingest, wait until ingestion completes, and recall. The [benchmarks](/benchmarks) document how recall quality is measured. [Facts that change over time](/guides/facts-that-change-over-time) covers general temporal designs.

## 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)
- [Memory for AutoGen](https://past.dev/integrations/autogen)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Quickstart](https://past.dev/docs/memory-api/quickstart)