CrewAI Memory with Supermemory: Scope, Retrieval, and Writes

CrewAI provides native memory, including persistent storage and scoped recall. Supermemory can complement it when a workflow needs context shared with other applications or a separately managed retrieval service. Decide which system owns each kind of information before enabling both.

The CrewAI memory documentation describes its unified memory interface. Avoid treating every crew as inherently ephemeral or assuming that a framework's memory is limited to one run.

Separate the crew from the customer

A crew identifies cooperating agents and tasks. It does not automatically identify the customer whose history those agents may read. The same crew definition can serve many users, while one user can interact with several crews.

Use explicit identities for the tenant, customer, task run, and source records. A shared research crew may need project-wide facts, while a support crew must isolate customer-specific context. Do not infer that boundary from the natural-language role assigned to an agent.

Choose one write authority

Data	Suggested responsibility
Task inputs and outputs	Run history and application records
Facts intentionally shared across a crew	Configured native or external memory scope
Personal customer context	Authorized customer scope
Approved business changes	The system performing the change

If native memory and external writes both extract the same task output, corrections and deletion become harder to reason about. Start with one authoritative durable write path and inspect exactly what it retains.

The Supermemory CrewAI guide describes retrieving context before a crew runs and saving selected material afterward. Use that sequence as an application boundary rather than assuming a single flag synchronizes every store.

Test the boundary with a fake crew first

This small orchestration function injects retrieved context into a crew-like object and persists only a separately confirmed user fact. It is an application adapter, not a replacement CrewAI API. The fake used in local tests implements kickoff(inputs=...), allowing order and scope to be checked without model calls.

def run_scoped_crew(crew, memory, scope, task, confirmed_fact=None):
    if not scope or not task.strip():
        raise ValueError("Authorized scope and task are required")
    context = memory.recall(scope, task)
    result = crew.kickoff(inputs={
        "task": task,
        "memory_context": context,
    })
    if confirmed_fact is not None:
        if not confirmed_fact.strip():
            raise ValueError("Confirmed fact must not be empty")
        memory.save(scope, confirmed_fact)
    return result

memory.recall and memory.save are your adapter's interface. Implement them using the selected provider's real SDK and error handling. Configure the crew's task templates to consume task and memory_context; passing unused input fields does not guarantee the model receives them.

A successful crew run should not automatically confirm every statement in its output. The caller supplies confirmed_fact only after the application has established that it is appropriate to retain.

Inspect context at each handoff

Multiple agents can multiply irrelevant context as summaries pass between them. Check whether a specialist needs the full customer profile or only the fact relevant to its task. Preserve source IDs for evidence that affects the final answer.

An instruction inside retrieved text remains untrusted source content. It must not redefine the agent's permissions or authorize a tool action. Limit tools independently of what memory says the user previously wanted.

Test cross-run behavior

Run the same crew twice for one fictional user, then once for another. Verify that the second run receives permitted context and the other user does not. Replay a failed task to check duplicate writes, then correct and delete a stored fact.

The local adapter tests verify ordering, scope forwarding, and the explicit-save boundary with test doubles. They do not run a live crew, model, or Supermemory request. Pair them with actual configured task templates and a two-run integration test before rollout. Use the isolation guide for additional cross-user cases.

Try the adapter around one crew task: start with Supermemory and a fictional user’s prior decision. Inspect what reaches the task on its second run and save only the outcome your workflow intends to retain.