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.
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.
{
"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.
{
"team_id": "tm_987654",
"total_nodes": 1420,
"active_members": 4,
"storage_bytes": 5242880,
"status": "healthy"
}
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.
Persona flows
ChatGPT user
Give ChatGPT durable access to your XMemo preferences, project facts, decisions, and TODOs without pasting bearer tokens into a chat.
Save a synthetic preference or project note, start a new chat, then ask ChatGPT to recall it through XMemo before continuing work.
Copilot / Codex developer
Carry repo decisions, coding conventions, bug-fix notes, and task history between IDE and CLI agents.
Record a codebase decision or bug fix, then ask the next IDE or CLI agent to recall the relevant XMemo context before editing.
Team / enterprise pilot owner
Evaluate shared memory with account controls, source attribution, export/delete workflows, and reviewer-safe setup evidence.
Have a pilot member save a synthetic team memory, confirm source attribution in XMemo, then review delete/export and support paths.