Shared memory for multi-agent teams: handle a conflicting update

Two agents can read the same information and still overwrite each other’s work. Shared memory needs a rule for accepting changes, not just a place to put them.

The useful part is the handoff

A research agent collects workshop requirements. A scheduling agent checks the venue. Both contribute to the same event brief. If each keeps a private copy, a correction can be missed. If both overwrite one shared paragraph, the latest writer can erase a valid change.

Neither problem is solved by calling the storage a shared brain. A better design makes the unit of shared information, its owner and its update rule visible. This article works through a small fictional example. It describes an application design, not a built-in guarantee of every memory framework.

Start with a record both agents can inspect

The fictional event brief is record E7, version 7. It contains: room capacity required = 8; projector required = yes; venue status = unconfirmed. The research agent and scheduling agent both read version 7.

New information arrives through two different paths. The organizer tells the research agent that attendance has increased to 10. The scheduling agent receives venue details for Room Maple, which seats only eight and includes a projector.

Both updates contain useful information. They cannot both become “ready to book Maple,” because the larger attendance changes the room requirement. The risk is not merely losing text; it is accepting a conclusion based on an obsolete premise.

Make the conflict explicit

In this illustrative design, each write includes the version it was based on. The storage service accepts it only if that version still matches the current record. This comparison and update must happen as one operation; reading the version and writing later without enforcement would leave the same race.

The second agent must reconsider, not just retry

A blind retry would resubmit “ready to book Maple” against version 8. That avoids a technical version error while preserving the wrong decision. The scheduling agent has to re-evaluate the proposal using the updated facts.

The resulting version 9 now gives the next agent a useful handoff: ten attendees are expected; a projector is required; Maple is ruled out; no venue is confirmed. The brief can carry references O12 and V3 so a teammate can inspect why those fields changed.

This is a deliberately small example of optimistic concurrency. Your storage may offer conditional updates, transactions, a single writer queue or another coordination mechanism. The critical property is that stale work cannot quietly replace accepted state. Do not assume a framework provides this property merely because multiple agents can reach its store.

Share accepted facts, not every scratch note

An agent exploring venues may generate abandoned options and uncertain hypotheses. Other agents do not necessarily benefit from treating all of that as shared truth. Keep provisional working state distinguishable from the accepted brief, and label observations separately from decisions.

LangGraph provides one example of the distinction between conversation-thread state and a store accessible across threads. That storage separation can support a design, but application rules still determine what belongs in each place. LangGraph persistence

Letta documents another approach: agents attached to a shared repository can work with common files using Git operations. Repository history is useful for inspectable artifacts, while agents still need a workflow for incorporating one another’s changes. Neither shared files nor shared records eliminate the need to resolve incompatible conclusions. Letta shared memory

Sharing has costs and boundaries

A central record can make the accepted state easier to locate, but it also introduces contention and an availability dependency. Separate agent state can be simpler for independent tasks. A shared repository can suit longer research artifacts; small structured records can make individual fields and acceptance rules easier to manage.

Permission is another boundary. An agent allowed to read the event brief need not be allowed to edit it. An agent allowed to update venue research need not be allowed to reserve a venue. Decide those capabilities explicitly rather than giving every participant every tool.

Most importantly, version 9 is a memory update. It has not booked anything or changed the organizer’s source message. Source write-back and external actions are separate operations with their own authorization and confirmation. For that distinction in a complete action loop, see how an agent makes a booking decision.

Try the collision before adding more agents

Before expanding a team of agents, give two workers the same starting record and incompatible new information. Check whether one update is rejected, whether the rejected worker re-reads the accepted state, and whether the final handoff preserves the correct facts.

If you cannot explain why version 9 was accepted, adding a third agent will make the confusion harder to diagnose. Shared memory earns its place when it produces a clearer next action, not simply because more agents can see more text.

About this article

Written by the HeyBrain Editorial Team with AI assistance. The examples are fictional and illustrate design choices; they are not customer stories, product demonstrations or measured test results. Primary sources are linked beside the claims they support.