Guides · Multi-Agent
Multi-Agent Memory: Sharing, Scoping and Conflicts
Sharing memory across more than one agent introduces four specific failure modes that a single agent never encounters: unauthorized leakage between agents, stale writes that never propagate, contradictions that persist because no agent has authority to resolve them, and facts nobody can trace back to their source. Solving one of these does not solve the others, and most informal advice on “shared memory” only addresses the first.
Three patterns
The problem
Why does single-agent memory break down with more than one agent?
Because single-agent memory has exactly one writer and one reader, so questions of authority, visibility and staleness simply do not arise. A single agent’s memory can be append-only, can trust every write it made itself, and never has to ask whether it is allowed to see a given fact. Add a second agent and all three assumptions break at once.
The moment two agents can both write to the same store, the store needs a way to decide whose write wins when they disagree. The moment two agents can both read from it, the store needs a way to decide who is allowed to see what, because not every fact one agent produces should be visible to every other agent in the system. And the moment agents run concurrently rather than in strict sequence, the store needs a way to handle a read that arrives before a related write has finished propagating.
None of these problems are solved by simply pointing every agent at the same database. That gets the agents reading and writing the same rows, which is necessary and not remotely sufficient; it is the same mistake as assuming a shared filesystem is a shared understanding. The actual design question is which of three broad patterns to build around, and each answers the authority, visibility and timing questions differently: should memory be shared, isolated, or hierarchical?
The choice
Should memory be shared, isolated, or hierarchical?
Hierarchical, for most production systems, because it is the only one of the three built to answer who is allowed to see a given fact rather than assuming the answer is everyone or no one. Each of the three patterns is a legitimate choice for a different situation.
A fully shared pool, one store every agent reads and writes without restriction, is the fastest to build and the easiest to reason about when it works. Its failure mode is exactly the one that matters most: every agent can see every write, including ones it should not, which is the unauthorized-leakage problem covered below.
Fully isolated memory, where each agent holds its own private store, eliminates leakage by construction, because there is nothing to leak into. Its cost is that any coordination between agents has to happen through explicit message passing rather than through shared state, which pushes complexity into the orchestration layer instead of removing it.
Hierarchical or scoped memory sits between the two: visibility is controlled by role, team or task, so an agent sees what its position in the system entitles it to see and nothing else. It costs more design work upfront, since scopes have to be defined and enforced, but it is the pattern that scales to the failure modes production systems actually hit. Naming what those failure modes look like in practice is worth doing before choosing an architecture: what actually goes wrong when agents share memory carelessly?
Failure modes
What actually goes wrong when agents share memory carelessly?
Four distinct problems, each requiring its own fix rather than one generic solution. Naming them precisely matters, because “our multi-agent memory has issues” hides four different bugs with four different remedies. Recent research on governed shared memory for multi-agent systems names all four explicitly, with worked examples for each, which is the framing this section follows.
Unauthorized leakage is an agent retrieving memory outside what it should be able to see, such as a customer-support agent pulling up billing notes meant only for finance. Systems built on plain semantic retrieval are especially exposed here, because eligibility is governed by embedding similarity rather than by an explicit policy check, so a similar-enough query surfaces a record regardless of who is asking.
Stale propagation is a write that fails to reach every agent that depends on it: one agent updates a user’s shipping address while another keeps acting on the old one. The gap between a write landing and every reader seeing it is not an implementation detail to optimise away later; in a multi-agent system it becomes part of the latency budget the whole design has to account for.
Contradiction persistence is two incompatible facts both remaining retrievable with nothing marking either as superseded. Append-only stores are prone to this by construction, since nothing in the design forces a resolution, and a downstream agent reading both has no principled basis for choosing one. The single-agent version of this problem, and the mechanics for resolving it, are covered on conflicting memories; the multi-agent version adds a harder question on top, covered next.
Provenance collapse is a retrieved fact with no traceable origin: no record of which agent wrote it, from what source, or when. Without that trail, debugging a wrong answer becomes guesswork, and a system cannot demonstrate how a piece of information entered the store, only that it is currently sitting there.
Leakage is solved by scoping, covered above. The other three all reduce to one underlying question, worth asking directly: how do you resolve two agents writing conflicting memories?
Resolution
How do you resolve two agents writing conflicting memories?
Pick one of four strategies deliberately, because each makes a different tradeoff between correctness, throughput, determinism and cost, and none of them is free. This is the most actionable design decision in a multi-agent memory system, and it is usually made by accident rather than on purpose.
Last-write-wins is the default in many ad-hoc implementations, and it is the simplest to reason about right up until two agents write at nearly the same moment: if one writes “use PostgreSQL” and another writes “use MySQL,” one of those decisions is silently gone, with no record that it ever existed.
Orchestrator-mediated serialization routes every write through a supervisor that resolves conflicts before they reach the store, which fixes the silent-loss problem entirely. The cost is architectural: the orchestrator becomes a single point of failure and a throughput limit, since nothing can write without going through it.
Reducer functions define an explicit merge rule per field: list fields concatenate, counters sum, messages deduplicate by identifier. This is deterministic and easy to reason about, and it works well for structured state with a known shape. It does not extend cleanly to free-form semantic memory, where there is no schema-level rule for what the “right” merge of two conflicting sentences even means.
LLM-assisted consolidation hands that harder case to a model: given two candidate facts, it evaluates whether they are duplicates, contradictions, or a simple update, and produces a single resolved entry, reconciling something like “the deadline is Friday” with “the deadline was moved to Monday” in a way no structural rule could. The cost is that the resolution step is non-deterministic, adds latency and expense on every conflict, and introduces a new failure mode of its own: the merge can itself be wrong, and unlike a reducer function, there is no way to prove it correct in advance.
Whichever strategy resolves the conflict, the result needs to be traceable afterward, or the fix has only solved half the problem: how do you know which agent wrote a memory, and when it stopped being true?
Provenance
How do you know which agent wrote a memory, and when it stopped being true?
By making every stored memory carry a writer, a source, a timestamp and a scope as first-class fields, not as optional metadata added when someone first needs to debug something. Provenance is a governance requirement, not a logging nicety, because without it a store cannot demonstrate how a fact arrived, only that it is present.
Four scopes cover most designs: agent-local, visible only to the agent that wrote it and the safest default; team-shared, visible to a defined group working the same task; tenant-global, visible across the whole environment and the scope leakage failures usually exploit; and a restricted scope for anything explicitly policy-constrained regardless of who requests it. Every retrieval, not just the write, has to check the requesting agent against the memory’s scope; semantic similarity alone cannot enforce this, since a policy violation can be just as semantically relevant as a permitted read.
Treating memory as evolving state rather than immutable history is what closes the contradiction and staleness problems from the previous sections. Instead of a pure append-only log, each stored fact carries a creation time, an optional reference to what it superseded, and a confidence or validity marker, so a contradiction is resolved by explicit temporal ordering rather than by leaving both versions to compete at retrieval time. This is the multi-agent extension of the mechanics on conflicting memories, and the fields involved are the same ones described generally on storage backends, with agent identity added as a required column rather than an optional one.
One scenario tests all of this at once and is rarely discussed: what happens to shared memory when an agent is replaced?
Succession
What happens to shared memory when an agent is replaced?
Ownership of every memory it wrote has to transfer explicitly, or the store accumulates orphaned facts nobody is responsible for maintaining. Agents get upgraded, reconfigured, or retired, and a memory architecture that has no answer for this ages badly even if it works perfectly on day one.
If a scope or an authority model is tied to a specific agent instance rather than to a role, replacing that agent leaves its writes stranded: still present, still retrievable, and now attributed to an identity that no longer exists in the system. Whether those facts are still trustworthy is unclear, because the thing that would have kept updating or retiring them is gone.
The fix follows directly from the provenance fields above: scope memory to a role or a team rather than to an agent instance where possible, so a successor inherits both the memory and the responsibility for it. Where scoping to an instance is unavoidable, a replacement event should trigger an explicit handoff step, either reassigning ownership or flagging the predecessor’s writes for review, rather than leaving them to be silently inherited by whatever fills the role next.
With the patterns, the failure modes, the resolution strategies and the succession case all on the table, the practical question is what a design actually has to guarantee before calling itself production-ready: what should a multi-agent memory design actually guarantee?
The checklist
What should a multi-agent memory design actually guarantee?
That every read is checked against an explicit scope, every write resolves through a chosen strategy rather than an accidental one, every stored fact carries who wrote it and when, and ownership transfers when an agent does not survive the system that built it. Those four guarantees map directly onto the four failure modes above, and a design missing any one of them will eventually hit the corresponding failure in production.
It is worth being honest about the limits of tooling here. A framework or a managed memory product that advertises shared or organization-level memory is usually solving the storage-sharing problem, letting several agents read from one pool, without necessarily solving conflict authority, provenance, or policy enforcement on top of it. Checking a specific claim against what is actually documented, rather than against the pitch, is the right way to evaluate any option under consideration, including Engram and any other managed memory layer.
None of this is exotic to build once it is named. Scoping is a metadata column and a query predicate, checked in one place rather than trusted at every call site. A merge strategy is a decision written down, not left implicit in whichever code path happened to run first. Provenance is four fields on every row. What is easy to get wrong is skipping the design step entirely and discovering the four failure modes one at a time in production, which is the order most teams learn them in without meaning to.
FAQ
Frequently asked questions
The implementation questions that follow once the design pattern is chosen.
Do all agents need write access to shared memory?
No, and defaulting to full read-write access for every agent is how unauthorized leakage happens. Scope write access as narrowly as the task allows, and give read access based on role rather than granting it by default just because the store is shared.
Is a vector database enough for multi-agent memory?
It handles the storage and similarity search, not the governance. Scoping, conflict authority and provenance have to be built on top, since a vector store enforces whatever filter a query supplies but does not decide policy on its own. See vector databases for agent memory.
How do you test that memory scoping actually holds across agents?
Seed the store with memories scoped to at least two different roles or agents, then assert that a query from one role never returns a memory scoped to another. Run it on every build, since scope leakage produces no error and degrades no obvious metric.
Which merge strategy should a new multi-agent system start with?
Orchestrator-mediated serialization for most designs, since it avoids silent data loss without the added latency and non-determinism of LLM-assisted consolidation. Move to LLM-assisted merging only once genuinely semantic conflicts, not just concurrent writes, are the actual problem.
Should every agent have its own separate memory store?
Only when agents genuinely do not need each other's context, since isolation trades away coordination for safety. Most production systems land on scoped, hierarchical memory instead, sharing what needs to be shared and isolating what does not by role rather than by agent instance.
What is the cheapest first step toward safe multi-agent memory?
Add a writer, source and timestamp column to every memory row before building anything else. Provenance is inexpensive to add early and expensive to retrofit once a store already holds memories nobody can trace back to their origin.