Skip to main content
All comparisons
Use-case roundup

Best AI Memory for CrewAI (2026)

CrewAI ships with short-term, long-term, and entity memory backed by ChromaDB. It's enough to demo, not enough to ship. Six ways to add real cross-crew, cross-user, conflict-resolving memory to a CrewAI build — evaluated honestly.

What CrewAI already ships

CrewAI's built-in memory system has three pieces. Knowing what each does — and where each stops — is the start of picking the right augmentation.

  • Short-term memory— RAG over the current crew run's context. Resets when the crew finishes. Useful for keeping tasks coherent inside a single run.
  • Long-term memory— SQLite-backed task outcomes from past crew runs. Helps agents recall "what worked last time" for similar tasks.
  • Entity memory — basic entity tracking backed by ChromaDB. Catches names, places, concepts the crew encountered.

What it does not ship: cross-crew shared memory, multi-tenant scoping, conflict resolution when two runs assert contradicting facts, a browsable view of what the crew has learned, or any way to keep the same memory in sync with a Claude Desktop or Cursor session. Those gaps are why people end up here.

The quick answer

If you want hosted memory that drops into CrewAI as a Tool: Ricord. If you're comfortable wrapping an OSS API into a Tool and tuning extraction yourself: Mem0 OSS. If CrewAI's built-in is already enough and you just need durable storage: Built-in + a hosted Chroma. The full matrix is below.

The decision matrix

Ten criteria, six options. CrewAI's built-in is evaluated as a real option because for plenty of crews it's sufficient.

CriterionRicordBuilt-inMem0LettaCogneeDIY
Works as a CrewAI ToolBuilt-in primitiveWrap RESTWrap RESTDIY
Persists across crew runsDIY
Per-user / per-tenant scopingDIY collectionDIYDIY
Shared memory across multiple crewsManual syncDIY
Semantic recall (vector or graph)Vector (Chroma)
Entity extraction + conflict resolutionBasic entity, no conflictsManual
Browsable wiki of what the crew learned
Hard delete (GDPR)Delete collectionDIYDIY
Cross-client (same memory from Claude Desktop / Cursor)API only
Cost (smallest tier with the listed features)$15/mo annual$0 + Chroma host$249/mo for graphSelf-host + LLM$0 OSS / self-hostTime

Slot-by-slot — which fits your CrewAI build

If your crew is a demo or a single-tenant internal tool

Built-in memory is enough. Turn it on with Crew(memory=True)and CrewAI handles the short/long/entity split. If you need durable storage past local files, point the ChromaDB backend at a hosted instance. You'll feel the limits the day you need multi-tenant or cross-crew memory — until then, it's not the bottleneck.

If you need cross-crew or multi-tenant memory

Ricordas a CrewAI Tool. Two of your crews can write into the same memory, and read each other's facts back later. Pass a user_id on each call and the memory is scoped per tenant without any namespace logic in your Tool code. Drop-in pattern below.

If you want OSS and you have engineering capacity

Mem0 OSS(Apache 2.0) wraps cleanly as a CrewAI Tool. Python-first, modifiable extraction prompts, well-documented. You'll spend time on the production-grade pieces (contradiction handling, multi-tenant, hard delete) but you'll own them. When OSS wins →

If your product is an agent runtime

Lettabundles runtime + memory. Most CrewAI builders won't switch off CrewAI to get this — but if your real bet is shipping a custom agent runtime, Letta collapses two decisions into one.

If extraction depth is the goal and AGPL is OK

Cogneegives you a configurable extraction pipeline that hosted layers hide. Worth a look if your crew's value is in how it structures what it learns. Read the AGPL implications before shipping commercially. Cognee details →

Ricord as a CrewAI Tool — the drop-in

CrewAI lets agents call Tools mid-task. A memory Tool is two methods: recall and save. Wire Ricord's API to each, scope by user_id, and the rest of your crew code stays untouched.

from crewai.tools import BaseTool
from pydantic import BaseModel
import requests, os

RICORD = "https://api.ricord.ai/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['RICORD_API_KEY']}"}

class RecallInput(BaseModel):
    user_id: str
    query: str

class RicordRecall(BaseTool):
    name: str = "ricord_recall"
    description: str = "Recall what we know about this user/topic"
    args_schema: type[BaseModel] = RecallInput

    def _run(self, user_id: str, query: str) -> str:
        r = requests.get(f"{RICORD}/memories/recall",
                         headers=HEADERS,
                         params={"user_id": user_id, "query": query, "k": 5})
        hits = r.json().get("hits", [])
        return "\n".join(h["content"] for h in hits) or "No memory found."

class SaveInput(BaseModel):
    user_id: str
    content: str

class RicordSave(BaseTool):
    name: str = "ricord_save"
    description: str = "Save a fact for future recall"
    args_schema: type[BaseModel] = SaveInput

    def _run(self, user_id: str, content: str) -> str:
        requests.post(f"{RICORD}/memories",
                      headers=HEADERS,
                      json={"user_id": user_id, "content": content})
        return "Saved."

# Wire into your Agent
from crewai import Agent
researcher = Agent(
    role="Researcher",
    goal="Learn about the user across sessions",
    tools=[RicordRecall(), RicordSave()],
    memory=False,  # Ricord replaces the built-in here
)

Why Ricord wins for production CrewAI builds

  1. Cross-crew memory by default.Two crews with different roles can write into and read from the same memory. CrewAI's built-in scopes to a single crew; sharing across crews is a manual sync job.
  2. Per-tenant scoping is a parameter. Pass user_id at Tool-call time. No collection juggling, no namespace prefix discipline across crews.
  3. Conflict resolution at ingest.If a new crew run says "Acme uses Postgres" and an old run said "Acme uses MySQL", Ricord resolves at save time so recalls return the current truth. CrewAI's entity memory doesn't resolve contradictions.
  4. Browsable wiki. Your team can see what the crew has learned at ricord.ai/dashboard — a real organized view, not a vector dump.
  5. Cross-client. The same memory the crew writes is reachable from Claude Desktop, Cursor, Codex via MCP. Useful when the same humans who run the crew also debug it from an IDE.

When to keep CrewAI's built-in

Don't replace it just because. The built-in is the right call when:

  • The crew is single-tenant and single-purpose
  • You don't need memory to outlive the project (long-term memory in SQLite is enough)
  • You don't need a UI for the team to inspect what the crew has learned
  • You're still in "does this crew shape work at all" mode — adding a memory layer is premature

The day any of those flips, swap the Tool. CrewAI's Tool boundary is the right seam.

Getting started

pip install crewai requests
# Get an API key at https://ricord.ai/login?signup=true
export RICORD_API_KEY=rc_live_...
# Drop the RicordRecall + RicordSave Tools into your Agents
# Turn off Crew(memory=True) — Ricord owns the memory now