Course Content

How does CrewAI handle shared knowledge between agents?

Only task context is exact; memory and knowledge are retrieved by relevance, so a fact you need every time belongs in context.

What you need to know

The three mechanisms

	Task `context`	Memory	Knowledge
What it holds	earlier task outputs	facts learned during runs	documents you provide
Who writes it	the crew, automatically	the crew after tasks, or your code	you, before the run
How it is read	inserted in full	recalled by relevance	searched by relevance
Across runs	no	yes	yes (static)
Deterministic	yes	no	mostly

Memory in current CrewAI

Older versions had separate short-term, long-term and entity memory classes. Current CrewAI has one Memory class:

On save, an LLM analyses the content and infers a scope (like a folder path, for example /customers/acme), categories and an importance score.
On recall, results are ranked by a mix of semantic similarity, recency and importance.
Default storage is LanceDB on local disk; the default embedder is OpenAI's.

Python

1from crewai import Crew2from crewai.memory import Memory34memory = Memory(5    semantic_weight=0.5,6    recency_weight=0.3,7    importance_weight=0.2,8    recency_half_life_days=14,   # a 14-day-old memory scores half for recency9)10crew = Crew(agents=[...], tasks=[...], memory=memory)1112# Your own code can use the same store directly13memory.remember("Acme Logistics signed with a competitor in March 2026.",14                scope="/accounts/acme")15hits = memory.recall("What do we know about Acme's current vendor?", limit=5)

memory=True uses the defaults. Agents share the crew's memory unless given their own, for example Agent(memory=memory.scope("/agent/writer")) for a private area.

Knowledge

knowledge_sources=[...] on the crew (shared) or on an agent (private) loads documents into a vector store. Before each task, CrewAI rewrites the task into a search query and adds the best-matching chunks to the prompt. Details are in the next lesson.

Costs and risks of memory

Saving runs an LLM analysis and an embedding; recall runs embeddings and, for deep recall, extra LLM calls.
Old memories can surface as if current — for example, last quarter's price.
Runs become harder to reproduce, because what is recalled changes as memory grows.

A real-life example

A B2B SaaS company runs its lead-qualification crew on the same accounts many times a year. Without memory, every run re-researched from scratch, and reps complained that the email writer did not know "we already spoke to them in January".

They enabled a Memory with recency_half_life_days=30 and a scope per account (/accounts/<domain>). After each run, the crew's outcome is remembered; the Flow also calls memory.remember(...) when a rep logs a call outcome. On the next run, the researcher recalls "Demo in Jan 2026; blocker: needs SSO" and the email opens with the SSO update instead of a cold pitch.

They kept context for passing data between tasks within a run, and turned memory off entirely for the loan-document crew elsewhere in the company, where every application must be judged only on its own documents.

Follow-up questions to expect

"Is memory shared between agents?" — Yes by default; all agents use the crew's memory. Give an agent a scoped view if it needs a private area.
"How do you stop stale memories?" — Lower recency_half_life_days, store dates in the content, use scopes per entity, and forget or reset scopes when facts change.
"When would you turn memory off?" — For stateless, auditable decisions such as credit or compliance checks, where each case must be judged only on its own inputs.