How do you stop CrewAI memory leaking between users in a multi-tenant service?

## Why this is a design question, not a config question CrewAI's memory model was built for a crew that belongs to you: it accumulates what the crew has seen and retrieves it by similarity. There is no tenant dimension in that model. Enabling `memory=True` in a service that handles many customers therefore converts a stateless request handler into a shared, cross-customer knowledge store — and the retrieval path has no filter that would keep customer A's contract terms out of the context assembled for customer B. Every part of the stack behaves exactly as documented; the leak comes from applying a single-owner abstraction to a multi-owner problem. ## The three defensible architectures **1. Isolate by storage location and process.** Set `CREWAI_STORAGE_DIR` to a per-tenant path and run one tenant per process (or one per worker, dispatched by tenant). This maps the isolation boundary onto something the framework actually respects: the store it reads and writes. The constraints are real — long-term memory is SQLite and the vector collections are file-backed, so multiple concurrent writers on one root is a correctness and locking hazard, and per-tenant directories multiply storage and cold-start costs. It suits a small number of high-value tenants far better than a long tail of small ones. **2. Delegate memory to a user-scoped provider.** `memory_config` lets you point memory at an external provider (Mem0, for example) carrying a `user_id`. Scoping then lives in a system whose data model has users in it, and your crew processes can stay stateless and horizontally scalable. You trade a local file for a network dependency in the hot path, another vendor holding customer data, and latency on every read and write. For a service with many users this is usually the honest answer. **3. Run stateless and pass context explicitly.** Leave memory off. Fetch whatever history matters from your own datastore — where it is already governed, access-controlled and auditable — and inject it into the task description or as a per-request string knowledge source. This is the most boring option and frequently the right one: your application already knows who the user is and what they are allowed to see, while CrewAI's memory does not and never will. You give up automatic accumulation and gain reproducibility, testability and a clean deletion story. ## Where knowledge sources fit Knowledge is a different risk profile. A shared corpus — product docs, policies, public reference material — is fine to index once and serve to everyone, because it is authored and identical for all tenants. Tenant-specific documents are not: indexing customer A's uploads into a crew-level knowledge base makes them retrievable by anyone the crew serves. Agent-level `knowledge_sources` scope material to an agent, which is a role boundary, not a customer boundary — do not mistake one for the other. Tenant-specific documents belong in a per-tenant store with a per-tenant lifecycle. ## Obligations you inherit the moment memory is on - **Deletion.** "Delete my data" now has to reach embeddings derived from that data. `crew.reset_memories(...)` and `crewai reset-memories` are your instruments, and they are coarse — per-user deletion is only tractable if the user maps to a whole store or to an external provider that supports it. - **Retention.** Nothing prunes memory. Left alone, it grows unboundedly and keeps content long past any policy you have written down. - **Data at rest.** The storage directory holds embeddings and task records derived from customer inputs. It inherits their classification: encrypt the volume, keep it off shared machines, and include it in backup and access reviews. - **Auditability.** Memory is injected into prompts automatically, so "why did the model say that" may have an answer that lives in a vector store nobody logged. If you need explainability, capture what was retrieved. ## Choosing A useful decision order: does this crew genuinely benefit from cross-run accumulation? If not, run stateless — you remove the entire class of problem. If yes, how many tenants? A handful of large ones justifies per-tenant storage and processes. A long tail argues for an external user-scoped provider. And whichever you choose, write down the reset boundary — per session, per tenant offboarding, per retention window — because unbounded accumulation with no defined reset is how a convenience flag becomes a compliance finding. ## Interview framing Lead by naming the structural fact — memory is scoped to a storage location and retrieval has no tenant predicate — rather than reaching for a fix. Then give the three architectures with their honest tradeoffs, separate the knowledge risk from the memory risk, and finish on deletion, retention and encryption obligations. That is a principal-level answer; "use a different collection per user" alone is not.