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.
| Criterion | Ricord | Built-in | Mem0 | Letta | Cognee | DIY |
|---|---|---|---|---|---|---|
| Works as a CrewAI Tool | Built-in primitive | Wrap REST | Wrap REST | DIY | ||
| Persists across crew runs | DIY | |||||
| Per-user / per-tenant scoping | DIY collection | DIY | DIY | |||
| Shared memory across multiple crews | Manual sync | DIY | ||||
| Semantic recall (vector or graph) | Vector (Chroma) | |||||
| Entity extraction + conflict resolution | Basic entity, no conflicts | Manual | ||||
| Browsable wiki of what the crew learned | ||||||
| Hard delete (GDPR) | Delete collection | DIY | DIY | |||
| 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 graph | Self-host + LLM | $0 OSS / self-host | Time |
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
- 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.
- Per-tenant scoping is a parameter. Pass
user_idat Tool-call time. No collection juggling, no namespace prefix discipline across crews. - 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.
- Browsable wiki. Your team can see what the crew has learned at
ricord.ai/dashboard— a real organized view, not a vector dump. - 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