Teams

Arquitectura de memoria de Teams y estado Preview

Teams es una función del plan Business. En producción, la creación de equipos está desactivada de forma predeterminada hasta que se lance el plan Business; el runtime actual opera en modo de solo denegación (deny-only) para solicitudes no autorizadas. Los administradores de espacio gestionan los límites del espacio de trabajo y el aprovisionamiento de inquilinos en el plano de gestión del espacio de trabajo, mientras que el acceso de los agentes a la memoria está regido por plazas en el plano de datos con enlaces criptográficos de espacio aislados por inquilino.

• Estado Preview: En la Memory Console en https://xmemo.dev/me#teams, Team Management está marcado con la insignia Preview.
• Contexto del espacio de trabajo de la consola: El encabezado de Team Management anuncia "One workspace for members and invitations." donde los administradores gestionan miembros activos e invitaciones pendientes.
• Navegación espacial: Los colaboradores cambian a un espacio de equipo mediante el parámetro explícito de espacio (https://xmemo.dev/me?space=<team_id>#memory) o inspeccionan conocimientos compartidos (https://xmemo.dev/me?space=<team_id>#knowledge) y habilidades (https://xmemo.dev/me?space=<team_id>#skills).
• Aislamiento colaborativo: Los espacios de trabajo de equipo proporcionan contexto compartido para múltiples agentes, aislado de los espacios de memoria personal de los usuarios individuales (/me#memory).

Elegibilidad de equipo, requisitos de creación y límites de suscripción

La creación de un equipo requiere una suscripción Business con derecho que cuente con al menos 2 plazas adquiridas. Dado que el plan Business no está disponible actualmente para su compra, la creación de equipos en autoservicio está desactivada de forma predeterminada para las cuentas generales. La documentación pública nunca presenta la compra de plazas como una acción disponible.

• Postura de creación: La creación de equipos en autoservicio está desactivada de forma predeterminada en entornos de producción hasta que se lance el plan Business.
• Requisito de derechos: La consola comprueba los derechos de la organización antes de habilitar la creación de equipos. Si no es apta, la interfaz muestra: "A Business subscription with at least 2 purchased seats is required to create a team."
• Motivo de limitación en Preview: Si una cuenta carece de autorización en la lista de permitidos, la consola muestra: "Team creation is currently limited to preview accounts."
• Motivo de no disponibilidad general: Para cuentas no aprovisionadas, la consola indica: "Team creation is not available for this account yet."
• Estado comercial: La suscripción Business no se puede adquirir actualmente. La adición de plazas en autoservicio y las mejoras de plan están desactivadas.
• Modal de creación: En cuentas de vista previa autorizadas, al hacer clic en Create team se abre un modal que indica: "Enter your company name. This will become the team name inside XMemo." con el campo de entrada "Company name" (marcador de posición "e.g. Acme Corp").

Jerarquía RBAC de cuatro niveles y límites de emisión de credenciales

Los permisos de pertenencia al equipo y los límites de emisión de credenciales son aplicados por los servicios de la consola personal. Los miembros activos con roles owner, admin o member pueden emitir credenciales vinculadas al equipo dentro de los límites de alcance específicos de su rol, mientras que los usuarios viewer son estrictamente de solo lectura y se les deniega la emisión de tokens. El esquema de roles siguiente es un resumen ilustrativo (no una respuesta de API):

• Jerarquía de roles: Resumen ilustrativo (no una respuesta de API) que asigna roles del espacio de trabajo a niveles de permisos y límites de emisión de tokens.
• owner (nivel 3): Creador del espacio de trabajo vinculado permanentemente a la cuenta de facturación. Puede invitar a miembros con roles Admin, Member o Viewer; puede actualizar roles de miembros no propietarios (entre Admin, Member y Viewer); puede eliminar miembros no propietarios y revocar invitaciones. Puede emitir credenciales vinculadas al equipo con cualquier alcance de autoservicio, incluidos los alcances de memoria del plano de datos, ledger, conocimiento y auditoría (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write y read:audit).
• admin (nivel 2): Administrador del espacio de trabajo. Puede invitar a miembros con roles Member o Viewer (no puede invitar a Admins); puede eliminar miembros no propietarios y revocar invitaciones pendientes; no puede modificar roles de miembros. Puede emitir credenciales vinculadas al equipo con cualquier alcance de autoservicio, incluidos los alcances de memoria del plano de datos, ledger, conocimiento y auditoría (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write y read:audit).
• member (nivel 1): Colaborador estándar del espacio de trabajo. Acceso de lectura, escritura y restauración a las plazas de memoria compartidas del equipo, elementos de conocimiento del equipo y Cloud Skills del equipo. Puede emitir credenciales personales vinculadas al equipo limitadas a los alcances de miembro del equipo (memory:read, memory:write, memory:restore, read:memories y write:memories); no puede emitir alcances elevados de ledger o conocimiento, ni gestionar miembros o configuraciones del espacio de trabajo.
• viewer (nivel 0): Acceso a la memoria de solo lectura en la consola (memory:read) e inspección del conocimiento compartido. No se le permite la emisión de credenciales; prohibido escribir en memoria, actualizar estado o emitir credenciales de equipo.
• Restricción de propietario único: Un propietario único que intente abandonar el equipo recibe el aviso: "Cannot leave team as the sole owner. Transfer ownership or delete the team first." (con texto flotante: "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": []
    }
  }
}

Enlace de espacio autoritativo en servidor y revocación dinámica

El aislamiento multiinquilino se aplica en el servidor mediante enlaces criptográficos de espacio. Cada clave de API con alcance de equipo contiene reclamaciones inmutables (bound_team_id, membership_id_at_issue, space_binding_version) que no pueden ser alteradas ni suministradas por solicitudes de cliente. Las solicitudes dirigidas a un equipo que no coincida fallan de forma cerrada inmediatamente con HTTP 403 token_space_mismatch.

• Verificación de espacio autoritativa: Las solicitudes dirigidas a un equipo no coincidente fallan de forma cerrada inmediatamente con HTTP 403 token_space_mismatch.
• Garantía contra suplantación: Las solicitudes con encabezados de equipo falsificados o en conflicto se rechazan en el edge antes de acceder a los grupos de bases de datos.
• Revocación dinámica basada en época: La validación de la membresía verifica la época de membership_id activa en cada solicitud autenticada, garantizando que los miembros eliminados pierdan el acceso de inmediato tras la actualización de la época sin esperar a que expire el token.

Gestión de plazas, ciclo de vida de invitaciones y límites operativos

La capacidad del espacio de trabajo se monitoriza cualitativamente entre membresías activas e invitaciones pendientes. Los límites operativos rigen la emisión de invitaciones, la expiración y las capacidades de la consola:

• Recuento cualitativo de plazas: Las plazas ocupadas consisten en miembros activos más invitaciones pendientes no vencidas, mostrándose en el encabezado de la consola como "Seats {used} / {limit} used, {members} members, {pending} pending".
• Vencimiento técnico de invitaciones: Las invitaciones de equipo caducan a los 7 días de su emisión (teams_service.py:1184-1188). Las invitaciones caducadas liberan su reserva y ya no cuentan para las plazas ocupadas.
• Límite de capacidad de plazas: Cuando todas las plazas disponibles están ocupadas, el modal Add member advierte: "Team seat limit reached. Upgrade or remove a member or pending invitation to send more invitations."
• Estado del flujo de trabajo de invitaciones: Enviar una invitación genera un enlace con token seguro válido por 7 días. Sin embargo, la aceptación de invitaciones no tiene consumidor en la interfaz de la consola hoy en día; el flujo completo de aceptación de invitaciones aún no está disponible en la consola.
• Sin eliminación de equipo ni transferencia de propiedad: La consola no proporciona rutas ni controles de interfaz para eliminar un espacio de trabajo de equipo o transferir la propiedad del equipo. Estas acciones no están disponibles en autoservicio.

Recursos compartidos, acceso de agentes y límites de exportación de datos

La capacidad de Teams no introduce cambios en la superficie del Model Context Protocol (MCP). Los agentes acceden a la memoria compartida del equipo de manera transparente utilizando herramientas estándar (remember, recall, recall_context, search, etc.) simplemente autenticándose con un token vinculado al equipo.

• Memoria de equipo compartida: Los agentes conectados que se autentican con un token vinculado al equipo leen y escriben en el espacio de memoria compartida del equipo.
• Conocimiento de equipo compartido: Las colecciones de documentos publicadas bajo el espacio de equipo (?space=<team_id>#knowledge) pueden ser recuperadas por los agentes del equipo y miembros del equipo con alcance knowledge:read.
• Cloud Skills de equipo compartidas: Las habilidades procedimentales creadas bajo el espacio de equipo (?space=<team_id>#skills) se rigen por roles de equipo. La publicación en un espacio de equipo crea una revisión PROPOSED que requiere la aprobación del Admin o del Owner.
• Límite de proyectos personales: Los espacios de trabajo de proyectos siguen siendo estrictamente personales hoy en día (services/personal_console.py:7222). El backend rechaza la creación de un espacio de trabajo de proyecto con team_id.
• Límite de exportación de datos: La exportación de datos personales (/api/v1/export o /me#memory) exporta exactamente memorias personales y excluye estrictamente los registros de memoria compartida del equipo.
• Superficie de herramientas congelada: No se añaden herramientas de gestión de equipos (como creación de equipos o gestión de invitaciones) a MCP.
• Compatibilidad universal de clientes: Claude Desktop, ChatGPT, Codex, Cursor y Gemini CLI interactúan con la memoria del equipo sin cambios de configuración del lado del cliente.
• Aislamiento delimitado: Las memorias escritas por agentes en un espacio de equipo reciben automáticamente la atribución del equipo y se aíslan de la memoria personal del usuario.

Límites explícitos y capacidades no verificadas

Para evitar desviaciones de la documentación respecto al código entregado, las siguientes capacidades no están explícitamente disponibles y quedan fuera del alcance de la versión actual:

• Plan Business requerido: La capacidad de Teams pertenece al plan Business, que actualmente aún no está disponible para su compra pública.
• Creación en producción desactivada: La creación de equipos general en autoservicio está desactivada en entornos de producción hasta que se lance el plan Business.
• Sin sincronización automatizada SCIM / SAML: No se admite la sincronización de directorios de proveedores de identidades empresariales.
• Sin replicación de datos multinube o multirregión: Los datos del equipo residen en una única partición de inquilino regional.
• Sin herramientas de mutación en MCP: Los equipos no se pueden crear, modificar ni eliminar mediante llamadas a herramientas de MCP.
• Modo de runtime de solo denegación: El runtime actual opera en modo de solo denegación para solicitudes no autorizadas hasta que se lance el plan Business.
• Sin métricas de rendimiento infundadas: Los tiempos de revocación y consulta son propiedades operativas en tiempo de ejecución, no garantías numéricas fijas.