CrewAI memory that survives the crew run

What memory does CrewAI provide?

CrewAI’s memory documentation describes a unified memory system with hierarchical scopes, recall, extraction, consolidation, configurable storage, and non-blocking saves. A crew can enable memory, and agents can use shared crew memory or a scoped view for private context.

That is useful infrastructure for the lifecycle of a crew. The product decision still remains: which facts belong to a customer, which belong to one run, which agents may read them, how long they stay, and how they leave through export or deletion.

When should you use CrewAI memory instead of an external memory API?

Use CrewAI memory when the crew runtime is the main boundary and its storage, scope, and recall behavior already match the product. Add an external layer when identity and lifecycle span several frameworks, when one customer uses multiple crews, or when a platform team needs one memory contract across many agents.

How do you retrieve persistent memory before a CrewAI run?

Resolve the customer and tenant before constructing the crew, retrieve a small context block, and inject it as trusted read-only input. Keep the same identifiers on the post-run write so context does not drift between the read and the save.

from aimemory import Memory

store = Memory(api_key=os.environ["AI_MEMORY_KEY"])

context = store.search(
    query="What should the crew know before this account review?",
    user_id=customer_id,
    agent_id="account-review-crew",
    metadata={"tenant": tenant_id},
    limit=6,
)

crew = AccountReviewCrew(
    inputs={
        "account_id": account_id,
        "durable_context": str(context),
    }
).crew()
result = crew.kickoff()

store.add(
    messages=[
        {"role": "user", "content": review_request},
        {"role": "assistant", "content": str(result)},
    ],
    user_id=customer_id,
    agent_id="account-review-crew",
    metadata={"tenant": tenant_id, "workflow": "account-review"},
)

How should CrewAI memory scopes map to users and agents?

Use the security boundary to choose the outermost scope, then use shorter scopes for execution detail. A tenant should never be an optional metadata filter that the model can omit. A crew or agent scope should not become a shortcut around user authorization.

What should a CrewAI workflow remember after it finishes?

Store the durable outcome, not the internal theatre of the crew. The final answer may contain a decision, a changed constraint, and the evidence behind it. Tool traces and intermediate drafts usually belong in observability storage, not long-term memory.

• Confirmed decisions and the date they became effective.
• Constraints that should affect a future run.
• Stable customer preferences with their source.
• Corrections that supersede an older memory.
• An episode summary only when the sequence of events matters later.

How do you keep one CrewAI agent’s private memory private?

Give each specialist an explicit agent identity and query agent-private memory only when the task belongs to that specialist. Shared facts should be promoted deliberately to a crew, project, or user scope. A manager agent should not inherit every private memory merely because it can delegate work.

When a delegated task needs context from a private scope, pass a bounded summary through the workflow rather than broadening the original memory. This preserves both utility and least privilege.

How should a CrewAI system correct, export, and delete memory?

Correction, export, and deletion must be product operations, not hidden maintenance scripts. A new run can supersede a fact, but an authorized user should also be able to inspect and correct it. Tenant offboarding should remove events, extracted memories, summaries, graph edges, and exported copies still under application control.

Test deletion after restoring a backup and after changing the crew’s extraction prompt. The same request must stay deleted when the workflow is replayed.

What is the recommended CrewAI persistent memory pattern?

Use the crew for orchestration. Resolve identity before it starts. Retrieve only the durable context the task needs. Keep specialist working memory inside the run. Write the confirmed outcome after completion. Keep correction, export, and deletion outside the prompt and inside the application’s control plane.