Multi-agent memory: shared context without shared confusion

What is multi-agent memory?

Multi-agent memory is the set of shared and private records that lets several agents coordinate a task without replaying every transcript through every role. It includes working state for the active run, durable facts and decisions visible to selected agents, and private context used only by one specialist.

The problem is different from single-agent memory because several writers can produce conflicting values at the same time. The architecture must answer who may write, which memory is authoritative, who can read it and how a handoff carries only the context the next agent needs.

Which memory should agents share and which should stay private?

Share approved facts and decisions needed for coordination. Keep temporary reasoning, failed hypotheses and specialist-specific context private by default. A shared blackboard filled with every intermediate thought creates context pollution and increases the impact of one incorrect agent.

How should memory move between agents during a handoff?

A handoff should transfer an explicit package: task, current state, approved facts, unresolved questions, source references and the next expected action. It should not dump the sender’s full context window into the receiver. The receiving agent must know which claims are data, which are instructions and which are still uncertain.

Prefer a shared run record for coordination and bounded memory retrieval for relevant history. If the receiver needs a fact that is not in the handoff package, it can query the same scoped memory service rather than ask another model to summarize the entire conversation.

type Handoff = {
  taskId: string;
  objective: string;
  completedSteps: string[];
  approvedFacts: MemoryRef[];
  unresolvedQuestions: string[];
  blockedActions: string[];
  nextAgent: string;
  sourceIds: string[];
};

await runStore.writeHandoff(taskId, handoff);
await memory.recordEpisode({
  tenantId,
  userId,
  agentId: 'planner',
  taskId,
  kind: 'handoff',
  summary: 'Planner handed implementation to coding agent.',
  sourceIds: handoff.sourceIds,
});

How do you prevent conflicting writes across agents?

Assign write ownership by memory type and entity. A billing agent owns billing-state observations; a research agent proposes facts but cannot overwrite them; a coordinator approves a shared project decision. When multiple agents must write the same record, use version checks, confidence, source priority and conflict review.

Do not let the model choose the final truth from two confident statements. Preserve both with provenance, select the correct value through deterministic rules or an authorized resolver, and mark the losing record as rejected or superseded rather than deleting its history immediately.

How should multiple agents coordinate working state?

Use a run coordinator or graph runtime for task state, assignments and completion. Keep the durable shared memory smaller than execution state. The coordinator can publish milestones and approved decisions, while individual agents maintain their own local working context.

LangGraph persistence can store graph state and namespaced data, while frameworks such as CrewAI provide their own memory primitives. Whichever runtime you use, preserve a framework-neutral retention contract for facts that must outlive the graph or crew.

• One owner for each shared task milestone.
• Explicit status transitions instead of inferred progress.
• Bounded handoffs with sources and unresolved issues.
• Private scratchpads that are not automatically promoted.
• A shared decision log separate from conversation history.
• Idempotent writes so retries do not duplicate tasks.

How should multi-agent memory enforce user and tenant scope?

Resolve tenant and user identity before an agent runs and pass the trusted scope into every memory operation. An agent ID is an additional scope dimension, not a replacement for user or tenant identity. A supervisor should not inherit private memory from every specialist automatically.

Define which agent identities may read which scopes. Shared team memory can be visible to all approved agents, project memory only to project participants and user memory only when policy permits. If scope resolution fails, fail closed rather than querying a default namespace.

What must multi-agent deletion cover?

Deletion must cover every memory surface an agent can read: source events, extracted facts, summaries, graph relationships, embeddings, local caches and exports. It must also invalidate shared references used by coordinators and other agents.

Test deletion by querying through every agent identity, not only the agent that originally wrote the memory. A deleted customer fact that remains in a supervisor cache or second agent’s summary is still a production failure.

How do you test multi-agent memory?

Create a multi-agent run with overlapping work, one handoff and one changed decision. Verify that private scratchpads stay private, the receiver obtains only the needed handoff package and all agents return the latest approved decision from their allowed scopes.

Add adversarial tests for stale writes, simultaneous updates and cross-tenant requests. Then delete a fact through one agent and query through every other agent and coordinator path until no derived copy remains.

What are the most common multi-agent memory failures?

The most damaging pattern is a global blackboard containing every agent’s reasoning. It spreads one specialist’s hallucination to the entire team, consumes context and makes authorization difficult. Another common failure is a handoff that sends a narrative summary without source IDs, blockers or ownership, forcing the receiver to reconstruct work that already happened.

Concurrent writes create a different class of failure. Two agents can both write a plausible but conflicting decision, and last-write-wins may preserve the less authoritative source. Version checks, explicit write ownership and coordinator approval keep shared memory from becoming an opaque race.

• Global context for every agent, regardless of purpose.
• Private scratchpads promoted without review.
• Handoffs without sources, blockers or expected next action.
• Last-write-wins updates without version checks.
• Deletion tested through only the original writing agent.

What is the recommended multi-agent memory architecture?

Use the run coordinator for task state, scoped durable memory for facts and decisions, and explicit handoff packages for transitions. Keep specialist scratchpads private, assign write ownership, resolve conflicts deterministically and test deletion through every agent identity.