Multi-Agent Memory

Multi-agent memory is the design of how multiple agents store, retrieve, share, isolate, refresh, and cite context across tasks, sessions, users, and tools. It is a coordination problem as much as a storage problem. When several agents can act on shared context, the system must define what is remembered, who can see it, how fresh it is, and where it came from.

The topic is related to retrieval-augmented generation and long-term memory, but it is narrower than either. Multi-agent memory focuses on memory as shared or bounded state inside an agent team. A system may need private memory for a specialist, shared memory for a workflow, durable memory across sessions, or temporary working memory that should disappear after a task is complete.

Background

A single-agent application can often treat memory as a conversation history, a vector search result, or a persistent profile. Multi-agent systems complicate that model. One agent may gather evidence, another may summarize it, a third may act on it, and a supervisor may decide what the user sees. Each step raises memory questions: what context moves forward, what remains private, and how later agents know which facts are reliable.

LangChain's memory documentation describes long-term memories as documents stored under namespaces and keys, with search across namespaces and choices around when memories are formed. LangGraph's persistence documentation distinguishes short-term memory through checkpointers from long-term memory through stores. Research systems such as MemGPT frame memory as tiered context management, while Generative Agents uses records, reflection, retrieval, and planning to shape agent behavior over time.

These sources do not describe one universal memory architecture. They show that agent memory is usually a set of design choices: persistence, retrieval, provenance, reflection, namespace boundaries, and update timing.

Memory Types and Boundaries

Short-term and working memory

Short-term memory supports the current interaction or task. It may include recent messages, intermediate reasoning traces, task state, or temporary tool results. In workflow systems, checkpointers can preserve state so work can resume after interruption or be inspected later.

Working memory should usually be bounded. If every temporary note becomes durable memory, later agents may inherit stale or irrelevant context. If too little working memory is preserved, handoffs become brittle because the receiving agent cannot reconstruct what happened.

Long-term memory

Long-term memory persists beyond a single interaction. It may store user preferences, project facts, prior decisions, known entities, source notes, or reusable knowledge. LangChain's memory model uses namespaces and keys to organize memory, while LangGraph separates persistent stores from short-term checkpoints.

In multi-agent systems, long-term memory needs access boundaries. A research agent, coding agent, and publishing agent may not need the same memories. Some memory may be global, some may be role-specific, and some may require human approval before reuse.

Shared and private memory

Shared memory lets agents coordinate. It can prevent repeated work, preserve decisions, and help a later agent understand why an earlier one acted. Private memory can preserve role boundaries, reduce leakage, and keep irrelevant context from contaminating another agent's work.

The design question is not whether memory should be shared. It is which memory should be shared, at what granularity, and with what source trail. A useful memory boundary describes both visibility and authority: an agent may be allowed to read a memory, cite it, update it, or act on it.

Namespaced memory

Namespaces are one practical way to bound memory. A namespace might represent a user, project, task, role, organization, or source collection. Namespaces can make memory easier to search and govern, but they also require naming conventions and update rules.

Poor namespace design can make memory appear reliable when it is stale or irrelevant. It can also hide important context from the agent that needs it. Multi-agent systems therefore need explicit rules for where memories are written and how agents search across boundaries.

Provenance and Freshness

Provenance is the record of where a memory came from. In a source-backed workflow, provenance can include a session artifact, document, URL, tool result, human decision, or prior generated output. Without provenance, agents may repeat claims that no one can verify.

Freshness is the question of whether a memory is still current enough to use. A memory about a user's preference may remain stable for months. A memory about a deployed system, API behavior, pricing, or publication status may expire quickly. Multi-agent memory systems should make freshness visible, especially when one agent acts on another agent's stored context.

The Portal event that sparked this page included coordinated memory as a practical theme, but the event should not be used as proof of a specific implementation. It is better treated as a source anchor: a real builder session where named agents, shared memory, handoff, and profile-state concerns appeared together.

Retrieval and Reflection

Retrieval decides which memories enter the active context. Search can be based on semantic similarity, keys, namespaces, time, source type, user identity, or task state. In multi-agent systems, retrieval also decides whether one agent receives another agent's context.

Reflection is a second layer. The Generative Agents paper describes agents that synthesize reflections from stored experiences and use those reflections in later planning. Reflection can make memory more useful by compressing experience into higher-level patterns, but it also introduces risk: a reflected memory may be an interpretation rather than an original source.

For source-backed workflows, original sources and generated reflections should remain distinguishable. A later agent should know whether it is using a transcript, a human decision, a generated summary, or a synthesized pattern.

Coordination Risks

One risk is conflicting writes. Two agents may update the same profile, project state, or memory namespace with incompatible interpretations. If the system does not record source, time, and authority, later agents may treat both as equally valid.

Another risk is hidden context. An agent may produce an answer based on memory that the user or reviewer cannot inspect. This is especially problematic when the answer affects public publishing, money movement, production systems, or claims about people and projects.

Over-shared memory is also a failure mode. If every agent receives all prior context, role boundaries weaken and the system may reproduce stale assumptions. A test agent, publishing agent, and financial agent should not automatically inherit the same permissions or context simply because they belong to the same system.

The session spark for this topic included profile reasoning serialization and profile race concerns. Those should be handled carefully in any public page: they are useful examples of state coordination problems, but exact implementation details should not be asserted without direct verification.

Relationship to Role Orchestration

Multi-agent memory and role orchestration are independent but connected. Role orchestration asks which agent should act. Memory asks what that agent can know. A handoff between agents depends on both: control must move to the right agent, and the right context must move with it.

A memory system can support role orchestration by preserving task state, source trails, and prior decisions. It can also undermine role orchestration if all agents inherit the same context without boundaries. Good multi-agent design usually treats memory visibility, role authority, and human oversight as linked design choices.

Open Questions

• Which memories should be shared across all agents, and which should remain private to a role or user?
• How should agents expose source provenance when reusing another agent's memory?
• What refresh or expiry rules prevent stale memory from silently shaping later actions?
• How should a system resolve conflicting writes or interpretations from multiple agents?
• When does multi-agent memory become a permissions problem rather than a retrieval problem?

Related Topics

• Agent Role Orchestration
• Multi-Agent Coordination
• Context Engineering
• Retrieval-Augmented Generation
• Economic Agency for AI Agents