CrewAI gives crews built-in short-term, long-term, and entity memory. This page explains how each type works, where the design is strong, and where a plain-file state layer fills the gaps.
Set memory=True on a Crew and CrewAI activates three memory stores with sensible defaults. Short-term memory uses ChromaDB to embed text and retrieves relevant chunks through RAG. It resets when the run ends.
Long-term memory persists across runs. It uses SQLite to store task results and learned insights. On the next run, the crew recalls what worked and what did not. Entity memory tracks people, companies, and concepts using the same RAG pipeline as short-term memory.
Contextual memory is not a separate store. It combines short-term, long-term, and entity memory into a single retrieval step and injects the most relevant information into the prompt.
For many single-crew use cases, the default memory system works well out of the box.
Storage locations are opaque. Short-term and entity memory write to ChromaDB in a platform-specific directory. Long-term memory defaults to .crewai/ in your project. Finding these files means knowing the internal layout.
Debugging retrieval is difficult. When an agent produces a bad answer, you cannot easily see what memory contributed to the prompt. Memory is locked inside the crew. Another framework or a second crew cannot read what the first crew learned.
Resets between projects require finding and deleting hidden files. There is no single command to clear all memory for a crew.
The alternative: give the crew a shared folder of plain text files. Agents read and write files in that folder through a custom CrewAI tool. You can open any file and see exactly what the crew knows.
The folder is portable. Copy it to another machine, point a different framework at it, or check it into version control. The knowledge moves with the folder, not with a specific framework.
| CrewAI short-term | CrewAI long-term | gcontext files | |
|---|---|---|---|
| Scope | Single run | Cross-run (same crew) | Cross-tool (any MCP client) |
| Storage | ChromaDB (in-memory + SQLite) | SQLite | Plain files on disk |
| Inspection | Requires code to query | Query SQLite directly | Open in any editor |
| Cross-framework | No | No | Yes, any MCP client |
| Correction | Not possible (resets each run) | Not straightforward | Edit the file |
| Best for | Task context within a run | Crew-scoped recall across runs | Shared, inspectable knowledge |
CrewAI and file-based state are not mutually exclusive. Keep CrewAI memory for in-run context and cross-run learning. Add a file layer for knowledge that needs to be visible, editable, or shared with tools outside the crew.
Create a custom CrewAI tool that reads and writes files in a gcontext state folder. The crew uses the tool like any other. The state folder is also served over MCP, so your coding assistant or a second crew can access the same files.
Long-term memory uses a SQLite database in your project directory (default: .crewai/). Short-term and entity memory use ChromaDB, which also writes to a local SQLite file. The exact paths depend on your OS and the appdirs package. You can override the long-term path with the db_path parameter on LTMSQLiteStorage.
CrewAI memory is scoped to a single crew instance. There is no built-in mechanism to share memory across crews. To share knowledge, store it in external files that both crews can access through a custom tool.
Long-term memory is in a SQLite database and can be queried with standard tools. Short-term and entity memory use ChromaDB embeddings, which require code to search. There is no built-in viewer. File-based state is readable in any text editor.
Keep CrewAI for orchestration. Add gcontext for memory you can read, edit, and share.