Shared Memory for Multi-Agent Systems: Private Domains, Shared Context, and Explicit Boundaries

TL;DR

• Shared agent memory is persistent context written to a common, named memory space so multiple agents can retrieve the same project or team knowledge across sessions.
• Agent protocols such as A2A coordinate work, but A2A explicitly describes collaboration "without needing access to each other's internal state, memory, or tools." Memory needs its own substrate. A2A specification
• A practical pattern is domain-scoped memory: agents write private working memory to agent:* domains and shared context to project:* or team:* domains. Mnemoverse multi-tenant docs
• Sharing is explicit. Agents share memory by writing to common domains that other agents can read. Isolation is the default; sharing requires domain coordination. Agent framework use case

Shared agent memory is persistent context written to a common, named memory space so multiple agents can retrieve the same project or team knowledge across sessions.

That definition matters because multi-agent systems often confuse coordination with memory. A task protocol can hand work from one agent to another. It can expose capabilities. It can carry messages. It does not automatically preserve the findings, preferences, decisions, or failed attempts that agents need later.

The A2A specification makes this boundary explicit. It says agents can collaborate "without needing access to each other's internal state, memory, or tools." A2A specification

That is a good protocol property. It protects opaque execution. It also leaves a separate architecture question: where does durable, cross-agent context live?

Why multi-agent systems need shared memory

Multi-agent memory — persistent context that several agents can write, read, and govern across sessions — becomes necessary the moment agents specialize. A researcher agent gathers facts. A planner turns them into a sequence. A developer agent implements. A reviewer checks the result. If each agent keeps only session-local context, the system must keep replaying discoveries through prompts, messages, or external logs.

The SAMEP paper, arXiv:2507.10562, states the issue directly: "Current AI agent architectures suffer from ephemeral memory limitations, preventing effective collaboration and knowledge sharing across sessions and agent boundaries." SAMEP, arXiv:2507.10562

A later architecture paper, arXiv:2603.10062, frames multi-agent memory as an open problem. It calls out "cache sharing across agents and structured memory access control," says "multi-agent memory consistency … has not been formally defined," and describes MCP-level connectivity as necessary—but not sufficient. arXiv:2603.10062

That is the wedge for shared memory. It is not a replacement for agent protocols. It is the substrate that lets agents remember what protocols helped them coordinate.

Private vs shared memory

Domain-scoped memory is memory partitioned by named domains so a system can separate private agent context from shared project, team, or tenant context.

The useful split is simple:

• private working memory for each agent;
• shared project or team memory for coordinated work;
• a broader tenant boundary for organization-level isolation.

The Mnemoverse multi-tenant documentation describes this pattern under multi-agent memory isolation. Each agent writes private working memory to its own domain, such as agent:researcher or agent:writer. Shared context goes to project:* or team:* domains that all participating agents read. Multi-tenant memory docs

That gives agents different scopes for different kinds of knowledge.

A researcher might store intermediate notes in agent:researcher. A writer might store drafting preferences in agent:writer. Both can write accepted project facts to project:acme, if that is the shared project domain. The shared domain is not a side effect of two agents existing in the same application. It is a named coordination point.

The key rule is:

Agents share memory by writing to common domains — project:*, team:* — that other agents can read. Isolation is the default; sharing requires explicit domain coordination.

This rule prevents a common failure mode. Developers sometimes expect multi-agent memory to act like automatic telepathy. That is not the documented pattern. Agents must be pointed at a shared domain.

How agents share memory

A shared-memory design needs two paths: write paths and read paths.

The write path decides which facts belong to private working memory and which facts should become shared context. The read path decides which domains an agent checks, and in what order.

The Mnemoverse documentation gives a hierarchical read order: own → project → team → tenant. Multi-tenant memory docs

That order keeps private context local while still allowing broader context to inform work. An agent can first consult its own memory, then project memory, then team memory, then tenant memory. The hierarchy also avoids treating every memory as equally relevant.

A minimal SDK-shaped example looks like this:

from mnemoverse import MnemoClient

client = MnemoClient(api_key="...")

# Private working memory for the researcher agent.
client.write(
    "The customer prefers short implementation notes with explicit tradeoffs.",
    domain="agent:researcher",
)

# Shared project context for other participating agents.
client.write(
    "The API integration should prioritize explicit error handling.",
    domain="project:acme",
)

# A developer agent can read from the shared project domain.
results = client.read(
    query="What project constraints should guide the integration?",
    domain="project:acme",
)

The method shapes shown here follow the documented SDK surface: MnemoClient, write(text, domain="agent:researcher"), read(query, domain="project:acme"), and feedback calls shaped as feedback(atom_ids=[...], outcome=..., query_concepts=...).

The important part is not the syntax. It is the boundary. The researcher's private domain does not automatically become the developer's memory. The shared project:* domain does.

The agent framework documentation says this directly in its FAQ: "Yes. Point them at the same domain…" It also states that "any agent's findings become available to the others — a researcher agent's discovery is readable by a developer agent later." Agent framework use case

Isolation & boundaries

Shared memory only works if isolation remains explicit. Without isolation, a shared-memory system becomes a leakage risk. Without sharing, it becomes a set of isolated notebooks.

The documented Mnemoverse security boundary is organization-scoped. The security documentation states: "Every API key is bound to a unique organization_id. All database queries are scoped to your organization. There is no way to access another tenant's data." It also states: "No cross-tenant learning. Hebbian associations and valence updates are per-tenant." Security docs

That gives three practical boundaries.

First, shared memory is not cross-organization federation. The documented model scopes queries to an organization. It does not describe cross-API-key or cross-org shared memory.

Second, shared memory is not automatic agent-to-agent propagation. The agent framework docs describe sharing by pointing agents at the same domain. Agent framework use case

Third, shared memory is not a cross-domain single query. The documented read model is hierarchical: own → project → team → tenant. Multi-tenant memory docs

These boundaries are useful for engineering. They make behavior reviewable. They also force the application designer to decide which observations become shared memory and which remain private working context.

The multi-tenant documentation says the same API and domain model scales from two agents to hundreds of agents without an architectural change. Multi-tenant memory docs The mechanism stays the same: private domains for agent-local work, shared domains for coordinated context, and tenant boundaries for organization isolation.

Memory vs A2A/MCP

The boundary here is simple: coordination protocols move work; a memory substrate persists context.

A2A sits on the coordination side of that line. Its specification says agents collaborate without requiring access to each other's internal state, memory, or tools. A2A specification That is a strong reason not to treat A2A as shared memory.

MCP belongs in the integration conversation rather than the memory-substrate conversation. For a narrower discussion of memory exposed through MCP, see Memory MCP. For the protocol comparison, see A2A vs MCP. For the A2A-specific background, see A2A Protocol Explained.

The clean architecture is not "A2A or memory." It is:

1. use protocols to coordinate agent work;
2. use memory domains to persist context;
3. use explicit read and write policy to control sharing.

That split matches the concern in arXiv:2603.10062 that MCP-level context I/O is necessary—but not sufficient when the problem includes cache sharing, structured memory access control, and unresolved multi-agent memory consistency. arXiv:2603.10062

A practical implementation checklist

Use this checklist when designing shared memory for AI agents:

1. Name the private domains. Give each agent a private working-memory domain, such as agent:researcher or agent:writer. Multi-tenant memory docs

2. Name the shared domains. Decide which project or team domains agents can read, such as project:* or team:*. Multi-tenant memory docs

3. Write shared facts intentionally. Do not assume that one agent's private memory becomes another agent's context. The documented pattern requires pointing agents at the same domain. Agent framework use case

4. Read hierarchically. Use the documented order: own → project → team → tenant. Multi-tenant memory docs

5. Keep tenant isolation separate from agent sharing. Organization isolation is enforced through API-key scoping, and learning updates are per-tenant. Security docs

6. Treat protocols and memory as different layers of responsibility. A2A coordinates agents without requiring access to internal memory. Shared memory persists cross-agent context. A2A specification

Mnemoverse's documented pattern is one concrete implementation of this design. The API overview is the right entry point for connection details, while the multi-tenant and agent-framework docs describe the domain model used for shared multi-agent memory. API overview

Common questions

Do AI agents share memory?

They can share memory when the system gives them an explicit shared substrate. In the domain pattern, agents write private working memory to agent domains and shared context to project or team domains that other agents can read.

What is shared memory for AI agents?

Shared memory for AI agents is persistent context written to a common, named memory space so multiple agents can retrieve the same project or team knowledge across sessions.

How is multi-agent memory different from A2A?

A2A coordinates collaboration while preserving opaque execution; its specification says agents collaborate without needing access to each other's internal state, memory, or tools. Shared memory is a separate substrate for persisted context.

How do private and shared agent memory domains work?

Each agent writes private working memory to its own domain, such as agent:researcher or agent:writer. Shared context goes to project:* or team:* domains that participating agents read explicitly.

Can one query read every memory domain at once?

Not in the documented Mnemoverse pattern. Reads follow a hierarchy from own domain to project, team, and tenant domains rather than a cross-domain single query.

Does shared memory mean cross-tenant learning?

No. The documented security boundary states that every API key is bound to an organization, all database queries are scoped to that organization, and Hebbian associations and valence updates are per-tenant.

Related

• A2A Protocol Explained
• A2A vs MCP
• A2A Integration How-To (Python)
• Multi-tenant memory and domains
• Agent framework memory use cases
• Memory MCP
• Mnemoverse API overview

---

Mnemoverse Library — persistent memory for AI agents. Written by Edward Izgorodin.