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

A survey of MCP memory servers published on 5 November 2026 found that most multi-agent memory products provide a shared store but not a full shared space with invited membership, revocation and server-recorded authorship. The comparison of Zep, Mem0 Platform, Letta, Supermemory, Basic Memory Teams, Cognee, Claude Managed Agents, TextForAgents, Hindsight Cloud and Mnemoverse found that author attribution is typically taken from the caller's request or configuration rather than from an identity boundary, and that revocation stops future calls but leaves existing writes in place.

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. 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 https://github.com/modelcontextprotocol/servers/tree/main/src/memory : "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 https://forum.cursor.com/t/memkernel-shared-branchable-memory-for-cursor-and-other-coding-agents/175026/9 : "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 https://www.reddit.com/r/AI Agents/comments/1xed0l7/how do you manage agent memory in teams/19rlcow8u74n7/ on r/AI Agents, read from the thread's RSS feed: "can agents overwrite each other's?" A guide by datamcp https://datamcp.app/blog/multi-agent-memory , an agent memory vendor, draws the same line: "Treat session names as organization metadata unless the system implements a separate identity boundary." | System | Shared thing | Who joins, and how | Revocation | Author on a write | Conflicting or bad writes | |---|---|---|---|---|---| | Zep https://help.getzep.com/v4/context-mcp-server Context MCP Server | Shared Context Graphs for an account, project or organization | End users who sign in through your identity provider, each with a short-lived token; shared graphs project-wide by default, UserGroup ABAC on Enterprise | Remove the user from the UserGroup or detach the policy; applies to the next operation | Not described; the token fixes which memory a connection reaches | Zep attempts to invalidate a fact that later information contradicts; valid at and invalid at keep its history facts https://help.getzep.com/v4/facts | | Mem0 Platform https://docs.mem0.ai/api-reference/organizations-projects | Organization projects; memories scoped by user id, agent id and run id | Project members as READER or OWNER; a project API key | Removing a project member revokes their access to its memories remove member https://docs.mem0.ai/api-reference/project/remove-project-member | Organization and project from the key; user id and agent id from each call | Dream marks an older fact outdated when a newer one contradicts it, in each user's memories, on all plans Dream https://docs.mem0.ai/platform/features/dream ; MCP tools overwrite by ID and bulk-delete in scope | | Letta https://docs.letta.com/concepts/shared-memory | Git repositories owned by the organization, for cloud-hosted agents | Collaborators by invitation link, Editors by default; a repository attached per agent | Detach the repository from an agent; the link remains until explicit detachment | A commit per file mutation; whose name it carries is not described | Commit, push, pull; a content hash precondition refuses a stale update | | Supermemory https://supermemory.ai/docs/supermemory-mcp/mcp | Spaces that teammates may read or write | Invitation link with role and access, valid seven days; keys scoped to namespaces | Disconnect an app; a revoked key gets 401, its memories stay | Not described | An update creates a new version and keeps the original API https://supermemory.ai/docs/api-reference/content-management/update-a-memory-creates-new-version ; writable scoped keys can update, delete and forget | | Basic Memory Teams https://docs.basicmemory.com/teams/about | A team workspace with its own isolated database and storage | Email invitation; roles at or below the inviter's; invite-only projects | Deactivation removes access; authored history stays | Changes by teammates and agents in the Activity feed | File history to step back and merge; a restore is a new version | | Cognee https://docs.cognee.ai/core-concepts/multi-user-mode/data-isolation-and-multi-tenancy , multi-user mode | Datasets owned by users | Read, write, share or delete permission per dataset, checked on every read and write | Users removed from the tenant by manage users; capabilities revoked separately; removing a dataset grant not described | Dataset owners; grants record who made them | Remembering and forgetting scoped to the dataset | | Claude Managed Agents https://platform.claude.com/docs/en/managed-agents/memory memory stores, a platform layer, not MCP | Stores attached to sessions | read write by default, or read only | Archiving makes a store read-only and blocks new attachments; detaching from a session not described | Versions attributed to the session | A prompt injection warning; versions to audit, restore and redact | | TextForAgents https://textforagents.com/products/shared-team-agent-memory/ | Project-scoped memory for agent teams | An operator token | Not described | From the token, never from request fields | Contradictory writes both marked contested, nothing overwritten | | Mnemoverse rooms https://mnemoverse.com/docs/api/rooms | A memory space shared across accounts | An invite code, at the read or read write scope the owner set | Immediate and forward-only; written atoms stay | Provenance when authorship was recorded; an author object ignored on API-key calls | A read-scope member cannot change anything | | LangGraph store https://docs.langchain.com/langsmith/store-auth , LangSmith Deployment | Namespaces your application defines | Shared across all callers by default; an @auth.on.store handler you write scopes them | Not described | Not described | Not described | | CrewAI https://docs.crewai.com/en/concepts/memory | The crew's memory, unless an agent has its own | The agents of the crew | Not described | A source tag set by the caller | A model may delete a record it judges contradicted; LanceDB writes under a lock | | agentmemory https://github.com/rohitg00/agentmemory | One server, in shared or isolated mode | Configuration; the REST API binds to 127.0.0.1 by default | Not described | AGENT ID, or an agentId request field that wins over it | Contradictions detected and resolved; superseded versions leave search, the version chain keeps history; exclusive action leases | | mcp-memory-service https://github.com/doobidoo/mcp-memory-service | Memory shared across all agents and runs | OAuth 2.0 for remote clients; the server binds to 127.0.0.1 by default | Not described | An X-Agent-ID header becomes a tag | Heuristic contradiction detection can mark older memories superseded; typed edges include contradicts | | MCP reference memory server https://github.com/modelcontextprotocol/servers/tree/main/src/memory | One knowledge graph file | Any process configured with that file | Not covered in the README | Not covered in the README | Writes take turns under a lock | | Hindsight https://hindsight.vectorize.io/developer/mcp-server | A bank per MCP endpoint; a shared bank that the client merges llms.txt https://hindsight.vectorize.io/llms.txt | Self-hosted: open by default until the API key tenant extension is enabled; Hindsight Cloud: team invitations with role-based access Cloud https://hindsight.vectorize.io/cloud-enterprise/hindsight-cloud | Cloud API keys revoked by deleting them CLI https://hindsight.vectorize.io/developer/admin-cli | Not described | Observations track contradictions with temporal markers rather than overwriting the prior belief configuration https://hindsight.vectorize.io/developer/configuration | 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 https://help.getzep.com/v4/context-mcp-server/standalone-graph-authorization and graphs https://help.getzep.com/v4/create-graph ; Mem0 members https://docs.mem0.ai/api-reference/project/add-project-member , group chat https://docs.mem0.ai/platform/features/group-chat , Supabase https://docs.mem0.ai/cookbooks/integrations/supabase and MCP https://docs.mem0.ai/platform/mem0-mcp ; Letta repositories https://docs.letta.com/agent-sdk/repositories , permissions https://docs.letta.com/teams/permissions and collaborators https://docs.letta.com/teams/collaborators ; Supermemory invitations https://supermemory.ai/docs/invite-team-members and keys https://supermemory.ai/docs/authentication ; Basic Memory roles https://docs.basicmemory.com/teams/members-and-roles , projects https://docs.basicmemory.com/teams/team-projects and history https://docs.basicmemory.com/cloud/file-history ; Cognee permissions https://docs.cognee.ai/core-concepts/multi-user-mode/permissions-system/overview and provenance https://docs.cognee.ai/guides/memory-provenance ; Mnemoverse API reference https://mnemoverse.com/docs/api/reference . Two rows depend on a mode. With access control off, Cognee's isolation page https://docs.cognee.ai/core-concepts/multi-user-mode/data-isolation-and-multi-tenancy 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 https://docs.langchain.com/langsmith/store-auth : "By default, store namespaces are shared across all callers." The Mnemoverse row is covered in detail in an earlier article https://dev.to/izgorodin/how-to-maintain-session-knowledge-across-a-fleet-of-specialized-developer-bots-m8m . 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 https://docs.mem0.ai/platform/features/group-chat : "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 https://docs.mem0.ai/cookbooks/integrations/supabase : "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 https://github.com/doobidoo/mcp-memory-service . The agentmemory README https://github.com/rohitg00/agentmemory : "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 https://docs.crewai.com/en/concepts/memory : "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 https://help.getzep.com/v4/graphiti/core-concepts/graph-namespacing gives the general rule: "A namespace filter does not replace application authorization." Two systems say that the author comes from the authenticated identity. TextForAgents https://textforagents.com/products/shared-team-agent-memory/ : "Your token IS your identity: operator attribution and admin rights derive from the token, never from request fields." Anthropic, for Managed Agents memory stores https://platform.claude.com/docs/en/managed-agents/memory : "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 https://mnemoverse.com/docs/api/rooms , and on a read, provenance is "Present whenever authorship was recorded" API reference https://mnemoverse.com/docs/api/reference . The Reddit user Emotional-Ad8388, in a comment of 25 October 2026 https://www.reddit.com/r/AI Agents/comments/1xed0l7/how do you manage agent memory in teams/19rmyq6k5wmyo/ 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 https://dev.to/izgorodin/your-agent-memory-records-when-four-older-fields-already-solved-who-4gmk . Three different things. In ElizaOS, a room is the conversation a memory belongs to: the Memory and State page https://docs.elizaos.ai/agents/memory-and-state 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 https://registry.modelcontextprotocol.io/v0/servers?search=memory&version=latest&limit=100 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 https://github.com/Holetron-lab/fleet-memory , although a heading in the same README calls them "topic isolation". In Mnemoverse, per its rooms documentation https://mnemoverse.com/docs/api/rooms : "A room is a memory space shared across Mnemoverse accounts." On 5 November 2026 at 15:47 UTC the official MCP registry https://registry.modelcontextprotocol.io/v0/servers?search=memory&version=latest&limit=100 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. 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 https://help.getzep.com/v4/context-mcp-server/standalone-graph-authorization : "Membership removal, policy detachment, policy updates, and mode changes affect the next MCP operation." Supermemory's authentication page https://supermemory.ai/docs/authentication , 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 https://docs.basicmemory.com/teams/members-and-roles : deactivating a member "removes their access and frees their place. Their authored history stays intact." Mnemoverse rooms, per the rooms documentation https://mnemoverse.com/docs/api/rooms : "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. Races. The reference server's README https://github.com/modelcontextprotocol/servers/tree/main/src/memory : "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 https://docs.letta.com/concepts/shared-memory : "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 https://dev.to/izgorodin/two-clients-wrote-the-same-memory-which-write-survived-and-did-the-loser-find-out-khe . Contradictions. TextForAgents https://textforagents.com/products/shared-team-agent-memory/ : "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 https://docs.crewai.com/en/concepts/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 https://github.com/doobidoo/mcp-memory-service , "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 https://docs.basicmemory.com/teams/about : "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 https://platform.claude.com/docs/en/managed-agents/memory 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 https://platform.claude.com/docs/en/managed-agents/memory : "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 https://github.com/Holetron-lab/fleet-memory gives the same advice for its server: "if you expose this server to anything untrusted, expose memory recall alone." Commons https://github.com/Neoo-Blue/commons-memory , 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 https://www.reddit.com/r/AI Agents/comments/1xed0l7/how do you manage agent memory in teams/19rldibjva4ow/ : "when a decision changes, how do you find which agent chats still carry the old version?" The answer from ericoinen https://www.reddit.com/r/AI Agents/comments/1xed0l7/how do you manage agent memory in teams/19rlgt8w5t1dx/ : "decisions sit in one markdown table with an id, who said it, which projects it binds and whether it stands." And from QuanTradin https://www.reddit.com/r/AI Agents/comments/1xed0l7/how do you manage agent memory in teams/19rlvjlw50i80/ : "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. Six questions, each settled by a test. 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 https://mnemoverse.com/docs/library/shared-memory-poisoning . Edward Izgorodin · Mnemoverse · 2026-11-05