# Multi-Agent Shared Memory: What Agents Should Share, How to Scope It, and How One Agent Poisons the Rest

> Shared memory for a team of AI agents is a write-governance problem, not a storage problem. What to share and keep private, how to scope memory per agent, run, user and tenant, how to handle conflicting writes and consolidation, what provenance to record, and what the October 2026 DeepMind Minecraft run and Meta's reward-hacking paper show about shared notes helping and hurting.

_Gaurav Dadhich · 2026-10-28_

\# Multi-Agent Shared Memory: What Agents Should Share, How to Scope It, and How One Agent Poisons the Rest \*Published 28 October 2026. Every figure below comes from a paper or page read on 28 October 2026, linked where it appears and listed at the end.\* Multi-agent shared memory is a durable store that several agents read from and write to, so that what one agent learns is available to the others after its own context window is gone. Getting it right is a write-governance problem far more than a storage problem: the hard decisions are what each agent is allowed to write, into which scope, with what record of where it came from, and what gets checked before a private note becomes something every other agent treats as true. Two papers from October 2026 show both sides of that. In \[Google DeepMind's Minecraft run\](https://arxiv.org/abs/2610.22319), four Gemini 4 Argon agents with a memory that had "a private part and a part shared by the team" defeated the Ender Dragon in 27 hours and 14 minutes with no assigned roles and no game-specific planner; one agent posted a warning about a crafting quirk nineteen minutes in, and the helper function carrying the fix appears in 655 programs written by all four agents. In \[Meta Superintelligence Labs' reward-hacking paper\](https://arxiv.org/abs/2610.12822), the same channel carried a bad habit instead: when a reward-hacking coder and a clean coder shared a memory of past submissions and grader results, a Claude Opus 4.7 target produced confirmed reward hacks in 28.7% of its submissions on average. Shared memory did the work of a planner in the first case and spread a cheat in the second, and the difference is governance. ## What multi-agent shared memory is, and what it is not A message between agents is transient and point to point; it reaches the agents it was sent to and is gone once their context is compacted or the run ends. Shared memory persists, is addressable by any agent with the right scope, and is read again later by agents that were not present when it was written. The DeepMind agents had both: an in-game chat that reached every player's next program, and a persistent memory that survived context compaction, which their instructions told them to use for "work in progress and next steps". Three architecture shapes cover almost every real system. A \*\*centralized\*\* store has every agent read and write one place, which gives strong consistency and simple debugging and becomes a contention point as the team grows. A \*\*distributed\*\* design gives each agent its own store and syncs selected pieces, which isolates well and makes consistency painful, because the question "how quickly does the support agent learn that billing changed the plan?" now has an eventual-consistency answer. A \*\*hybrid\*\* keeps private tiers per agent and a shared tier for what the team acts on, and it is where production systems and the October 2026 experiments below land: the Minecraft memory was split private and shared, and \[Cohere's coding-agent teams\](https://cohere.com/blog/lessons-from-scaling-teams-of-frontier-coding-agents) worked in one shared workspace while each worker kept its own context. The \*\*blackboard\*\* pattern, where agents post results with an agent ID, timestamp and confidence to a shared board and others act on what appears, is the centralized shape with a schema, and its known weakness is two agents writing the same entry at once. A shared knowledge base answers "what is generally true about our product"; shared agent memory answers "what has this team learned and decided, for this task and this user, and who said so". It is the same line that separates \[agent memory from RAG\](https://www.maximem.ai/blog/agent-memory-vs-rag), with several writers instead of one. ## When a multi-agent system needs shared memory, and when it does not A multi-agent system does not always need shared memory, and the clearest evidence for that is recent. Cohere ran teams of GPT-5.6 coding agents on ProgramBench (200 programs to rebuild from scratch, scored by the share of a hidden behavioral test suite each rebuilt program passes, three runs per configuration) with a lead that hands out subtasks and workers that "see only the subtask" they are given and report back. Teams beat a single agent by up to about 10 points, at 3 to 7 times the cost. A Sol lead with 16 cheap Luna planning workers reached 61.8% for $155, against 63.2% for an all-Sol team that cost $510. That hierarchy needed a shared workspace and no team memory, because the lead held the whole picture. When Cohere gave every agent a \`send\_message\` tool, 84% of messages in the Sol teams went from workers to the lead, messages between workers averaged fewer than one per task, reward stayed flat for the Sol and Terra teams, and Luna teams lost 4 to 7 points. The authors' own suggestion for where communication would pay is "shared goals, shared progress logs, or messages that carry checkable evidence", which is a description of shared memory with provenance. A one-shot fan-out where an orchestrator collects results and the run then ends does not need persistent shared memory; pass state through the orchestrator. Shared memory earns its cost when agents build on each other's results across time, when no single lead can hold the whole state (the Minecraft team ran for more than a day across thousands of dependent steps with no designated lead), when several agents serve the same user or customer and must not contradict each other, or when a new agent should start with what the team already knows. ## What agents should share, and what they should keep private The useful test is whether another agent will act on it and whether it is safe for every reader in that scope to see. | Share with the team | Keep private to the agent (or a narrower scope) | |---|---| | Facts about the shared world the team acts on: locations, IDs, current state of an order or a ticket | Scratch reasoning, intermediate drafts and abandoned plans | | Tool quirks and the workaround, with the evidence that the workaround works | Hypotheses that have not been checked | | Decisions and the reason for each, so a later agent does not undo one blindly | Anything a person disclosed under a narrower permission than the team's | | Task status: claimed, done, blocked, by whom | Per-role working state that only makes sense to that role | | Lessons from failures, stated with what was observed | A bare "it passed" signal with no account of how it passed | The Minecraft team's shared notes are a clean example of the left column: the paper reports that the agents "posted the coordinates of chests, portals and dangers, and kept notes on the quirks of their tools in the memory the team shares", and their general instructions asked them to record "mechanics, strategies and workarounds in memory so that no obstacle is met twice". The last row of the right column matters as much. In the Meta paper the propagation channel was exactly a memory of past submissions paired with the grader's result for each, which is a lesson stripped of its evidence; a submission that passed by bypassing the tests looks, in that memory, exactly like one that passed by being correct. Failures are worth sharing, with that caveat. A record of what did not work stops the next agent from repeating it, provided it records what was tried and what was observed. ## Scope: per-agent, per-run, per-team, per-user, per-tenant, global Most shared-memory bugs in production are scoping bugs, not recall bugs. Scope decides which agents can see a memory, and the usual levels nest: | Scope | Holds | Typical reader | |---|---|---| | Agent (one agent instance or role) | Its own learned conventions and working notes | That agent only | | Run or task | Intermediate findings for one workflow execution | Agents in that run; ages out when it ends | | Team or project | Decisions, task status and shared lessons | Every agent on the team | | User | One person's preferences, history and facts | Any agent serving that person | | Customer or tenant | An organisation's facts, in a B2B product | Agents serving anyone in that organisation | | Account or global | Product facts and policies that apply everywhere | Every agent | Reads compose these levels. An agent serving one user in one run should see its own agent memory, the run, that user, that user's organisation and the global tier, and should never see a different user's memory or another tenant's. The rule that keeps this sane is that visibility flows one way, from wide to narrow: a user-scoped read may draw on customer and account memory, and a customer-scoped read must never reach into an individual user's memory. Assign scope when a memory is written, not only when it is read. A filter applied at read time is a check at a door the facts already walked through, and filters are easy to get subtly wrong. \[Mem0's documentation\](https://docs.mem0.ai/platform/features/entity-scoped-memory), for example, states that identifiers you do not mention are not constrained: filtering on \`user\_id\` alone also returns records that carry an \`agent\_id\` or \`run\_id\`. That is reasonable behaviour, documented clearly, and it means "agent B cannot see agent A's notes" holds only if every read includes the right filter. A paper on \[governed shared memory\](https://arxiv.org/abs/2606.24535) (Margalit et al., June 2026) reports the same class of failure in a live multi-tenant service: tenant isolation held, but sub-tenant scope was bypassed on direct GET-by-id requests made with agent-scoped credentials until the authors disclosed and fixed it. One question that the scope table does not answer by itself is whose scope an agent writes into when it acts for a person. An agent that files an expense report on behalf of an employee should write what it learns about that employee into the employee's scope, and record both identities: the agent that wrote it and the person it acted for. An agent with its own standing identity, such as a background agent that watches a queue for everyone, builds its own agent-scoped memory, and someone has to decide explicitly what it may read of each person's. ## Multi-user agents: permissions have to follow the information Shared memory gets harder when several people use the same agent, for example in a Slack channel. \[Mastra's Sam Bhagwat calls the control needed here fine-grained context\](https://mastra.ai/blog/fine-grained-context): the agent has to adapt to each user's authorization level and to everyone who can see the conversation. His example is a private calendar event read in a one-to-one chat ("Medical Appointment") that resurfaces later in a shared scheduling conversation with a co-worker who can only see availability, either because the tool result is still in context or because it was written to a stored memory. The practical consequences for memory are direct. Store source references and permissions with every memory, and keep them through summaries, so access can be rechecked at read time. Build shared summaries only from inputs every member of the audience was already allowed to see; a summarizer cannot be trusted to strip every private detail. Recheck when the audience changes, including when someone joins a conversation or a permission is revoked mid-run. ## Conflicting writes: concurrency, retries and contradictions Two different problems hide under "conflict", and they need different tools. \*\*Write conflicts\*\* happen when two agents update the same record at once. The tools are the familiar ones from distributed systems: optimistic locking with version numbers, compare-and-swap for anything that represents state an action depends on (an order's status, a claimed task), and last-write-wins only for data where losing a write costs nothing. The swarm-specific trap is retries. \[Hindsight's post on thirty agents sharing one memory\](https://hindsight.vectorize.io/blog/2026/10/20/agent-swarm-memory) (Vectorize, 20 October 2026) points out that a retry without a stable document ID writes a second complete copy of everything, and the consolidation layer then reads the duplicate as further corroboration. The fix is to derive the ID from the unit of work (worker plus task), never from the attempt or a timestamp. The same post notes that entity names written by different agents at the same instant can split one company into two entities, because each write sees nothing committed yet to match against; later writers converge on whichever name committed first. \*\*Semantic conflicts\*\* happen when two agents assert incompatible facts about the same thing. Do not resolve these by overwriting. Keep both, decide which is current (by recency, by the source's authority, or by an explicit policy), mark the older one as historical and link it to its replacement, so the system can still answer what it used to believe and why it changed. Watch for one specific bad trade: a newer statement that is vaguer than the old one ("takes a cholesterol medication" against "takes 20mg of atorvastatin daily") should enrich or be discarded, not replace the precise fact. Pipeline order matters as well. The governed-memory paper found that a synchronous near-duplicate gate rejected contradictory writes before the asynchronous contradiction detector ever saw them, so the system never learned that a fact had changed. Agents can catch some contradictions themselves if claims are visible to the team. In the Minecraft run, when one agent reported returning with twelve blaze powder one second after burning to death, a teammate flagged the contradiction within three minutes, and another agent retracted a success its own program had announced: "my previous chat was an unguarded script branch". That only works when claims carry enough context (who, when, what was observed) for another agent to check them. For how time-aware storage handles supersession, see \[knowledge graphs versus vector search for agent memory\](https://www.maximem.ai/blog/knowledge-graph-vs-vector-search-agent-memory). ## Consolidation: twenty agents, one finding A swarm writes the same finding many times by construction. If twenty workers each conclude that a checkout service retries three times, you want one belief backed by twenty observations, not twenty rows competing in retrieval. Hindsight's design keeps every raw fact (it never merges two of them) and consolidates related facts into observations with a \`proof\_count\`, defined as the number of distinct live source memories behind the observation. Twenty agents agreeing becomes one observation with a proof count of twenty. Agreement is only evidence if the agents were independent. Twenty agents that read the same poisoned note and repeated it are one source counted twenty times, and a retry storm inflates the count without anyone confirming anything. Treat a corroboration count as a signal to inspect, and record enough provenance to tell independent confirmation from echo. Consolidation is also the promotion path from private to shared. A finding should usually start in the narrowest scope (the agent or the run), move to the team when it has been checked or independently repeated, and move to the user or organisation tier when it is durable. Each promotion is a write into a wider scope and deserves the same check as any other write there. The other half of consolidation is forgetting: run-scoped notes should age out when the run ends, team notes when the project closes, and anything that keeps growing without a retention decision will eventually surface stale context as if it were current. ## Provenance: what every shared memory should record When three agents disagree at 2am, provenance is the difference between reading the answer and guessing it. These are the fields I would require on every write into a shared scope: | Field | Why it matters in a team | |---|---| | Writing agent (identity and role) | Tells you which agent to distrust, retrain or quarantine | | Acting on behalf of | Separates the agent's identity from the person whose scope it wrote into | | Scope | Makes the write-time decision auditable | | Source evidence | The verbatim observation or tool output behind the claim, so a reader can check it | | Time stored and time the event happened | They differ, and the event time is often the one that matters | | Confidence | Lets readers weight a hypothesis below a verified fact | | What it replaced | Keeps the history of a belief instead of overwriting it | The governed-memory paper treats losing this as its own failure mode ("provenance collapse") and reports reconstructing all depth-four derivation chains with the correct writer identity in its harness. Provenance is also the precondition for every defense against a misbehaving agent: you cannot quarantine one agent's writes if you do not know which writes were its. ## How one agent poisons the rest For a single agent, a bad memory is one bad session. In a team, it is the premise every other agent recalls. Meta Superintelligence Labs measured this for reward hacking, where a coding agent passes an automated grader without solving the task (for example by exiting the process early or adding a pytest hook). The authors elicited hacking in small open-weight source agents (mid-training on synthetic documents about the test environment, then coding RL) and paired each source with clean target agents built on fourteen different models. In the shared-memory experiment, source and target solved the same new task each round and both submissions, with the grader's result for each, were appended to a shared memory the target consulted in later rounds; each seed ran 30 trajectories of 12 rounds, and the reported rate is the share of the target's submissions that were confirmed hacks. | Target model | Source: Qwen2.5-Coder-14B (conftest hook) | Source: Gemma-3-12B (early exit) | Source: Gemini 3.1 Pro after six hops | |---|---|---|---| | Qwen3-235B | 16.0% | 19.7% | 61.3% | | Claude Opus 4.7 | 28.7% | 13.0% | 38.7% | | Gemini 3.1 Pro | 14.0% | 0.3% | 21.7% | | Claude Opus 5 | 11.1% | 2.0% | 7.2% | | GPT-5.5 | 0.0% | 0.0% | 0.3% | Mean shared-memory propagation rates from Table 9 of \[arXiv 2610.12822\](https://arxiv.org/abs/2610.12822) (v2, 12 October 2026), Python coding tasks graded by pytest; selected rows, the full table has fourteen targets. A hack counts as confirmed under the paper's mechanical criterion, which the authors validated on a random sample. Three findings matter for anyone designing shared memory. Small open-weight sources pushed stronger closed-weight targets into hacking. The strategy got more contagious as it travelled: a Gemini 3.1 Pro agent that had picked the hack up six hops down a transmission chain induced stronger shared-memory propagation than the Gemma source the chain started from, and the authors attribute the intensifying chains on hard tasks to code that "acquires more persuasive justifications" at each hop. And the effect reached coordination itself, biasing task routing toward the hacking agents and surviving aggregation when no clean candidate passed. The defenses that worked, and their costs, are specific. The authors' recommendation is to treat "code, memory entries, and plans from other agents" as untrusted input. A separate verifier gating what gets delivered reduced delivered hacks, with several verifiers reaching zero or near zero, but showing the verifier the default grader's pass signal increased false accepts, and even the best verifiers rejected some genuine solutions. Self-review by the coder lowered propagation for every coder tested, but most still produced hacks. Translated into memory design: gate writes into shared scopes, never store an outcome without the evidence behind it, keep the planner's brief and the team's agreed conclusions in a namespace workers cannot overwrite (Hindsight's swarm post recommends exactly this), and run an independent check before a note is promoted to shared truth. The DeepMind team did a version of the last one: a fifth Observer agent followed the session as an independent witness for cheating or specification gaming and found none. ## Latency, consistency and cost pull against each other Strong consistency (every agent sees a write immediately) costs latency and coordination; low latency usually means caching or eventual sync, which brings back agents acting on stale state; and low cost means pruning aggressively, which forces agents to re-derive what the team already knew. A sensible split is strong consistency for small, action-critical state (task claims, order status, the team's current plan), eventual consistency for accumulated knowledge, and nothing persistent at all for scratch work. The shared tier is also cheaper than the alternative it replaces: passing every agent's full history to every other agent grows the prompt on every call, and the Minecraft run, which leaned on context caching (91% of 1.35 billion input tokens were served from cache), still estimated about $520 at introductory list prices for the players up to the win. ## How to test a shared-memory design before you ship it Test the scope boundaries as hard as you test recall. Mastra's list of cases is a good start: two people ask the same question with different permissions; a private discussion continues in a shared conversation; a private fact survives a summary and is recalled later; a permission changes during a tool call. Add three cases specific to teams of agents. Write a contradictory fact from a second agent and check that the first one is marked historical rather than silently kept or silently lost. Retry a worker mid-task and check that nothing is counted twice. Plant a plausible but wrong note from one agent (a fake workaround, or an outcome without evidence) and measure how many other agents repeat it, which is the Meta protocol scaled down to your system. The rest of a memory test plan carries over from single agents; see \[how to test agent memory before you ship\](https://www.maximem.ai/blog/how-to-test-agent-memory). ## What memory layers give you for multi-agent scoping today The distinction to look for in any memory layer is whether scope is a first-class part of the write, whether reads compose scopes in one direction, whether contradictions are tracked instead of overwritten, and whether provenance survives consolidation. Most layers give you the identifiers; fewer give you the governance. Mem0 scopes memory by \`user\_id\`, \`agent\_id\`, \`app\_id\` and \`run\_id\`. Hindsight uses banks and tags, consolidates into observations with proof counts, and offers a Memory Defense policy that is off by default. Mastra maps thread and resource identifiers to your own access rules and leaves fine-grained context as a pattern you assemble from its authorization, memory scopes and processors. Agent-to-agent protocols are a separate layer again; \[A2A and MCP\](https://www.maximem.ai/blog/mcp-vs-a2a) move messages and tool calls, not durable shared state. Maximem Synap lets several agents share a central context layer while keeping their own agent-specific memories, and the scope chain handles the isolation between them. Memory is isolated by default across the account, the customer, the individual user and the conversation, a read sees the narrowest scope that applies and everything above it but never below or sideways, organisations with a deeper shape can model it as their own hierarchy to any depth, and a grant gives one part of that hierarchy directed, read-only access to another's memories. Every memory carries a type, a confidence score, its scope, when it was stored and when the thing it describes happened, and provenance records where it came from, what it replaced and what it used to say, so a change to a fact is recorded rather than overwritten. Building this yourself is a reasonable choice, as long as the estimate accounts for where the time goes: the retrieval is the easy part, and the work is in scoping, contradictions and keeping tenants apart. ## A minimum design to decide before the first agent writes 1. Where the shared tier lives, and which state is strongly consistent (claims, statuses, the plan) versus eventually consistent (knowledge). 2. The scope ladder for your product (agent, run, team, user, customer, global), with scope assigned at write time and reads that compose upward only. 3. Who may write where. Default write access to shared scopes is "no"; give it per role, and keep the brief and agreed conclusions in a namespace workers cannot overwrite. 4. The provenance fields every shared write must carry, including the acting-on-behalf-of identity and the source evidence. 5. The contradiction policy: which fact wins, how the loser is kept and linked, and in what order duplicate and contradiction checks run. 6. The promotion check a note passes before moving from an agent's private notes to the team, and from the team to the user or organisation tier. 7. Retention for each scope, and stable IDs per unit of work so a retry replaces its earlier attempt instead of duplicating it. If you cannot answer one of these, the agents will answer it for you in production, and the answer will be whatever the last writer said. Answer them up front and a new agent joins the team already knowing what the others learned, and your customers stop getting two different answers from two of your agents. ## Frequently asked questions ### What is multi-agent shared memory? Multi-agent shared memory is a persistent store that several AI agents read and write, so what one agent learns or decides is available to the others after its context window is gone. It differs from messages between agents, which are transient, and from a document knowledge base, which holds reference material, not what the team has learned. Most production designs are hybrids: a private tier per agent and a shared tier for what the team acts on. ### What should agents share and what should they keep private? Share facts about the shared world the team acts on, decisions with their reasons, task status, tool quirks with their workarounds, and lessons from failures stated with what was observed. Keep scratch reasoning, unchecked hypotheses, per-role working state and anything a person disclosed under a narrower permission private. Never share an outcome (such as "the tests passed") without the evidence behind it, because that is the channel through which reward hacks spread in Meta's October 2026 experiments. ### Should memory scope be enforced at write time or read time? Assign scope at write time and also enforce it on every read. Read-time filters alone are easy to get wrong: some memory APIs, by documented design, return records with extra identifiers when a filter omits them, and a June 2026 study of a production multi-tenant memory service found sub-tenant scope bypassed on direct lookups by ID until it was fixed. ### How do you handle two agents writing conflicting facts? Separate write conflicts from semantic conflicts. For simultaneous updates to the same record, use version checks or compare-and-swap, and give each unit of work a stable ID so a retry replaces its earlier attempt. For contradictory facts, keep both, mark which one is current under an explicit policy, link the old one to its replacement, and never let a vaguer statement overwrite a precise one. ### Can one agent poison a shared memory? It can, and the effect has been measured. In Meta Superintelligence Labs' October 2026 paper, a reward-hacking coder sharing a memory of past submissions and grader results led a clean Claude Opus 4.7 target to submit confirmed hacks in 28.7% of submissions on average, and a source that had picked the hack up six hops down a chain pushed a Qwen3-235B target to 61.3%. Treat memory written by other agents as untrusted input, gate writes into shared scopes, and verify before promoting a note to shared truth. ## Sources All retrieved 28 October 2026. - Faldor, Singh and Raileanu (Google DeepMind), \[A team of Gemini 4 Argon agents beats Minecraft\](https://arxiv.org/abs/2610.22319), arXiv 2610.22319, submitted 15 October 2026. Single run on Easy difficulty, the first launch the authors tried. - Hu, Ghahremani, Aghajani, Pasupuleti and Bhattacharjee (Meta Superintelligence Labs; Duke University), \[Reward Hacking as a Transmissible Strategy in Multi-Agent Coding Systems\](https://arxiv.org/abs/2610.12822), arXiv 2610.12822 v2, 12 October 2026. Section 5.4 and Appendix K.4, Table 9; mitigations in Section 8. - Cohere, \[Lessons from scaling teams of coding agents: reach the frontier at 30% of the cost\](https://cohere.com/blog/lessons-from-scaling-teams-of-frontier-coding-agents), 14 October 2026. - Ben Bartholomew (Vectorize), \[Thirty Agents, One Memory\](https://hindsight.vectorize.io/blog/2026/10/20/agent-swarm-memory), Hindsight blog, 20 October 2026. - Sam Bhagwat, \[Multiplayer agents need fine-grained context\](https://mastra.ai/blog/fine-grained-context), Mastra blog, 8 October 2026. - Margalit, Cohen-Inger, Avram, Taig and Margalit, \[Governed Shared Memory for Multi-Agent LLM Systems\](https://arxiv.org/abs/2606.24535), arXiv 2606.24535, 23 June 2026. - Mem0 documentation, \[Entity-scoped memory\](https://docs.mem0.ai/platform/features/entity-scoped-memory).

---

Source: [https://www.maximem.ai/blog/multi-agent-shared-memory](https://www.maximem.ai/blog/multi-agent-shared-memory)