What MCP memory servers support shared memory rooms for multi-agent collaboration?

Several MCP memory servers and memory layers let more than one agent use the same memory, but fewer document a shared space in the full sense: members who are invited, access that can be revoked, and an author on each write that the server takes from the writer's identity. On 5 November 2026, Zep, Mem0 Platform, Letta, Supermemory, Basic Memory Teams, Cognee in multi-user mode, Claude Managed Agents, TextForAgents, Hindsight Cloud and Mnemoverse (the author's company) each document some of these properties, and no two document them the same way. The MCP reference memory server, mcp-memory-service, agentmemory, CrewAI, LangGraph and self-hosted Hindsight give several agents one store, and the pages read leave who may write, and under which name, to configuration, to a request field or to your own code.

TL;DR

• A shared store is not yet a shared space. Several agents reaching one file, server or namespace is a shared store; a space adds invited members, revocation and an author on each write that the server sets.
• The author often comes from the caller. Mem0, CrewAI, agentmemory and mcp-memory-service take it from the call or its configuration; TextForAgents and Claude Managed Agents take it from the token or the session.
• A room is not a standard. It is a conversation in ElizaOS, a topic filter in RCLL fleet-memory and a membership pool in Mnemoverse.
• Revocation stops the next call, not the past. Where the pages say what happens to the data, writes stay after access ends, so removing a bad write depends on knowing who made it.

Mnemoverse makes a memory API for agents; its rooms are one row of the table below, taken from its public documentation like every other row.

What is the difference between a shared store and a shared space?

A shared store is a memory that several agents reach because they are pointed at the same file, server, key or namespace. A shared space is a shared store with a membership of its own: an identity is invited in and can be revoked, and each write it makes carries an author that the server records from that identity, not from what the caller puts in the request.

The MCP reference server is the plain shared store. Its README: "Each MCP client starts its own server process, so two clients using the same MEMORY_FILE_PATH (or both using the default) are two processes writing one file."

That is enough for two agents of one developer, not for writers who belong to different people or vendors. Bridger Pennington, in a Cursor forum post of 21 October 2026: "a shared space both can write to sounds cool but i'd only trust it if i could tell who wrote what". The Reddit user London-Boat asked the other half in a comment of 24 October 2026 on r/AI_Agents, read from the thread's RSS feed: "can agents overwrite each other's?" A guide by datamcp, an agent memory vendor, draws the same line: "Treat session names as organization metadata unless the system implements a separate identity boundary."

Which MCP memory servers and memory layers offer a shared space today?

Read on 5 November 2026 from the pages linked in each row and below; not a test. Not described means the pages read do not describe that point, not that the product lacks it.

Also read for the rows: Zep authorization and graphs; Mem0 members, group chat, Supabase and MCP; Letta repositories, permissions and collaborators; Supermemory invitations and keys; Basic Memory roles, projects and history; Cognee permissions and provenance; Mnemoverse API reference.

Two rows depend on a mode. With access control off, Cognee's isolation page says "all datasets share one store and datasets/dataset_ids filters are ignored". The open default of LangGraph is that of LangSmith Deployment, per its store authorization page: "By default, store namespaces are shared across all callers." The Mnemoverse row is covered in detail in an earlier article.

Where does the author of a shared write come from?

Four systems in the table say that it comes from the caller: Mem0, mcp-memory-service, agentmemory and CrewAI. That is a design choice, not an oversight. Mem0's Group Chat page: "You control which speaker a memory belongs to by scoping each add() call with user_id, agent_id, and run_id; Mem0 does not infer that scope automatically from the conversation." The account level is Mem0's own, per its Supabase cookbook: "The key is scoped to your org and project; Mem0 resolves both server-side, so you never pass IDs by hand."

mcp-memory-service tags a memory with the agent named in an X-Agent-ID header, "which a tag search then scopes retrieval by" (README). The agentmemory README: "AGENT_ID tags every write with the role that made it.", and its REST API "accepts an agentId field in the request body that wins over the env." CrewAI's memory page: "Every memory record can carry a source tag for provenance tracking and a private flag for access control."

When one trusted application makes every call, the caller is the right party to name the agent. When agents of several people or vendors share the memory, a name that the caller writes is a claim any writer can make; that is this article's reasoning, not a vendor statement or a demonstrated attack. Zep's Graphiti page gives the general rule: "A namespace filter does not replace application authorization."

Two systems say that the author comes from the authenticated identity. TextForAgents: "Your token IS your identity: operator attribution and admin rights derive from the token, never from request fields." Anthropic, for Managed Agents memory stores: "writes to a read_write mount produce memory versions attributed to the session." Mnemoverse rooms document two related lines: in a write, an author object is "honored only for service integrations and ignored on API-key calls" (rooms), and on a read, provenance is "Present whenever authorship was recorded" (API reference).

The Reddit user Emotional-Ad8388, in a comment of 25 October 2026 read from the thread's RSS feed, on what a missing author does to the reader: "A line like 'we decided X' with no author makes the agent treat a teammate's suggestion as a settled decision". The fields that answer who wrote a record are the subject of an earlier article on provenance.

What does a room mean in each system?

Three different things. In ElizaOS, a room is the conversation a memory belongs to: the Memory and State page lists roomId: UUID; // Conversation context beside entityId: UUID; // Who created this memory (user/agent).

In RCLL fleet-memory, a fork of Hindsight that the MCP registry lists as "Self-hosted shared memory for a team of AI agents.", rooms are "topic scoping over one shared store, which is selectivity rather than isolation" (README), although a heading in the same README calls them "topic isolation".

In Mnemoverse, per its rooms documentation: "A room is a memory space shared across Mnemoverse accounts."

On 5 November 2026 at 15:47 UTC the official MCP registry returned 317 entries (latest versions) with memory in the name; the self-written descriptions of 41 of them mention shared, share, team, room, workspace or cross-agent, and two use the word room: RCLL fleet-memory and the Mnemoverse server. The count measures vocabulary, not features, and misses servers without memory in the name, Mem0's among them. What decides is who may join, who can remove a member, and where the author comes from.

What happens to a write after access is revoked?

Where the pages describe it, revocation acts on the next request, and the pages that say what happens to the data keep the writes. Zep's graph authorization page: "Membership removal, policy detachment, policy updates, and mode changes affect the next MCP operation." Supermemory's authentication page, for a key: "Revoke with the id from creation. Subsequent requests get 401. Memories and namespaces are not deleted." Basic Memory's Members and Roles: deactivating a member "removes their access and frees their place. Their authored history stays intact." Mnemoverse rooms, per the rooms documentation: "Revocation is immediate and forward-only."

Keeping the writes is reasonable, but it means that revocation cannot remove a bad write: that takes finding it, and finding one member's writes takes the author on each write.

What do the docs say about conflicting or bad writes?

Races. The reference server's README: "A write that cannot get the lock within 60 seconds fails with a tool error rather than overwriting the file." Letta's repositories are Git, per its shared memory page: "The agent must commit and push its changes. Other agents can then pull those commits into their own checkouts." Preconditions on a content hash, which Letta and Anthropic both document, are covered in an earlier article on which of two writes survives.

Contradictions. TextForAgents: "contradictory decision/finding writes mark BOTH records contested; nothing is overwritten", and "records derived from a retracted record become stale_derived and drop out of search/briefs". In CrewAI's memory consolidation, "the LLM decides what to do", and one documented outcome is to delete a record when "The existing record is outdated, superseded, or contradicted." Which agent's record it picks in a crew is not described in the pages read. mcp-memory-service records the relation as a "Knowledge graph with typed edges (causes, fixes, contradicts)", and per the same README, "Heuristic contradiction detection can mark older memories as superseded, hiding them from default retrieval while retaining them for explicit lookup."

Stepping back. Basic Memory's team page: "If a teammate overwrites something or an agent edits go sideways, open File history on the note to step back through the timeline, compare any version against the current one, and merge content back in." Anthropic's memory page offers version endpoints "to audit who changed what and when, to inspect or restore a prior snapshot", and past versions there "might be deleted after 30 days".

Keeping bad content out. Anthropic names the path on the same memory page: "If the agent processes untrusted input (user-supplied prompts, fetched web content, or third-party tool output), a successful prompt injection could write malicious content into the store. Later sessions then read that content as trusted memory." Its advice: "Use read_only for reference material, shared lookups, and any store the agent does not need to modify." The RCLL README gives the same advice for its server: "if you expose this server to anything untrusted, expose memory_recall alone." Commons, a shared memory for parallel coding sessions, says "Upstream output is fenced as untrusted".

Practitioners build these properties by hand. On r/AI_Agents, read from the thread's RSS feed, Ctbhatia asked on 24 October 2026: "when a decision changes, how do you find which agent chats still carry the old version?" The answer from ericoinen: "decisions sit in one markdown table with an id, who said it, which projects it binds and whether it stands." And from QuanTradin: "nobody's agent writes to it directly, changes go through a PR." That is membership, authorship and history, built from a repository and a review.

What should a team check before trusting a shared space?

Six questions, each settled by a test.

1. Who can write before anyone changes a setting? Start from the default, not from the setting you plan: Anthropic's memory stores "attach with read_write access by default" (memory), and on self-hosted Hindsight "By default, the MCP endpoint is open (no authentication required)." (MCP server).
2. Where does the author come from? Write with an author field that names someone else, read the write back, and see which name was recorded.
3. What does revocation leave? Revoke a test member, confirm that its next call is refused and that its earlier writes still carry its name.
4. Can one member's writes be found and removed? Filter or list by author, then delete or retract what that member wrote. If neither is possible, a bad write cannot be told from good ones.
5. What happens to a contradiction? Write two conflicting decisions from two members and see whether both survive, one replaces the other, or a model chooses.
6. Control. Call the space from an identity that was never invited. It must be refused; if it is not, the other five tests describe a shared store, not a space.

What this article does not claim

It tests no product and ranks none. Each row and quotation comes from the pages linked beside it, as read on 5 November 2026; not described means only that the pages read do not describe that point, and what a vendor documents elsewhere is not covered. The registry counts go by names and self-written descriptions on one day. The Reddit and forum lines are individual reports, each with its date. The six checks are a proposal, not any team's procedure.

Sources and method. Every quotation was read on 5 November 2026 with two instruments, a request with browser headers and a reader service with its cache off: vendor documentation as its Markdown export where the vendor offers one, GitHub READMEs from raw.githubusercontent.com, the forum post also as the forum's own JSON, and the Reddit comments, which the reader service does not serve, from two reads of the thread's RSS feed. A made-up address on each host answered 404 as a control; docs.crewai.com sent a made-up address to its home page with 200, so the lines from that host count only as exact matches on their own pages. The text describes those pages as of that date. How agents should consume a shared memory safely, once one is chosen, is the subject of the Mnemoverse library page Shared Memory Poisoning: One Bad Write, Many Agents.

Edward Izgorodin · Mnemoverse · 2026-11-05