I have been thinking about what happens when several agents share the same memory.
The obvious version is a database they can all read and write. A coding agent saves a useful pattern. A browser agent adds research. A personal agent records a decision. The next agent opens the workspace and starts with everything the others learned.
That sounds powerful until two agents disagree.
One agent marks a component as the preferred version. Another replaces it after a failed run. A third saves a summary without seeing the original decision. If every write has equal authority, the shared memory slowly becomes a pile of confident contradictions.
The difficult part of multi-agent memory is not storage. It is deciding what gets to become true.
Shared memory creates a merge problem
Developers already know this problem from Git. Many people can work on the same codebase because changes have authors, diffs and a path to merge. We do not let every branch silently rewrite main.
Agent memory needs the same basic discipline.
A useful memory entry should keep its source, the agent that proposed it, the work that produced it and the decision that accepted it. When something changes, the system should preserve the old version long enough to explain what happened.
Without that history, an agent cannot tell the difference between a tested decision and a guess saved five minutes ago.
This matters more as agents move beyond code. A coding agent may know that an integration failed for a specific technical reason. A browser agent may later see updated documentation and conclude that the old limitation is gone. Both observations can be valid at the time they were made. Replacing one sentence with the other throws away the part that makes the knowledge useful.
The memory needs to carry the change, not only the latest text.
One agent should hold merge authority
My current view is that a shared workspace needs a primary agent. That agent does not need to do every task. It needs to decide what becomes part of the durable memory.
Other agents can propose additions and corrections. They can attach evidence, point out stale knowledge and suggest that an asset should be replaced. The primary agent can accept, reject or ask for more context.
This gives the workspace a clear authority model. A temporary agent used for one task cannot silently rewrite a decision that every other agent will trust tomorrow.
The human still sits above the system. They can pin a decision, change which agent has authority or inspect why something was accepted. The point is to make those boundaries visible instead of pretending all agent output deserves the same weight.
Silent self-editing is especially dangerous here. If an agent can change its own instructions or the shared memory after a failed run, it may improve. It may also erase the evidence of why it failed. Proposed changes should be reviewable events, even when another agent handles the review automatically.
Memory should become more trusted as it is used
A good shared memory should learn from reuse.
If an asset is saved, retrieved and used successfully across several projects, that is evidence. If agents keep pulling it and then rewriting it, that is evidence too. Usage can tell the primary agent which parts of the library are stable and which need attention.
This is more useful than treating every saved item as permanent. Some knowledge should expire. Some should be tied to a version, environment or client. Some should remain a proposal until it has survived real work.
The library becomes valuable because it records decisions and their outcomes. More agents writing to it should increase that value, as long as they cannot quietly overwrite one another.
I still think agents need a shared place for the work we leave behind. I just no longer think shared access is enough.
The next step is shared memory with authorship, diffs and merge authority. Otherwise we are giving every agent a notebook and letting each one erase the previous page.
Top comments (0)