Memory types · Multi-agent
What Is Shared Memory in Multi-Agent Systems?
Shared memory is a store several agents read from and write to, so they coordinate through a common record of state rather than by passing messages to each other. It removes a coordination problem and creates a consistency one, which is the trade this page is about.
Two coordination models
Definition
What is shared memory in a multi-agent system?
Shared memory is a persistent store that more than one agent can read and write, holding task state, findings and decisions in one place so that every agent works from the same record. The pattern is old enough to have a name outside AI: a blackboard architecture, where specialists contribute to a common workspace rather than negotiating with each other directly.
The alternative is message passing, where agents hand results to each other directly. That works for a fixed pipeline of two or three agents and degrades quickly as the number grows, because every agent has to know who to tell and what format they expect. A shared store replaces those connections with one interface.
Shared memory is a scope decision rather than a new memory type. The same semantic, episodic and procedural memories described on the types of AI agent memory can be scoped to one agent, to a team of agents, or to the whole system, and the scope changes what can go wrong far more than it changes what is stored.
Before the example, the choice it represents is worth stating plainly: shared memory against message passing.
The choice
How does shared memory differ from message passing?
Message passing moves information between agents; shared memory publishes it to a place any agent can read. The first couples agents to each other, the second couples them to a format.
Message passing is direct and easy to reason about for small systems. Agent A finishes and hands its output to agent B. The trace is obvious, latency is low, and nothing persists that does not need to. It stops scaling for a specific reason: every agent has to know who consumes its output and in what shape, so adding an agent means editing the ones around it.
Shared memory inverts that. An agent writes what it produced and never learns who reads it. Adding a consumer changes nothing about the producer. The cost is that the store becomes an interface: its format is now a contract, and a change to what a field means affects every agent silently rather than at a call site.
There is also a durability difference that decides many designs. A message is consumed and gone, so a system that crashes mid-pipeline loses the work in flight. A shared store keeps the record, so a restarted system can see what was already done and continue. For long-running tasks that property alone justifies the store.
Most production systems use both, and the split is usually clean: messages for control flow, meaning who should act next, and shared memory for the results, meaning what has been established so far. Trying to do control flow through a shared store produces agents polling for work, and trying to carry results through messages produces the coupling described above.
The difference is easiest to see in a concrete arrangement: a worked example of shared memory.
Example
Can you give an example of a shared memory system?
A research and drafting pipeline is the clearest case: a researcher agent writes findings, a writer agent reads them and produces a draft, a reviewer agent writes verdicts, and a planner agent updates the task list from those verdicts. No agent calls another. Each one reads what it needs and writes what it produced.
Walk one task through it. The planner writes three open questions to the store. The researcher picks up an unanswered question, gathers sources, and writes findings tagged to that question. The writer sees a question with findings and no draft, and produces one. The reviewer sees a draft without a verdict and writes one. The planner sees a negative verdict and reopens the question with a note about what was wrong.
Two properties fall out of that arrangement. Agents become replaceable, since any agent that can read the store’s format can do the job, and adding a second researcher requires no changes elsewhere. The system is inspectable, because the store holds the entire history of what was decided and why, which is far easier to debug than a trace of messages between processes.
The same pattern appears in customer operations, where an intake agent, a diagnosis agent and a resolution agent share one case record, and in coding systems where a planner, an implementer and a reviewer share one task state. Those are covered on memory for customer support agents and memory for coding agents.
The arrangement also creates a class of failure a single agent never has: what goes wrong when agents share memory.
Failure modes
What goes wrong when agents share memory?
Four failures, and all four are versions of the same problem: several writers, no agreement about who is authoritative. A single-agent store never has to answer that question.
- Contradiction. Two agents write incompatible conclusions and neither is marked authoritative, so retrieval returns both and whichever ranks higher wins by accident. The resolution procedure is on handling conflicting and stale memories.
- Feedback loops. One agent writes an inference, a second reads it as a fact and writes a conclusion drawn from it, and a third treats that conclusion as corroboration. Nothing in the store distinguishes an observation from an inference built on one, so confidence compounds without new evidence.
- Write contention. Two agents update the same record from stale reads and one silently overwrites the other. This is an ordinary concurrency problem, and it needs an ordinary answer: versioning, or a single writer per record.
- Scope leakage. A memory written for one task or tenant is retrieved in another because the store had no scope boundary. With one agent this is a bug; with several it is a much likelier bug, since more code paths write. See memory security and access control.
The mitigation for the first two is provenance: record which agent wrote each memory and whether it was observed or inferred, so ranking can prefer observations and a bad inference can be traced and removed rather than merely outvoted.
Knowing the failures makes the design question tractable: how to design shared memory that holds up.
Design
How do you design shared memory that holds up?
Four rules cover most of it: scope every memory, record provenance, give each record one owner, and separate task state from durable knowledge.
- Scope every write. Task, tenant and user identifiers attached at write time and applied as filters during retrieval. Without this, more agents simply means more ways to leak.
- Record who wrote it and how they knew. An agent identifier plus an observed or inferred marker. This one field prevents most feedback loops, because inferences can be ranked below observations and traced when wrong.
- One writer per record. Several agents may read anything; only one should own updates to a given record. Where that is impossible, use versioning so a conflicting write fails loudly rather than silently winning.
- Separate working state from knowledge. The task list is coordination data with a short life. A durable fact about a customer is memory. Mixing them means the store is either too volatile to trust or too permanent to coordinate with.
Most production systems end up hybrid rather than purely shared. Each agent keeps a private scratchpad for its own reasoning, and only conclusions worth acting on are promoted to the shared store. That promotion step is the multi-agent version of consolidation, covered on memory consolidation.
The implementation choices are covered on how to share memory across multiple agents, and the frameworks that support it on the best AI memory tools.
Before building any of it, the prior question is whether the system needs shared memory at all: when to share memory between agents.
Selection
When should agents share memory?
When agents work on the same task, when the order of work is not fixed in advance, or when the set of agents changes over time. If a pipeline is fixed and short, passing results directly is simpler and has fewer ways to go wrong.
The clearest signal is a task that outlives any single agent’s turn. A support case handled by three specialists over two days needs a shared record, because no agent is present for the whole thing. By contrast, an extraction step that feeds a classification step needs a function call, not a store.
The second signal is dynamism. If agents are added, removed or reassigned, direct connections between them become the thing you maintain, and a shared store removes that maintenance entirely.
The cost side is real and worth pricing before committing. Shared memory adds a consistency model to design, provenance to record, scope enforcement to implement, and a debugging surface where the culprit for a bad answer may be an agent that ran hours earlier. For a two-agent system, that is usually more machinery than the problem deserves.
A useful way to decide is to ask what happens when one agent is wrong. In a message-passing pipeline a bad output is consumed by one downstream agent and the damage is bounded. In a shared store a bad write is visible to everyone, is read as established fact, and can be built on repeatedly before anyone notices. That is not an argument against sharing, but it does mean provenance and scope are prerequisites rather than refinements, and a team that adds shared memory without them has usually made their system harder to debug rather than easier.
Multi-agent memory sits alongside the single-agent mechanisms rather than replacing them, and the underlying operations are the same ones described in how AI memory works.
FAQ
Frequently asked questions
The questions that follow: which frameworks support shared memory, and how to keep agents from overwriting each other.
Why use shared memory for AI agents?
Agent teams need common context — research findings, task state, customer records — without re-deriving facts each turn. Shared memory enables coordination and collective learning.
Shared memory vs per-user memory?
Per-user memory scopes facts to one end user. Shared memory scopes to a team, project or agent pool. Production systems often use both layers.
Is Python shared memory the same as agent shared memory?
No — Python multiprocessing.shared_memory is OS IPC between processes. This page covers AI agents sharing a semantic/graph memory store.
What is the namespace pattern for multi-agent memory?
Single vector/graph store with metadata filters: org_id, team_id, agent_id. Each agent reads shared namespace, writes with provenance tags.
How does Zep handle multi-agent memory?
Shared temporal graph with agent provenance on edges. Bi-temporal invalidation resolves conflicts. LongMemEval +18.5% vs baseline (Rasmussen et al., 2025).
LangGraph shared memory store?
LangGraph supports shared stores with thread/namespace scoping. Pair with LangMem for durable cross-agent LTM.
How do you resolve multi-agent memory conflicts?
Last-write-wins, versioning, temporal KG invalidation (Zep), coordinator merge or confidence scores. See conflicting memories.
Shared memory for coding agent teams?
Blackboard or coordinator pattern: planner writes task state, coder reads constraints, reviewer writes feedback. See coding agents use case and multi-agent memory guide.