Why Memory?
By default, every kickoff starts fresh — agents forget everything between runs. Memory persists facts across runs, so the same crew gets smarter over time without you re-feeding context.
The Three Kinds of Memory
Short-term (this run)
Recent task outputs and reasoning, available within a single kickoff. RAM-based, dies when the run ends.
Long-term (across runs)
Persisted to disk (SQLite by default). Stored as embeddings — agents can semantically recall facts from previous runs.
Entity memory
Tracks specific entities (people, products, projects) and their attributes across runs. Useful for CRMs, support bots.
Enabling Memory
Turn it on at the crew level — CrewAI handles all three kinds for you.
Memory-enabled crew
from crewai import Crew, Process
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, write_task],
process=Process.sequential,
memory=True, # enable short + long + entity
verbose=True,
)
# First run: learns about Acme Corp
crew.kickoff(inputs={"company": "Acme Corp"})
# Second run, days later: still remembers Acme facts
crew.kickoff(inputs={"company": "Acme Corp", "question": "What did we learn last time?"})Custom Embedder & Storage
The default uses OpenAI embeddings + a local SQLite store. For production, point at your own infra.
Custom embedder
crew = Crew(
agents=[...],
tasks=[...],
memory=True,
embedder={
"provider": "openai",
"config": {"model": "text-embedding-3-small"},
},
)Passing Context Manually
Sometimes you don't want auto-memory — you want to inject specific context per run. Use the inputs dict.
Per-run context injection
customer_history = load_customer_history(customer_id)
result = crew.kickoff(inputs={
"customer_id": customer_id,
"history": customer_history, # appears anywhere {history} is referenced
"current_ticket": ticket_body,
})Caveats
- Memory costs tokens. Recalled facts are stuffed into the prompt — watch your context usage.
- Memory can mislead. Stale facts get recalled too. Add timestamps if that matters.
- Test with memory off first. If your crew works deterministically, memory is just a bonus, not a fix.
Notes
Shared memory is shared failure modes
When every agent reads the same buffer, one bad summary poisons downstream reasoning. Add refresh steps, confidence cues, or scoped memories per role for sensitive workflows.
Long-term recall needs retention policy
Embeddings and entity stores grow without pruning. Plan TTLs, user-driven deletes, and legal holds before you persist customer content from agent transcripts.
Serialization surprises show up under load
Pickling rich Python objects into memory backends can break across versions. Prefer JSON-friendly state or versioned blobs so rolling deploys do not corrupt recall.
Entity memory can overfit to noise
Aggressive entity extraction captures typos and hallucinated names. Validate entities with deterministic checks or periodic human audits when accuracy matters.
CrewAI memory FAQ
What types of memory does CrewAI support?
CrewAI offers short-term conversational buffers, longer persistent recall, and entity-focused memory depending on configuration and version features you enable.
When should I enable long-term memory?
Enable it when users expect continuity across sessions—support copilots, research notebooks, or CRM assistants— and pair it with privacy review.
How does entity memory help CrewAI crews?
Entity memory tracks facts about people, accounts, or projects so agents stop re-asking for stable identifiers and can personalize safely.
What are memory pitfalls in production?
Unbounded growth, stale facts, and leaking private data between tenants. Add retention policies, scrubbing jobs, and per-tenant storage isolation.
How is memory different from CrewAI knowledge?
Knowledge usually refers to retrieved documents or corpora, while memory stores conversational or entity state produced during runs.
See also: DevShelfHub's CrewAI tool review for a product-level comparison, pricing notes, and links back into this tutorial series.