# Teams Tenant-isolated shared memory spaces for collaborative agent teams. Space administrators manage workspace bounds on the management plane while memory access is partitioned by data-plane seats. - Canonical: https://docs.xmemo.dev/docs/capabilities/teams - Locale: en-US - Content-Locale: en-US - Canonical-Content-Digest: 901546079e99fa6d4caacbabd3e70fe478ec4135b3cbac8ee5cfe2a0a65156fb - Edition-Digest: 3a656b85c7b168d8699cc55d1d0e4cd311e3dc363f9a63f51b97c0db74a32fdc - Source-Revision: sha256:3c2a5853dd0aa8a465ee4f2018081b302039f773e3e24a43b919381132d2fe15 ## Team memory architecture and availability Teams is a feature of the Business plan. In production, team creation is disabled by default until the Business plan launches; current runtime operates in deny-only mode for unauthorized requests. Space administrators manage workspace bounds and tenant provisioning on the workspace management plane, while agent memory access is governed by data-plane seats with tenant-isolated cryptographic space bindings. - Plan entitlement: Teams is a feature of the Business plan; the Business plan is currently not open for purchase; current runtime operates in deny-only mode for unauthorized requests. - Default production posture: Team creation is disabled by default in production environments until the Business plan launches. - Workspace governance and data plane seats: Space administrators govern workspace bounds on the management plane, while memory access is partitioned by tenant-bound seats. - Collaborative isolation: Team workspaces provide multi-agent shared context isolated from individual user memory spaces. ## Four-tier RBAC hierarchy and credential issuance ceilings Team membership permissions and credential issuance ceilings are enforced by personal console services. Active members with owner, admin, or member roles can mint team-bound credentials within role-specific scope ceilings, while viewers are strictly read-only and denied token issuance. - owner (level 3): Full workspace governance, workspace deletion, billing settings, and member role management. Can mint team-bound credentials with any self-service scope, including data-plane memory, ledger, knowledge, and audit scopes (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write, and read:audit). - admin (level 2): Workspace administration, invitation issuance and revocation, and member removal. Can mint team-bound credentials with any self-service scope, including data-plane memory, ledger, knowledge, and audit scopes (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write, and read:audit). - member (level 1): Read, write, and restore access to shared team memory seats. Can mint personal team-bound credentials capped to team member scopes (memory:read, memory:write, memory:restore, read:memories, and write:memories); cannot mint elevated ledger or knowledge scopes, and cannot manage workspace members or settings. - viewer (level 0): Read-only memory access in the console (memory:read). Permitted no credential issuance; prohibited from writing memory, updating state, or minting team credentials. ```json { "roles": { "owner": { "level": 3, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories", "delete:memories", "ledger:read", "ledger:write", "knowledge:read", "knowledge:write", "read:audit" ] }, "admin": { "level": 2, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories", "delete:memories", "ledger:read", "ledger:write", "knowledge:read", "knowledge:write", "read:audit" ] }, "member": { "level": 1, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories" ] }, "viewer": { "level": 0, "token_issuance_cap": [] } } } ``` ## Server-authoritative space binding and dynamic revocation Multi-tenant isolation is enforced server-side through cryptographic space bindings. Every team-scoped API key contains immutable claims (bound_team_id, membership_id_at_issue, space_binding_version) that cannot be altered or supplied by client requests. Requests targeting a mismatched team fail closed immediately with HTTP 403 token_space_mismatch. - Authoritative space verification: Requests targeting a mismatched team fail closed immediately with HTTP 403 token_space_mismatch. - Anti-spoofing guarantee: Requests with forged or conflicting team headers are rejected at the edge before accessing database pools. - Epoch-based dynamic revocation: Membership validation checks the live membership_id epoch on every authenticated request, guaranteeing removed members lose access immediately upon epoch update without waiting for token expiration. ## Team context inspection and zero-leakage error semantics Team administration and memory state inspection are exposed via dedicated read-only REST endpoints under /api/v1/team-context. These routes require an admin scope and enforce strict tenant-isolation and anti-existence oracle protections. - GET /api/v1/team-context/summary — Aggregated health, node count, and active storage metrics for the bound team space. - GET /api/v1/team-context/explain/{node_key} — Node attribution, author agent identity, and memory revision history. - GET /api/v1/team-context/health — Diagnostic health check verifying tenant partition integrity and vector store synchronization. - Anti-existence protection: Requests querying non-existent nodes or cross-tenant nodes return identical HTTP 404 responses to prevent tenant probing. ```json { "team_id": "tm_987654", "total_nodes": 1420, "active_members": 4, "storage_bytes": 5242880, "status": "healthy" } ``` ## Transparent agent access through the 12 canonical MCP tools Teams capability introduces zero changes to the Model Context Protocol (MCP) surface. All 12 MCP tool specifications under Reference > MCP Tools remain 100% frozen and machine-stable. Agents access shared team memory transparently using standard tools (remember, recall, recall_context, search, etc.) simply by authenticating with a team-bound token. - Frozen tool surface: No team management tools (such as team creation or invite management) are added to MCP. - Universal client compatibility: Claude Desktop, ChatGPT, Codex, Cursor, and Gemini CLI interact with team memory without client-side configuration changes. - Scoped isolation: Memories written by agents in a team space are automatically stamped with team attribution and isolated from personal user memory. ## Explicit boundaries and unverified capabilities To prevent documentation drift ahead of shipped code, the following capabilities are explicitly not available and out of scope for the current release: - Business plan required: Teams capability belongs to the Business plan, which is currently not yet open for public purchase. - Production creation disabled: General self-service team creation is disabled in production environments until the Business plan is launched. - No automated SCIM / SAML synchronization: Enterprise identity provider directory sync is not supported. - No cross-cloud or multi-region data replication: Team data resides in a single regional tenant partition. - No MCP mutation tools: Teams cannot be created, modified, or deleted via MCP tool calls. - Deny-only runtime mode: Current runtime operates in deny-only mode for unauthorized requests until the Business plan launches. - No ungrounded performance metrics: Revocation and query timing are operational runtime properties, not fixed numerical guarantees. ## ChatGPT user Give ChatGPT durable access to your XMemo preferences, project facts, decisions, and TODOs without pasting bearer tokens into a chat. Connect the hosted XMemo MCP server through the ChatGPT/OpenAI app OAuth flow, then approve the memory:read and memory:write grant for your XMemo account. Save a synthetic preference or project note, start a new chat, then ask ChatGPT to recall it through XMemo before continuing work. If OAuth fails or tools do not appear, sign out of the MCP server in the host app, reconnect the XMemo server URL, and retry before creating direct tokens. ## Copilot / Codex developer Carry repo decisions, coding conventions, bug-fix notes, and task history between IDE and CLI agents. Use OAuth for VS Code / GitHub Copilot and Gemini CLI when available. For Copilot CLI, Codex, Cursor, or other direct MCP clients, keep XMEMO_KEY in the local environment or secret store and set a stable XMEMO_AGENT_INSTANCE_ID. Record a codebase decision or bug fix, then ask the next IDE or CLI agent to recall the relevant XMemo context before editing. If recalls are empty, verify the selected MCP config path, the XMEMO_KEY environment variable for direct clients, and any stale OAuth credential in the host app. ## Team / enterprise pilot owner Evaluate shared memory with account controls, source attribution, export/delete workflows, and reviewer-safe setup evidence. Create or enter the protected XMemo workspace, invite approved users, then connect each client through OAuth or a scoped direct credential according to the readiness badges. Have a pilot member save a synthetic team memory, confirm source attribution in XMemo, then review delete/export and support paths. If a member cannot connect, check role permissions, OAuth approval, client readiness status, and support guidance before issuing a new token. ## Autonomous agent operator Let headless or scheduled agents record progress, retrieve prior decisions, and keep a stable non-secret instance identity. Fetch /api/v1/mcp/config/autonomous-agent. Prefer auth_modes.oauth when the runner supports OAuth + custom headers; use auth_modes.xmemo_key with XMEMO_KEY from a secret store only for fully headless runners. Run one synthetic task that writes progress to XMemo, restart the runner, and confirm it recalls that progress using the same XMEMO_AGENT_INSTANCE_ID. If attribution changes or recalls split across instances, persist XMEMO_AGENT_INSTANCE_ID outside git and verify the runner is not regenerating it on every start.