Claude Code Agent Teams: Guía Multisesión (2026)
Research preview - desactivado por defecto, el comportamiento puede cambiar. Las agent teams de Claude Code son varias sesiones ejecutándose en paralelo: un agente "lead" coordina, uno o más "teammates" ejecutan, y todo el equipo comparte una lista de tareas más mensajería directa - muy distinto de un subagent (se ejecuta dentro del contexto de la sesión que lo llamó, sin ventana propia y persistente, sin ida y vuelta de mensajes). En esta guía explico: cómo habilitarlo, en qué se diferencia de subagents/skills/workflows, qué es en realidad el cross-session messaging, las limitaciones reales y una lectura honesta sobre AgentKit.
- Esta es una función en research preview, y la mecánica de activación ya cambió una vez (antes/después de la v2.1.178 - las herramientas manuales para crear equipos ya no existen). Los detalles aquí se contrastaron con la documentación oficial al momento de escribir (08/2026) - verifica la documentación en vivo antes de depender de esto.
Qué son realmente las agent teams
Agent teams es una función en research preview de Claude Code que permite que varias sesiones se ejecuten en paralelo dentro de un "equipo": un agente lead coordina, y uno o más teammates ejecutan tareas. Cada teammate obtiene su propia ventana de contexto - no comparte contexto con el lead ni con los demás teammates - y todo el equipo comparte una lista de tareas más un canal de mensajería directa (mailbox). Según la documentación oficial en code.claude.com/docs/en/agent-teams (revisada en 08/2026), esto es una capa de coordinación sobre sesiones independientes de Claude Code - no un modelo nuevo, no una API aparte.
Una línea para evitar confusiones: las agent teams no son las personas "advisor" o "kongming" de AgentKit - esas funcionan de una forma muy distinta (mira la lectura honesta al final).
Agent teams vs subagents
Si ya te manejas con Claude Code subagents, aquí tienes la comparación directa de la documentación (resumida):
| Criterio | Subagents | Agent teams |
|---|---|---|
| Contexto | Se ejecuta dentro del contexto de la sesión que lo llamó, sin ventana propia y persistente | Cada teammate tiene su propia ventana de contexto |
| Comunicación | Toma una tarea, devuelve un resultado - sin ida y vuelta de mensajes | Envía mensajes directamente por un mailbox mientras se ejecuta |
| Coordinación | La sesión principal decide qué subagent llamar y cuándo | Lead + lista de tareas compartida; los teammates la reclaman o reciben trabajo asignado |
| Mejor para | Trabajo especializado y repetible que necesita aislamiento de contexto (code review, tests...) | Exploración en paralelo, varias perspectivas sobre un problema a la vez |
| Costo de tokens | Menor - un contexto, llamado bajo demanda | Bastante mayor - cada teammate es una sesión completa ejecutándose en paralelo |
Versión corta: un subagent es "delega el trabajo y recibe un resultado"; agent teams es "un grupo trabajando junto y enviándose mensajes directamente". Para escalar aún más la orquestación de subagents, mira orquestar subagents a escala.
Quién tiene el plan: subagents vs skills vs agent teams vs workflows
Esta es la principal aportación de información del artículo - una comparación de 4 vías sacada directamente de la documentación de Claude Code (code.claude.com/docs/en/workflows, revisada en 08/2026) que ninguno de los competidores que revisamos, EN o VI, reproduce por completo:
| Subagents | Skills | Agent teams | Workflows | |
|---|---|---|---|---|
| Qué es | Un agente hijo, llamado bajo demanda, con contexto propio para una tarea | Instrucciones cargadas por el contexto (divulgación progresiva) | Varias sesiones en paralelo, lead + teammates, lista de tareas compartida | Un script (lo escribe Claude) que despliega subagents en segundo plano |
| Quién decide qué se ejecuta después | La sesión principal decide | La sesión principal, guiada por las instrucciones de la skill | El lead y cada teammate deciden dentro de su ámbito asignado | La lógica dentro del script decide, no Claude turno a turno |
| Dónde viven los resultados intermedios | Se devuelven al contexto de la sesión que llamó | Sin estado aparte - son solo instrucciones | La lista de tareas compartida + mailbox | Dentro del runtime del propio workflow, separado del contexto principal |
| Qué es repetible | Sí, si redefines el agente | Sí - ese es justamente el punto de una skill | No automáticamente - cada equipo es una sesión interactiva | Sí - se guarda como un comando reutilizable |
| Escala | Un agente a la vez, secuencial o unos pocos en paralelo | No atado a un agente - son instrucciones | Limitado por cuántas sesiones abras de verdad en paralelo | Hasta cientos/miles de subagents en una sola ejecución |
| Interrupción | Sigue a la sesión principal | No aplica | Aún sin reanudación para teammates en curso (mira limitaciones) | Se puede pausar/reanudar con /workflows |
Ninguno de los artículos de la competencia que revisamos reproduce este encuadre exacto de 4 vías - la mayoría solo compara agent teams con subagents y se salta skills y workflows por completo. Para un análisis a fondo de workflows/ultracode, mira Claude Code Dynamic Workflows.
Habilitar las agent teams - CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS
Las agent teams vienen desactivadas por defecto. Actívalas con una variable de entorno en settings.json:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true"
}
}Algunas cosas que conviene recordar (según la documentación, revisada en 08/2026 - verifícalo en la versión de Claude Code que de verdad estás ejecutando antes de confiar en esto):
- Solo funciona en una sesión interactiva - no se ejecuta con
-pni con el Agent SDK. - En la configuración actual (post-v2.1.178), no necesitas llamar manualmente a las herramientas
TeamCreate/TeamDeletecomo describen algunos textos más antiguos - esas herramientas ya no existen en el flujo actual. Si lees una guía que describe un paso manual para crear equipos, probablemente se escribió antes de este cambio - un ejemplo concreto de la advertencia de "puede cambiar" que la propia Anthropic da.
Iniciar tu primer equipo y la lista de tareas compartida
Una vez habilitado, empieza con una tarea lo bastante grande como para repartirla entre perspectivas, por ejemplo:
Spawn a team of 3 teammates to review this PR:
one for security, one for performance, one for test coverage.
Report findings back to me.Claude Code crea una lista de tareas compartida para todo el equipo, con estados familiares: pending, in progress, completed. Algunos mecanismos que conviene conocer:
- Bloqueo por dependencia - una tarea puede esperar a que termine otra antes de empezar.
- Auto-reclamada o asignada por el lead - un teammate puede reclamar por sí mismo una tarea pendiente, o el lead puede asignársela directamente.
- Bloqueo de archivo al reclamar - cuando un teammate reclama una tarea que toca un archivo concreto, un bloqueo evita que dos teammates editen el mismo sitio a la vez.
Cross-session messaging - una función distinta, no un equipo
Aquí es donde la mayoría de los competidores (EN y VI) difuminan la línea y lo tratan como "mensajería del equipo". La documentación en realidad lo trata como una función aparte: el cross-session messaging permite que dos sesiones independientes de Claude Code - incluso en otra máquina, o vía Remote Control - se pasen mensajes mediante ListAgents/SendMessage (o el comando /list-agents), sin que ambas pertenezcan al mismo equipo supervisado por Claude.
Cuándo usar cada uno: si quieres que el propio Claude coordine un grupo a través de una lista de tareas compartida, usa agent teams. Si tienes algunas sesiones independientes que gobiernas tú misma y solo necesitas que se pasen mensajes cuando lo pidas, el cross-session messaging es la herramienta adecuada y más ligera - no necesitas activar todo el mecanismo de equipo para eso.
Nota de plataforma: el cross-session messaging por ahora solo funciona en macOS/Linux - todavía no hay soporte nativo en Windows. WSL2 cuenta como Linux, así que allí sí funciona. El modo de visualización en panel dividido del equipo también necesita
tmuxo iTerm2, y explícitamente no funciona en Windows Terminal. No he visto ni un solo competidor (EN o VI) mencionar esto - vale la pena señalarlo, dado cuántas máquinas de desarrollo entre los lectores de este sitio usan Windows.
Agent view - el panel para sesiones paralelas en segundo plano
Una función relacionada y fácil de confundir: el agent view, que se abre con claude agents. Es un panel que lista tus sesiones paralelas en segundo plano - a diferencia de las agent teams, no hay mensajería entre sesiones, es puramente una pantalla de monitoreo. También es research preview.
Vale la pena corregir una confusión bastante común: el aislamiento mediante un git worktree dedicado por sesión es el mecanismo del agent view (para sesiones en segundo plano), no un comportamiento por defecto de las agent teams. Algunos textos describen las agent teams como si crearan automáticamente un worktree separado por teammate, presentado como una especie de "universo paralelo" - la documentación de Arquitectura de las agent teams no describe ningún mecanismo así; solo describe lead/teammate/lista de tareas/mailbox, sin ninguna mención a worktrees automáticos.
Un caso de uso realista: PR review en paralelo
El caso de uso más fuerte en la documentación oficial (y el que yo de verdad elegiría) es un PR review en paralelo: levantar 3 teammates, cada uno leyendo el mismo PR desde una lente distinta - seguridad, rendimiento, cobertura de tests - y luego reportándote de vuelta. Como cada teammate tiene su propio contexto, no se pisan entre sí al leer el mismo diff.
Con honestidad: este recorrido está basado en el caso de uso que la propia Anthropic documenta, no en una ejecución de primera mano con números concretos (cantidad de problemas, de PRs). Si ves otra review citando cifras precisas como "X problemas encontrados en Y minutos", vale la pena preguntarse si de verdad la ejecutaron o solo están parafraseando la documentación. Otro patrón que vale la pena probar: dale un bug difícil a varios teammates trabajando hipótesis en competencia, y deja que el lead sintetice qué hipótesis encaja mejor con la evidencia.
Cualquiera de los dos patrones solo compensa cuando las subtareas de verdad se benefician de un contexto separado - leer el mismo diff con lentes distintas, o perseguir teorías diferentes de causa raíz sin que la suposición de un teammate contamine la de otro. Para trabajo que es casi todo secuencial (implementar, luego probar, luego documentar) una simple cadena de subagents suele ser más barata y fácil de razonar que montar todo un equipo.
Limitaciones - lo que aún no funciona
Como esto es un research preview, la documentación enumera abiertamente sus propias limitaciones actuales - vale la pena leerlas antes de apostar un flujo importante a esta función:
- Sin reanudación para teammates en curso tras cerrar la terminal - cerrar la sesión pierde a ese teammate.
- El estado de las tareas se retrasa - la lista de tareas no siempre refleja lo que un teammate está haciendo en tiempo real.
- Un equipo por sesión - no puedes ejecutar varios equipos en paralelo bajo una sesión lead.
- Sin equipos anidados - un teammate no puede levantar su propio subequipo.
- Los paneles divididos necesitan tmux/iTerm2 y no funcionan en Windows Terminal (la misma salvedad que el cross-session messaging).
Por eso también el artículo insiste en "research preview": la mecánica de activación ya cambió una vez (eliminando el paso manual de la herramienta para crear equipos), así que esta lista de limitaciones es una buena candidata a cambiar también. No ates un flujo crítico de producción a los detalles/comportamiento exactos descritos aquí sin volver a comprobarlo.
Ángulo honesto sobre AgentKit: ¿sus personas pueden ser teammates?
La pregunta directa: ¿pueden las personas advisor y kongming de AgentKit actuar como teammates en una agent team? No, no como un teammate persistente.
kongminges de un solo tiro: entra un prompt, sale una respuesta, sin turnos de ida y vuelta.advisores de entrevista por relevos: hace preguntas de una en una y vuelve a la sesión principal entre ellas - no es una sesión independiente ejecutándose en paralelo, enviando mensajes por un mailbox.
Ninguno está hecho para la mensajería persistente y de múltiples turnos que un teammate necesita (según docs.agentkit.best/en/beta/concepts/advisory-supervision, revisado en 08/2026).
Pero hay un matiz real que vale la pena decir con todas las letras en vez de pasarlo por alto: Claude Code te permite levantar un teammate usando cualquier tipo de agente definido a nivel de proyecto/usuario/plugin - y el adaptador de runtime de AgentKit instala los agentes del kit como definiciones nativas de subagent de Claude Code. Así que, técnicamente, un agente de ejecución de tareas de un kit de AgentKit (no advisor/kongming) puede designarse como teammate. Eso no es lo mismo que "AgentKit trae equipos ya hechos" - lo digo con claridad: AgentKit es un kit de pago que te da personas/skills para delegar trabajo; agent teams es el mecanismo de coordinación gratuito de Claude Code en el que tú misma las enchufas - no un producto "equipo" empaquetado por AgentKit. Mira la review completa de AgentKit para más.
¿Quieres un conjunto sólido de personas/skills prefabricados para entregar a un teammate? AgentKit empaqueta skills y subagents para Claude Code (y Codex) - utilizables como agentes de tarea dentro de un equipo que montas tú misma, no un producto "equipo" empaquetado. Pago único, sin cuota recurrente indicada en la página.
Preguntas frecuentes (FAQ)
¿Qué hace CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS?
Es una variable de entorno (definida en settings.json) que habilita la función de agent teams de Claude Code, desactivada por defecto por seguir siendo un research preview. Solo funciona en una sesión interactiva, no con -p ni con el Agent SDK.
¿En qué se diferencian las agent teams de los subagents?
Un subagent se ejecuta dentro del contexto de la sesión que lo llamó, toma una tarea y devuelve un resultado, sin ida y vuelta de mensajes. Las agent teams implican varias sesiones independientes (cada teammate con su propio contexto), que comparten una lista de tareas y se envían mensajes directamente por un mailbox mientras se ejecutan - con un costo de tokens bastante mayor.
¿Funciona el cross-session messaging en Windows?
Todavía no de forma nativa - por ahora solo funciona en macOS/Linux. WSL2 cuenta como Linux, así que allí sí funciona. El modo de visualización en panel dividido del equipo también necesita tmux o iTerm2, y no funciona en Windows Terminal.
¿Cuál es el costo de tokens de un equipo frente a una sola sesión?
Bastante mayor, porque cada teammate es una sesión completa ejecutándose en paralelo sin contexto compartido con la sesión principal. La documentación no da una cifra fija - recurre a esto solo cuando de verdad necesites perspectivas paralelas, no cuando un solo agente trabajando de forma secuencial bastaría.
¿Puedo reanudar un equipo después de cerrar la terminal?
Todavía no. Según las limitaciones actuales, los teammates en curso no pueden reanudarse después de que cierras la sesión - cerrar la terminal pierde a ese teammate. Esta es una de las limitaciones que la propia documentación enumera abiertamente.
¿Es esta función lo bastante estable para el trabajo diario?
La verdad que no - sigue siendo un research preview, y la mecánica de activación ya cambió una vez (eliminando el paso manual de la herramienta para crear equipos). Está bien probarla en exploración paralela no crítica; todavía no es algo sobre lo que construir un flujo diario obligatorio, dada la estabilidad que aún le falta.
Conclusión
Agent teams sigue siendo un research preview - potente para la exploración en paralelo (varias perspectivas sobre un problema a la vez), no un reemplazo del trabajo secuencial más simple que un subagent o una skill ya resuelven. Ten a mano la tabla de 4 vías "quién tiene el plan" como tu atajo de decisión: un solo agente siguiendo instrucciones secuenciales - subagent/skill; sesiones largas y colaborativas que se envían mensajes entre sí - agent teams; trabajo más grande que una ventana de contexto o que necesita cientos de subagents - workflow. Pruébala primero en algo no crítico, lee las limitaciones con atención y no ates un proceso de producción a detalles que pueden cambiar en cualquier momento.