How should memory architecture work for multi-agent systems?

Multi-agent systems break the quiet assumption that made single-agent memory easy: one writer, one write gate, one assembly policy. The moment a planner, a researcher, and a reviewer all touch the same user or project, you must decide what is private scratch, what is shared truth, and who is allowed to promote a note into the shared plane. Shared memory without scopes becomes contamination. Fully isolated memory without sync becomes contradictory agents that cannot finish a joint job.

This chapter maps shared, isolated, and hybrid memory shapes onto Weaviate Engram scopes and groups, shows how organizational knowledge stays a separate authority plane even when agents multiply, outlines write and promotion rules that keep coherence without a free-for-all, and walks a pipe-organ voicing bench where specialist agents collaborate under one user. After multi-agent ownership comes another composition question: vectors plus graphs in one hybrid retrieval design.

Why do multi-agent memory problems show up as contamination and divergence?

After a solid single-agent loop, teams often clone the same Engram client into every role and call it “shared memory.” That flattens authorship. A researcher’s speculative note ranks beside a reviewer’s approved decision. A scheduler’s temporary constraint overwrites a durable user preference because both wrote under the same user_id with no agent or tier tag. Industry writing on multi-agent memory keeps returning to the same pair of failure modes. Unscoped sharing contaminates. Pure isolation diverges until agents argue past each other.

Computer-architecture analogies help without becoming literal hardware. Shared pools need visibility rules. Distributed private stores need explicit synchronization. Most production agent systems land in a hybrid: private working memory per agent, a scoped shared project or team memory for committed artifacts, and a user personalization plane that only certain roles may write. Engram fits that hybrid when you treat scopes and properties as the isolation mechanism—not when every agent runs an unfiltered hybrid search over the entire user corpus.

Multi-agent memory is therefore policy design first, storage second. The store can still be Engram. The architecture is which queries each agent may run and which writes each agent may commit.

How should Engram scopes separate private, team, and user planes?

That policy becomes concrete with scopes. Keep the human identity on user_id whenever personalization is involved. Add properties that encode agent role, memory tier, and project. A practical split looks like three Engram “lanes” under one product. Lane A is agent-private: properties.group = agent_scratch plus agent_id, used for hypotheses and tool traces that should not pollute teammates. Lane B is team-shared: properties.group = project_shared plus a project_id, used for decisions the orchestrator has accepted. Lane C is user personalization: properties.group = personalization, written only by agents explicitly allowed to update standing preferences.

Reads follow least privilege. The researcher searches lane A for its own scratch and lane B for committed project facts. It does not search other agents’ scratch. The reviewer may read lane B and propose writes to lane B, but personalization writes go through a single owner agent or a promotion step. Organizational SOPs remain outside Engram: a Weaviate collection queried with document filters, never mixed into the same top-k as scratch notes.

This is still multi-store at the contract level—private, shared, personalization, org—even when Engram hosts the first three. Hybrid architecture here means hybrid visibility, not necessarily three databases.

What write and promotion rules keep agents coherent?

Once lanes exist, define how notes move. Agents may write freely to their private scratch within size caps. Promotion to project_shared requires a gate: confidence threshold, reviewer approval, or orchestrator merge after a structured handoff. Promotion to personalization is stricter still—only durable user-stated preferences, always scoped to user_id, with supersession when the user changes their mind. Deletes and soft-forgetting apply per lane so a discarded hypothesis does not linger in shared search.

Conflict handling needs an explicit rule when two agents promote incompatible claims. Prefer timestamp plus role rank (reviewer beats researcher on decisions), or keep both with status metadata and force the orchestrator to resolve before answering the user. Do not hope hybrid search will pick the “right” contradiction. For organizational facts, neither agent may promote chat text into the SOP collection; they open a change request instead.

Logging should record agent_id on every Engram write. When a bad preference appears in production, you need to know which role authored it. Multi-agent systems that skip attribution recreate the single-agent bug with more suspects.

What does collaboration look like at a pipe organ voicing bench?

Those rules fit a small shop floor. A voicing team uses three agents for one organ builder: a tone researcher, a regulation planner, and a client-facing summarizer. They share project memory for a stop being voiced, keep private scratch for experiments, and update personalization only when the builder states a standing preference. Scenario id: pipe-organ-voicing-bench-3.

from weaviate.engram import EngramClient
from weaviate.engram.retrieval import HybridRetrieval

engram = EngramClient()
user_id = "builder-elio"
project_id = "swell-oboe-2026"
scenario = "pipe-organ-voicing-bench-3"

def search_lane(group: str, query: str, agent_id: str | None = None):
    props = {"group": group, "project_id": project_id, "scenario": scenario}
    if agent_id:
        props["agent_id"] = agent_id
    return engram.memories.search(
        query=query,
        retrieval=HybridRetrieval(alpha=0.5, limit=5),
        scopes={"user_id": user_id, "properties": props},
    )

def promote_to_shared(content: str, from_agent: str):
    # Gate: only after orchestrator accepts the handoff artifact
    engram.memories.add(
        content=content,
        scopes={
            "user_id": user_id,
            "properties": {
                "group": "project_shared",
                "project_id": project_id,
                "source_agent": from_agent,
                "scenario": scenario,
            },
        },
    )

# Researcher: private scratch + shared reads
scratch = search_lane("agent_scratch", "oboe shallot experiments", agent_id="researcher")
shared = search_lane("project_shared", "approved shallot cut decisions")

# Summarizer: may update personalization only for standing builder prefs
# engram.memories.add(..., properties={"group": "personalization", ...})

The researcher’s failed shallot cut stays in agent_scratch until the planner accepts a cut into project_shared. The summarizer can read shared decisions to brief Elio, and may write personalization when Elio says he always wants pressure notes in millimeters. SOP limits for wind pressure still come from the organizational collection, not from any agent’s Engram lane. Three agents, one user, four contracts—and no unscoped shared pile.

Multi-agent memory works when visibility is designed: private scratch, shared committed artifacts, user personalization via Engram scopes, and organizational knowledge on its own plane. Promotion beats ambient sharing; attribution beats mystery writes. Our next chapter, How do hybrid vector-plus-graph memory architectures work?, turns from agent ownership to retrieval composition—when vectors and graphs should work together in one system.