Teams

Team memory architecture and Preview status

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.

• Preview status: In the Memory Console at https://xmemo.dev/me#teams, Team Management is marked with the Preview badge.
• Console workspace context: The Team Management header announces "One workspace for members and invitations." where administrators manage active members and pending invitations.
• Space navigation: Collaborators switch into a team space using the explicit space parameter (https://xmemo.dev/me?space=<team_id>#memory) or inspect shared knowledge (https://xmemo.dev/me?space=<team_id>#knowledge) and skills (https://xmemo.dev/me?space=<team_id>#skills).
• Collaborative isolation: Team workspaces provide multi-agent shared context isolated from individual user personal memory spaces (/me#memory).

Team eligibility, creation requirements, and subscription boundaries

Team creation requires an entitled Business subscription with at least 2 purchased seats. Because the Business plan is not currently open for purchase, self-service team creation defaults to disabled for general accounts. Public documentation never presents buying seats as an available action.

• Creation posture: Self-service team creation defaults to disabled in production environments until the Business plan launches.
• Entitlement requirement: The console checks organization entitlement before opening team creation. If ineligible, the interface displays: "A Business subscription with at least 2 purchased seats is required to create a team."
• Preview limitation reason: If an account lacks allowlist clearance, the console displays: "Team creation is currently limited to preview accounts."
• General unavailability reason: For unprovisioned accounts, the console states: "Team creation is not available for this account yet."
• Commercial status: The Business subscription is not currently purchasable. Self-service seat additions and plan upgrades are disabled.
• Creation modal: In allowlisted preview accounts, clicking Create team opens a modal stating: "Enter your company name. This will become the team name inside XMemo." with input field "Company name" (placeholder "e.g. Acme Corp").

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. The role schema below is an illustrative summary (not an API response):

• Role hierarchy: Illustrative summary (not an API response) mapping workspace roles to permission levels and token issuance ceilings.
• owner (level 3): Workspace creator fixed to the billing account. Can invite members with Admin, Member, or Viewer roles; can update non-owner member roles (between Admin, Member, and Viewer); can remove non-owner members and revoke invitations. 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 administrator. Can invite members with Member or Viewer roles (cannot invite Admins); can remove non-owner members and revoke pending invitations; cannot modify member roles. 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): Standard workspace collaborator. Read, write, and restore access to shared team memory seats, team knowledge items, and team cloud skills. 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) and shared knowledge inspection. Permitted no credential issuance; prohibited from writing memory, updating state, or minting team credentials.
• Sole owner constraint: A sole owner attempting to leave receives the notice: "Cannot leave team as the sole owner. Transfer ownership or delete the team first." (with tooltip: "Sole owner must transfer ownership before leaving").

{
  "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.

Seat management, invitation lifecycle, and lifecycle boundaries

Workspace capacity is tracked qualitatively across active memberships and pending invitations. Operating boundaries govern invitation issuance, expiration, and console capabilities:

• Qualitative seat counting: Occupied seats consist of active members plus unexpired pending invitations, displayed in the console header as "Seats {used} / {limit} used, {members} members, {pending} pending".
• Technical invitation expiry: Team invitations expire 7 days after issuance (teams_service.py:1184-1188). Expired invitations release their reservation and no longer count toward occupied seats.
• Seat capacity limit: When all available seats are occupied, the Add member modal warns: "Team seat limit reached. Upgrade or remove a member or pending invitation to send more invitations."
• Invitation workflow status: Sending an invitation generates a secure 7-day token link. However, invitation acceptance has no consumer in the console interface today; the full invitation acceptance workflow is not yet available in the console.
• No team deletion or ownership transfer: The console does not provide routes or UI controls for deleting a team workspace or transferring team ownership. These actions are unavailable in self-service.

Shared resources, agent access, and data export boundaries

Teams capability introduces zero changes to the Model Context Protocol (MCP) surface. Agents access shared team memory transparently using standard tools (remember, recall, recall_context, search, etc.) simply by authenticating with a team-bound token.

• Shared team memory: Connected agents authenticating with a team-bound token read and write to the shared team memory space.
• Shared Team Knowledge: Document collections published under the team space (?space=<team_id>#knowledge) are retrievable by team agents and team members with knowledge:read scope.
• Shared Team Cloud Skills: Procedural skills created under the team space (?space=<team_id>#skills) are governed by team roles. Publishing in a team space creates a PROPOSED revision requiring Admin or Owner approval.
• Personal project boundary: Project workspaces remain strictly personal only today (services/personal_console.py:7222). Creating a project workspace with team_id is rejected by the backend.
• Data export boundary: Personal data export (/api/v1/export or /me#memory) exports exact personal memories and strictly excludes shared team memory records.
• 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.