How should agents share memory across a team?

When several agents work as one team, some knowledge should travel. Cue changes, corrected procedures, and hard-won tool lessons help every specialist on the next run. Shared memory is how that transfer happens without forcing every agent to live inside one giant prompt. The hard part is sharing on purpose. An ungoverned common pile invites leakage, stale facts, and contradictory advice. This chapter explains what shared team memory is for, where it fails, and how Weaviate Engram models trusted sharing with project-wide topics, groups, and deliberate search.

What Counts as Shared Memory for an Agent Team?

Shared team memory is not “paste the whole transcript into every agent.” It is a durable store of facts and procedures that multiple agents are allowed to read, and sometimes write, under the same trust boundary. Classic blackboard systems used a similar idea. Agents posted intermediate results to a common board. Others contributed when they could help. Modern LLM teams need the same pattern, but with retrieval instead of one infinite document.

Good candidates for sharing are operational. House rules. Tool recipes that stopped failing. Constraints that apply to every role on the job. Bad candidates are private user preferences, secrets tied to one person, and raw intermediate chatter that was never cleaned into a lesson.

The point of sharing is collective improvement. One agent discovers a better filter. The next agent should not rediscover it from scratch. That only works if the lesson is stored outside any single context window and made visible to the roles that need it.

Why Does Naive Sharing Break Teams Instead of Helping Them?

If every agent can dump everything into one bag, four failures show up quickly. Unauthorized leakage moves private details into a channel other agents should never see. Stale propagation keeps an old plan alive after a better one exists. Contradiction persistence leaves two opposing “truths” equally retrieveable. Provenance collapse makes it unclear who wrote a fact and whether it was verified.

Broadcast-style coordination makes those failures worse. Re-sending the full shared state to every agent on every step multiplies cost. It also increases the chance that a specialist overfits to noise that was never meant for its role. Shared memory needs governance: what may be written, what may be read, and when a newer memory supersedes an older one.

Trust boundaries matter as much as retrieval quality. Project-wide sharing is appropriate inside a trusted operations team. It is dangerous when untrusted users can poison agent behavior for everyone else. Engram supports both modes by scoping topics as project-wide or user-scoped. The product chooses which lessons are allowed to compound across the fleet.

How Does Weaviate Engram Model Trusted Shared Memory?

Weaviate Engram treats shared operational memory as a first-class configuration choice. A continual_learning group can hold project-wide topics that need no user_id. Any agent in that project can search those memories and benefit from team experience. A separate personalization group can keep user-scoped facts isolated. Groups themselves are isolated with multi-tenancy, so personalization configuration does not collide with team learning configuration.

Topics decide what gets extracted into the shared pool. That is the content filter. If you only define topics for procedures and verified experience, casual private remarks are less likely to become fleet-wide memory. Transforms can further merge fragments from multiple agents into one clean experience record before commit, so the shared store receives lessons rather than raw debate.

Property scopes add a middle layer when “everyone in the project” is too wide. A show_id or shift_id can keep shared memories local to one production without making them private to a single agent. Agents on that show share. Agents on another show do not, unless you intentionally search across properties.

What Does Shared Write-and-Read Look Like Across Specialist Agents?

Consider a live-concert AV crew for Hall B. A lighting agent and a front-of-house audio agent run in separate contexts. Both need the same house rules about changeover timing. Neither should need the other’s full tool trace. Shared memory carries the show bible. Role-specific working notes stay out of that pool.

Here is a Weaviate Engram pattern where either specialist can contribute a scrubbed operational lesson, and both can retrieve it on the next cue:

from engram import EngramClient, HybridRetrieval

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
show_id = "venue-hall-b-sat"

# Lighting agent writes a team lesson after a failed changeover.
client.memories.add(
    "For Hall B changeovers, hold house lights at 30 percent until FOH confirms line check complete.",
    group="continual_learning",
    properties={"show_id": show_id},
)

# FOH audio agent writes another shared constraint from the same show.
client.memories.add(
    "Do not unmute festival mics until stage manager calls places on channel 2.",
    group="continual_learning",
    properties={"show_id": show_id},
)

# Either agent retrieves shared show memory without a user_id.
shared = client.memories.search(
    query="What are the Hall B changeover and unmute rules?",
    group="continual_learning",
    properties={"show_id": show_id},
    retrieval_config=HybridRetrieval(limit=5),
)

No user_id appears because these topics are project-wide within the continual-learning group. The show_id keeps the shared board tied to this production. A later Saturday crew inherits the lesson without replaying Friday’s private chatter.

How Should Teams Decide What Enters the Shared Store?

Shared writes should pass a promotion gate. Ask whether the fact helps every trusted role on the job. Ask whether it still makes sense with personal identifiers removed. Ask whether a newer correction should replace it. If the answer is no, keep the note in a narrower store or discard it.

Reads should be selective too. Not every agent needs every shared memory on every turn. Search with a task query. Optionally filter by show, shift, or case. Prefer a small set of high-value procedures over dumping the whole board into the prompt. Shared memory is infrastructure for coordination, not a substitute for role-appropriate context.

Over time, measure whether sharing actually helps. Look for fewer repeated mistakes across agents, less re-explanation between specialists, and clearer ownership when a bad lesson must be corrected. Shared memory that cannot be audited will eventually be distrusted, and teams will fall back to brittle message passing.

Sharing across a team is only half the design. Different roles still need different partitions so specialists are not drowning in each other’s details. Our next chapter, How do you partition memory by agent role?, covers how to split memory so each role sees what it needs and little else.