Todos los artículos

Claude Code para equipos: qué cambia cuando los agentes son multi-tenant

Tu agente funciona de maravilla cuando tiene un usuario. El día que tiene diez mil, de repente estás construyendo orgs, roles, auditoría, cuotas, impersonación y webhooks. Aquí va la lista de lo que necesitas, y el patrón que le tomamos prestado a Stripe para hacerlo bien.

Appstrate
multi-tenantequiposapi

👤 Tu agente tiene un usuario. Ahora tiene diez mil.

Claude Code, Cursor, OpenClaw, Antigravity: los agentes de código autónomos de 2025 y 2026 se volvieron muy buenos, muy rápido. La forma del producto es la misma: un dev, una laptop, un agente. Las credenciales son las del dev. El filesystem es el del dev. Los logs son la terminal del dev.

Esa forma funciona mientras el agente tenga exactamente un usuario. En el momento en que decides llevar esa capacidad a un equipo real (tu propio equipo usando una herramienta interna compartida, o tus usuarios embebiendo un agente en un SaaS que operas) descubres un segundo producto escondido dentro del primero.

El segundo producto tiene organizaciones, roles, invitaciones, cuotas, logs de auditoría, impersonación, API keys, idempotencia, webhooks, versionado, y algunas cosas más. A Stripe le tomó una década dejar bien afinada su versión de ese producto. Lo más probable es que no quieras construir todo eso de nuevo.

Este artículo va de lo que cambia cuando un agente pasa de "un usuario" a "muchos usuarios", y qué patrones hacen que la transición no sea terrible.

📐 Las siete cosas que vas a construir (y probablemente no deberías)

La brecha entre un agente personal y un agente de equipo es un conjunto de features que parecen opcionales hasta que dejan de serlo. Aquí va la lista en el orden en que lamentarás no tenerlas.

1. Organizaciones y membresía

En el segundo en que dos personas comparten un agente, hay una organización implícita envolviendo todo. Alguien es owner. Alguien es admin. Alguien es miembro. A alguien hay que darlo de baja cuando se va. Alguien necesita ser invitado, con un email, vía un enlace que expira, contra un rol.

Vas a escribir esta capa. Toma dos semanas.

2. Roles y permisos, los de verdad

Tres roles (owner / admin / member) es el mínimo que sobrevive al contacto con usuarios. No alcanza para una plataforma. El RBAC de verdad tiene verbos (read, write, delete, invite, billing) contra recursos (agents, runs, models, webhooks, api_keys, connections). Terminas con entre treinta y cien combinaciones de permisos.

En Appstrate terminamos con 78. No es un capricho de diseño: es el número que necesitas si no quieres que el primer evaluador enterprise se ría de ti y se vaya de la demo.

3. API keys con scope, no bearer-to-root

Una sola API key que hace todo está bien el día 1 y es un incidente de seguridad el día 300. Las API keys de verdad tienen scope (esta key puede leer runs pero no crear agentes), son atribuibles (quién la creó, cuándo, último uso), revocables al instante y rate-limited por key.

También necesitan un prefijo con sentido (ask_ en el caso de Appstrate) para que tu tooling de detección pueda hacer grep sobre ellas en repos públicos.

4. Logs de auditoría en el lado confiable

Cuando un usuario de un usuario de tu plataforma exfiltra datos, los logs del proceso del agente no son admisibles. Necesitas logs de auditoría del lado de la plataforma, escritos por el runtime, no por nada que el agente pueda influenciar. Quién corrió qué, en nombre de quién, a qué hora, desde qué IP, con qué resultado. Guardados lo suficiente como para que compliance firme.

5. Cuotas, rate limits y kill switch

Un usuario puede correr un agente las veces que quiera en su propia máquina. En una plataforma compartida, eso es una factura y un vector de DoS. Necesitas límites de concurrencia por org, rate limits por minuto, techos de presupuesto diarios y un kill switch para cancelar runs en curso cuando algo sale mal.

El que agarra a los equipos por sorpresa: un kill switch compartido de "cancela cada run en toda la plataforma ahora mismo", porque un día vas a desplegar una versión mala de agente y lo vas a necesitar.

6. Impersonación para soporte

Tu primer ticket de soporte va a ser "mi agente no funcionó" y no vas a poder reproducirlo sin convertirte en ese usuario durante cinco minutos. Todo sistema multi-tenant maduro tiene impersonación. Los que lo hacen bien tienen logs de auditoría sobre la impersonación misma (quién impersonó a quién, cuándo, por cuánto tiempo).

7. Webhooks, idempotencia, versionado

Todo lo que es largo y multi-tenant necesita una historia de callback async. Todo con reintentos necesita idempotency keys o las acciones duplicadas se vuelven la norma. Todo con API pública necesita una estrategia de versionado para que los breaking changes no rompan a los consumidores.

Nada de esto es opcional si quieres que te usen en producción. Y todo es molesto de hacer bien.

🎭 Dashboard users vs end-users: la distinción Stripe

Aquí está la sutil. Cuando haces tu agente multi-tenant, tienes que lidiar con dos tipos de usuarios, y confundirlos es la causa número uno de una plataforma rota.

Los dashboard users son tus usuarios. Tu equipo. Los devs y admins que entran directo a la plataforma, configuran agentes, miran logs, gestionan API keys. Tienen contraseñas. Tienen 2FA. Ven una UI. Pertenecen a orgs.

Los end-users son los usuarios de lo que construiste sobre la plataforma. Nunca entran a tu dashboard de agentes. Viven dentro de tu producto. Su nombre está en tu tabla de clientes. Tienen un externalId que les asignaste. Conectan su propio Gmail, su propio Notion, su propio GitHub a los agentes que corren en su nombre.

Stripe lo entendió temprano. User en el dashboard es una persona de tu equipo. Customer es una persona que te paga. Dos tablas, dos modelos, dos ciclos de vida, dos conjuntos de reglas. La misma separación tiene que existir en una plataforma de agentes:

┌──────────────────────────────────────────────────────────────┐
│ Organización (tu empresa)                                    │
│                                                              │
│   Dashboard users ──── las personas en tu equipo             │
│   ────────────────     contraseña, rol, login al dashboard   │
│                                                              │
│   Application ──────── un producto que envías                │
│   ────────────────     tu SaaS, tu herramienta interna       │
│                                                              │
│       End-users ──── los usuarios de tu producto             │
│       ─────────────  externalId, metadata, sus credenciales  │
│                      sus runs, sus webhooks                  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Cuando no haces esta separación, acabas en uno de dos malos desenlaces. O los end-users pueden ver datos del dashboard (una brecha), o los dashboard users heredan las preocupaciones de los end-users y tu sistema de roles colapsa bajo su propio peso.

En Appstrate, los dashboard users viven en la tabla users, los end-users en end_users, y las API keys que crean runs de end-users llevan un header Appstrate-User: eu_…, con la misma forma que el header Stripe-Account de Stripe, por exactamente la misma razón.

🎛️ Impersonación, bien hecha

El patrón es el mismo que el resto: tomar prestado de pagos, no reinventar.

POST /api/runs
Authorization: Bearer ask_live_…
Appstrate-User: eu_01HZXY…
Idempotency-Key: run-2026-03-28-abc123
Content-Type: application/json

{ "agentId": "agent_inbox_triage", "input": { … } }

Cuatro cosas dignas de mirar en esa petición, porque cada una es una lección aprendida de hacerlo mal la primera vez:

  • Appstrate-User se rechaza en auth por cookie. Las sesiones del dashboard no pueden impersonar: solo puede la auth por API key, y la application de la API key tiene que coincidir con la del end-user. Esto frena el error de soporte más común ("olvidé con qué usuario estaba logueado") antes de que se convierta en un incidente.
  • Idempotency-Key vuelve seguros los reintentos. La plataforma guarda la respuesta 24 horas. Una key duplicada con el mismo body devuelve el resultado cacheado; una key duplicada con un body distinto recibe un 422. Así corres un agente desde un cron con reintentos sin facturar dos veces.
  • El run hereda las conexiones del end-user, no las del dashboard user. Cuando el agente llama a Gmail vía el broker, usa el token de eu_01HZXY, no el tuyo. Este es el cableado más importante: ¿para quién está actuando el agente, ahora mismo?
  • Cada impersonación emite un registro de auditoría: el request ID, el ID de la API key, el ID del end-user impersonado, la IP, el user agent. El log vive en la plataforma, no en el proceso del agente.

Puedes construir todo esto en un trimestre. No deberías. O mejor dicho, deberías, pero solo las partes específicas de tu producto. La plomería multi-tenant es la misma para cualquier equipo que construya sobre agentes.

🧱 Cómo se ve realmente "Claude Code para equipos"

La frase es una abreviatura. No es un port literal de Claude Code: es un patrón.

Un agente de código single-user es una personalidad. Un agente de equipo es una plataforma alrededor de esa personalidad. Obtienes:

  • El mismo prompt que funcionaba en tu laptop, corriendo en nombre de tus compañeros.
  • El mismo agent package (prompt + schema + skills + tools), versionado e instalable entre aplicaciones.
  • Roles que reflejan quién puede ejecutar qué.
  • Rate limits para que un usuario no se coma el presupuesto de la org.
  • Logs de auditoría para que pase tu revisión de seguridad.
  • API keys para que tu CI pueda disparar runs.
  • Webhooks para que tu producto reaccione cuando los runs terminen.
  • Impersonación para que tu soporte pueda reproducir el problema.

Un agente de equipo no es un Claude Code mejorado. Es Claude Code envuelto en cien piezas aburridas de infraestructura que todo producto multi-tenant termina necesitando. La razón de que exista una runtime platform es shipear esas cien piezas una vez, bien hechas, y dejar que los autores de agentes se concentren en el prompt.

📚 Relacionado

Otros artículos

Documentación de Appstrate