4. Team Sharing
The native CLAUDE.md provides shared static context (versioned, zero infra). For shared dynamic memory that evolves during sessions, no single dominant solution exists as of May 2026.
4.1 The Trinity: CLAUDE.md + .mcp.json + /skills
The most adopted team pattern in 2025-2026. Three files in the repo root, all versioned in Git:
<repo>/
├── CLAUDE.md # coding standards, guardrails, agent behavior
├── .mcp.json # MCP server configs (DBs, ticketing, memory servers)
└── .claude/
└── skills/ # shared workflows as markdown skillsEvery developer who clones and runs Claude Code in that repo inherits the full stack with no per-developer setup. Rules like "never modify CI files," "always run tests after changes," and "use read-only DB access" are centralized here.
CLAUDE.md best practice: keep under 2,000 words, link to details rather than embed them, prioritize signal density.
This covers shared standards and conventions with zero infrastructure. For shared dynamic memory (decisions made during sessions, context discovered by agents), you need an additional layer.
4.2 doobidoo + Cloudflare (Team Mode)
The recommended production path for teams using doobidoo is the Cloudflare backend (Vectorize + D1 + Workers AI), which requires a Cloudflare account with appropriate access enabled.
{
"mcpServers": {
"memory": {
"command": "memory",
"args": ["server"],
"env": {
"MCP_MEMORY_STORAGE_BACKEND": "hybrid",
"MCP_HTTP_ENABLED": "true",
"MCP_HTTP_PORT": "8000",
"CLOUDFLARE_API_TOKEN": "your-token",
"CLOUDFLARE_ACCOUNT_ID": "your-account-id",
"MCP_MEMORY_SQLITE_PRAGMAS": "busy_timeout=15000,cache_size=20000",
"MCP_OAUTH_ENABLED": "false"
}
}
}
}Gotchas for team deployment: SQLite shared across machines requires WAL mode configuration and the busy_timeout fix above. Sharing a plain SQLite file over a network filesystem (NFS, SMB) will corrupt the database; SQLite locking assumes local fcntl. If multiple developers write from different machines, use the Cloudflare backend. This is not free and not zero-config.
4.3 Mem0 Cloud MCP
Repo: github.com/mem0ai/mem0 | Stars: ~61.9K (full repo, 2026-07-27) | Free tier: yes
Cloud-hosted MCP server. No local installation, no infrastructure to manage. One-line setup:
npx mcp-add --name mem0-mcp --type http \
--url https://mcp.mem0.ai/mcp \
--clients "claude code,cursor,windsurf"Each team member adds the same URL to their .mcp.json. Memory scope (individual vs. shared) is controlled by user_id: use a project-scoped ID to give the team a common pool.
11 MCP tools: add_memory, search_memories, get_memories, update_memory, delete_memory, delete_all_memories, plus entity management and event tracking. Wildcards (user_id: "*") search across all users.
When to use: quickest path to working shared memory layer. Zero configuration gap between team members.
When not to use: codebases containing proprietary logic or client information. Data lives on Mem0's infrastructure, a real consideration for privacy-sensitive projects.
4.4 Zep / Graphiti
Repo: github.com/getzep/graphiti | Stars: ~29.3K (2026-07-27) | Pricing: self-hosted (Neo4j, free) or cloud ($25-$475/month)
If the requirement is not just "remember context" but "understand how context changed over time," Graphiti is the only option with a clear answer. It builds a temporal knowledge graph on top of Neo4j: nodes are entities, edges are relationships, and every edge carries a validity window. A query like "what did the team decide about the auth service in March, before the direction change in April?" is answerable. Standard semantic vector search cannot do this.
9 MCP tools. Graph traversal enables entity-centric retrieval, relationship chains, and temporal constraints.
Bitemporal modeling: the technique comes from data warehousing (Snodgrass, 1999). Every other tool in this survey treats memory as a flat snapshot; they cannot answer historical questions about superseded decisions.
Setup requires Neo4j: a full database service. Self-hosting is reasonable for teams with existing infrastructure. The cloud tier removes that constraint at $25-475/month.
4.5 Notion MCP
If your team already uses Notion, Claude can read and write pages via MCP tools (mcp__notion__*). Decisions, notes, and context are stored as human-readable pages. Zero new infrastructure, works today, has a web UI for non-Claude access.
This is Pattern B (Option 1) from the implementation patterns: no additional configuration beyond the Notion MCP server already in your .mcp.json.
4.6 Team-Native Tools (2026)
Three tools designed specifically for multi-user scenarios, all released in 2026. Insufficient community feedback for confident recommendations.
Memlord (memlord.com): self-hosted, full user isolation, shared workspaces with invite links. Multi-user is a first-class architectural feature, not a configuration option. Stars unknown, recently launched.
Pindoc (community listing, PulseMCP): "Code-pinned team memory for AI coding agents." Typed artifacts, MCP-native, self-hosting. Released April 2026. [UNVERIFIED: repo handle not independently confirmed]
Artel (NicolasPrimeau): "Self-hosted shared memory and coordination mesh for AI agent fleets, with semantic search, task management, and async coordination." Released May 2026, 7 stars as of the 2026-07-27 check (originally listed at 210 stars at launch, a drop worth flagging: treat early-listing counts on brand-new repos with caution rather than as a stable adoption signal).
Memlord has the clearest multi-user model from available information. Artel targets agent fleet coordination most directly. Neither is ready for production CC use without personal evaluation.
4.7 Why the Team Gap Is Structural
Section 10 documents the gap explicitly. The conventional read is "the market will mature." Six architectural barriers explain why iteration on existing tools will not close it:
Single-tenant DNA: Tools start as solo-developer projects. Their core abstraction is a SQLite file on a laptop. Retrofitting multi-user requires rewriting the storage model, auth model, and deployment model simultaneously. Cheaper to start a new tool, which is exactly what Memlord, Pindoc, and Artel did.
OAuth 2.1 is months of engineering: Implementing PKCE, refresh tokens, scoped permissions, and multi-IdP support is 3-6 months for a memory tool. Most authors don't have that runway. doobidoo has the flag (MCP_OAUTH_ENABLED) but ships it disabled.
Privacy and sharing can't coexist cheaply: Privacy-first tools mean local SQLite, which means no sharing. Cloud-shared tools mean vendor data residency. End-to-end encrypted shared memory with client-side key management, the answer to both requirements, is not implemented by any tool here.
No team taxonomy standard: Mem0 uses user_id with wildcards. Memlord uses workspaces. ICM has no team primitive. Zep has graph-scoped permissions. No interoperability is possible without a standard. Supermemory's container tags are a fourth, functionally similar primitive to Mem0's user_id scoping, with no documented merge or conflict-resolution semantics between personal and team memory.
No enterprise buyer yet: Memory tools are bought by individuals at $0-25/month. Team memory needs SOC 2, SSO, audit logs, and an admin console. Only Zep cloud at $475/month is attempting this. Supermemory's own compliance stack (SOC 2 Type II, HIPAA BAA) exists but is gated to Scale/Enterprise pricing, and its most Claude-Code-specific integration, the claude-supermemory plugin, is paywalled from an individual's first real use at $19/month, the same individual-buyer-first default this bullet describes.
Claude Code's multi-agent model is young: Agent teams are a recent feature. Building shared memory on an evolving substrate has been correctly deferred by teams who could have done it.
The correct bet today: CLAUDE.md + .mcp.json (static, zero infra) for shared standards, plus Notion MCP or Mem0 cloud (zero new infra) for dynamic shared memory. Plan a migration to agentmemory on a shared host or Memori when those tools' team stories mature.
Partial counter-example, file-based playbooks (§3.7): ORF and DiffMem sidestep the single-tenant-DNA barrier by having no database at all. Because a playbook is a plain file, git commit experiences/ distributes one developer's agent fix to the whole team through the same review flow as code, no server and no auth model to build. DiffMem pushes this further with an orphan Git branch per user for real multi-tenant isolation. This solves distribution, not coordination: the two hard problems (consolidating overlapping playbooks and resolving conflicts between contributors) are exactly the open questions their authors name and leave unsolved. The Git-native path is the distribution mechanism §10 says is missing, but it inherits Git's merge semantics, which were not designed for semantic memory conflicts.