Este artículo es una traducción del artículo original en inglés.
Hay un hilo en r/ClaudeCode con el mejor título: "Convénceme de que los equipos de agentes no son inútiles". Hay mucho debate ahí, porque es una pregunta muy válida.
¿La verdad? Los equipos de agentes de Claude (Agent Teams) son inútiles para la mayoría de las cosas. Los equipos de agentes cuestan entre 3 y 4 veces más tokens que una sesión individual. Añaden una sobrecarga de coordinación real. Para un bug fix, un refactor, un nuevo componente —son la herramienta equivocada y saldrás más lento y con menos tokens.
Pero para los casos específicos donde brillan, nada más se les acerca. Una revisión de código en paralelo donde tres agentes investigan seguridad, rendimiento y cobertura de pruebas simultáneamente, cada uno sin contaminarse con los hallazgos de los otros. Cinco agentes persiguiendo teorías en competencia sobre un bug complicado, cada uno rebatiendo a los demás. Frontend, backend y pruebas avanzando al mismo tiempo sin esperar al otro. Estas son formas genuinamente distintas de lo que puedes hacer en una sola sesión.
Si quieres ver cómo se ve el desarrollo multiagente a escala completa —más de 20 agentes corriendo en paralelo en contenedores en la nube, cada uno con su propio entorno de desarrollo y vista previa en el navegador, tu PM verificando cambios de UI directamente en la rama en vivo— eso es Builder.io. Pruébalo gratis. Este artículo trata sobre la versión local de esa idea, y exactamente cuándo vale la pena el overhead.
La versión corta: un líder, varios compañeros de equipo, todos coordinando trabajo compartido.
El líder es tu sesión principal de Claude Code. Crea una lista de tareas, genera compañeros de equipo, asigna trabajo y sintetiza resultados. Cada compañero es una instancia completamente independiente de Claude Code —su propia ventana de contexto, sus propias instrucciones, su propio panel de terminal si usas tmux. Se comunican mensajeándose directamente a través de un sistema de buzón compartido: enviar un mensaje añade JSON a un archivo de bandeja de entrada, reclamar una tarea actualiza un archivo de tareas. Es colaboración entre IAs diseñada como software, no como chat.
Lo que separa a los equipos de agentes de los subagentes es esa palabra: comunicación. Los subagentes hacen el trabajo y reportan resultados al agente principal. Eso es todo. Los compañeros de equipo se mensajean entre sí, cuestionan los hallazgos del otro, comparten lo que han aprendido y coordinan sin que tú gestiones cada traspaso. Como dijo Dára Sobaloju: "Los subagentes son llamadas a funciones. Los equipos de agentes son organizaciones."
Esa distinción es lo que los hace poderosos —y también lo que los hace innecesarios para la mayoría de las tareas.
Una cosa importante que saber: no hay /resume para los equipos de agentes. Si la sesión muere, el equipo desaparece. Planifica en consecuencia.
Ningún artículo responde esto con claridad, así que aquí va.
Verde — aquí es donde los equipos de agentes justifican su costo:
- Revisión de código en paralelo. Seguridad, rendimiento y cobertura de pruebas revisados simultáneamente por agentes separados. La razón por la que esto funciona mejor que un solo agente haciendo las tres cosas: aislamiento de sesgo. Lo primero que encuentra un agente individual ancla toda su revisión. Los agentes separados comienzan cada uno desde cero. El líder sintetiza después.
- Depuración con hipótesis en competencia. Tienes cinco teorías sobre por qué algo está roto. Generas cinco agentes, cada uno persiguiendo una, cada uno intentando refutar a los demás. El sesgo de contexto es el verdadero enemigo en la depuración —un agente encuentra evidencia para la Teoría A y deja de buscar con rigor las teorías B a E. Los agentes separados protegen cada teoría de esa contaminación.
- Funcionalidades entre capas. Frontend, backend y pruebas, cada uno en manos de un compañero diferente, avanzando en paralelo. Sin esperas. Cada agente se mantiene en su dominio.
- Exploración grande de solo lectura. Investigación, research, recopilación de contexto —tareas donde los agentes solo leen y nunca crean conflictos de archivos. Un buen punto de partida si eres nuevo en esto.
Amarillo — puede funcionar, depende de cómo lo estructures:
- Refactorizaciones de múltiples archivos con separación clara de dominios (funciona bien si puedes garantizar que no haya superposición de archivos)
- Pipelines de escritura: investigación, borrador y edición corriendo de forma concurrente (el overhead de coordinación vale la pena a escala, no tanto para un solo artículo)
Rojo — no uses equipos de agentes:
- Tareas secuenciales con dependencias fuertes (una cosa tiene que ocurrir antes que la siguiente —usa subagentes o una sola sesión)
- Ediciones en el mismo archivo (conflictos de merge garantizados, sin excepciones)
- Cualquier cosa suficientemente pequeña como para terminar en una sesión (el overhead no compensa)
- Flujos de trabajo sensibles al costo (cada compañero es una ventana de contexto completa; un equipo de 4 compañeros puede consumir tokens rápidamente)
La documentación oficial lo dice claramente: "Los equipos de agentes funcionan mejor cuando los compañeros pueden operar de forma independiente." Si tus tareas están muy acopladas, no pagues por un equipo.
Todos dicen "ahora eres un tech lead". Esto es lo que eso significa en la práctica.
Activa el modo delegación. Pulsa Shift+Tab para activarlo. El error más común de los principiantes es dejar al líder en su modo predeterminado, donde escribe código en lugar de coordinar. Con el modo delegación activado, el líder planifica y delega. Sin él, has pagado por un equipo y tu agente más caro está haciendo trabajo de ingeniero junior.
Instruye a los compañeros como si fuera su primer día. Los compañeros no heredan el historial de tu conversación. Cargan tu CLAUDE.md, tus servidores MCP y el prompt de generación que les das. Eso es todo. Si pasaste una hora construyendo contexto sobre el codebase en tu sesión principal, nada de eso se traslada. Sé explícito: estructura del proyecto, archivos relevantes, convenciones de código, el objetivo específico. Escatimar en el prompt de generación es la razón más común por la que los resultados son mediocres.
Impón la separación de dominios. El agente de frontend trabaja en /frontend. El agente de backend trabaja en /backend. Dos agentes tocando el mismo archivo es un conflicto de merge esperando ocurrir. Esto es innegociable. Si no puedes separar los dominios con claridad, no uses un equipo.
Máximo 5 o 6 tareas por compañero. No le asignes 20 cosas a un agente. Divide el trabajo en unidades autocontenidas con entregables claros, inícialo de una en una, trae de vuelta al compañero. Muchas de las mejores prácticas para gestionar ingenieros reales aplican directamente aquí.
Monitorea activamente, no lo dejes solo. Si dejas correr un equipo sin supervisión por demasiado tiempo, los agentes se desvían y desperdicias tokens. La vista de paneles divididos de tmux lo hace mucho más fácil —puedes ver todos tus agentes trabajando simultáneamente. Estate atento a que el líder empiece a implementar cosas él mismo en lugar de delegar. Cuando eso ocurra, dile: "Espera a que tus compañeros completen sus tareas antes de continuar."
Empieza con tareas de solo lectura. Si eres nuevo en esto, prioriza la investigación y el research primero. Sin escritura de archivos, sin conflictos. Una vez que te sientas cómodo con los mecanismos de coordinación, pasa a la implementación.
Ya no estás dando prompts a una IA. Estás ejecutando sprint planning.
1. Activa el flag
Añade esto a tu ~/.claude/settings.json:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}Reinicia Claude Code.
2. Instala tmux (muy recomendado)
brew install tmux # macOSInicia una sesión de tmux antes de lanzar Claude. Esto te da una vista de paneles divididos —cada compañero tiene su propio panel visible. Puedes monitorear todos los agentes simultáneamente y hacer clic en cualquier panel para interactuar directamente.
3. Pide un equipo en inglés llano
Create an agent team to review the latest changes. One agent focused on
security, one on performance, one on test coverage. Have them each review
and combine results into one report.Eso es todo. Claude crea el equipo, genera los compañeros y empieza a coordinar. Tú guías desde ahí.
Este es el mejor punto de entrada a los equipos de agentes. El prompt es simple, el valor es inmediato, y el riesgo de conflictos de archivos es cero (todos leen, nadie escribe).
Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications and vulnerability patterns
- One checking performance impact and potential bottlenecks
- One validating test coverage and edge cases
Have each reviewer go deep in their lane. Then combine into one report
with severity ratings.
Por qué esto funciona mejor que pedirle a un solo agente que haga las tres cosas: el primer agente que empieza ancla toda la revisión. Si el revisor de seguridad encuentra un problema con el manejo de tokens, una revisión de un solo agente empieza a gravitarse hacia las preocupaciones de seguridad y pierde objetividad en el rendimiento. Los agentes separados empiezan cada uno desde cero. El líder obtiene tres perspectivas limpias y sintetiza.
Esta es la menos usada y genuinamente novedosa.
Users report the dashboard crashes after the second data refresh. I have
five theories:
1. Race condition in the state update
2. Memory leak from uncleaned event listeners
3. WebSocket reconnect flooding the connection pool
4. Stale closure capturing an outdated reference
5. Response parsing failing on an edge case in the data shape
Spawn 5 agent teammates to investigate these simultaneously. Have them
actively try to disprove each other's theories — like a scientific debate.
Compile the surviving evidence into a findings doc.La instrucción "refutar activamente las teorías del otro" importa. Sin ella, los agentes confirmarán su teoría y pararán. Con ella, obtienes falsificación real. La teoría que sobrevive tiene muchas más probabilidades de ser la causa raíz real.
Para tener contexto de lo que es posible a escala: Anthropic construyó un compilador de C usando 16 agentes de Claude en aproximadamente 2.000 sesiones, consumiendo alrededor de 2 mil millones de tokens de entrada, a un costo inferior a $20.000. Ese es el techo de la técnica —no un flujo de trabajo práctico para el día a día, pero un buen recordatorio de lo que esta arquitectura puede hacer cuando el problema genuinamente lo justifica.
Esto es lo que encuentras cuando llevas los equipos de agentes al límite:
De 3 a 5 compañeros es el límite práctico. Más allá de eso, el overhead de coordinación empieza a comerse las ganancias. La comunicación, la carga de contexto, el líder intentando dar seguimiento a todos —se complica rápido.
Las sesiones son efímeras. El equipo muere con la sesión. Sin resume, sin rebobinar. Si estás a mitad de una tarea y Claude se cae, el equipo desaparece. Planifica para esto.
Tu máquina paga el precio. Cada agente es una instancia completa de Claude Code. Cinco compañeros significa cinco ventanas de contexto corriendo simultáneamente. En un laptop, lo sentirás —RAM, CPU, los ventiladores a tope.
Sin vista previa en el navegador. Puedes monitorear agentes en paneles de terminal, pero no hay forma de verificar cambios de UI en un navegador en vivo sin salir del flujo de trabajo. Iterar sobre cambios visuales es incómodo.
Sin colaboración en equipo. Eres solo tú y la terminal. Tu PM no puede entrar a una rama y verificar el resultado. Tu diseñador no puede ajustar el comportamiento responsive. Sigues siendo el único humano en el ciclo.
Builder.io es cómo se ven los equipos de agentes cuando los llevas a la nube. En lugar de 3 a 5 compañeros en tu laptop, obtienes más de 20 agentes en contenedores en paralelo —cada uno con su propio entorno de desarrollo completo y vista previa en el navegador. Tu PM puede verificar cambios de UI directamente en la rama en vivo. Tu diseñador puede ajustar el comportamiento responsive sin un handoff de Figma. Revisas un PR completamente validado, no código en bruto que necesita QA manual. El concepto es el mismo. El techo es mucho más alto.
Si los equipos de agentes te dieron una probada de cómo se siente el desarrollo multiagente, Builder.io es donde esa idea escala. Pruébalo gratis.
¿Valen la pena los equipos de agentes?
Para las tareas correctas, sí —la revisión de código en paralelo y la depuración con hipótesis en competencia en particular. Para todo lo demás, probablemente no. El costo en tokens y el overhead de coordinación son reales. Usa el filtro Verde/Amarillo/Rojo de arriba.
¿Cuándo debo usar equipos de agentes en lugar de subagentes?
Usa subagentes cuando los trabajadores solo necesitan hacer tareas aisladas y reportar de vuelta. Usa equipos de agentes cuando los trabajadores necesitan compartir hallazgos, cuestionarse mutuamente y coordinar sin que tú gestiones cada mensaje. Si no necesitan hablar entre sí, los subagentes son más baratos y simples.
¿Cuántos compañeros debo usar?
Empieza con 3. La mayoría de los flujos de trabajo no necesitan más de 4 o 5. Empieza pequeño, añade compañeros solo cuando puedas separar claramente los dominios y estés seguro de que el trabajo en paralelo compensa.
¿Cuánto cuestan los equipos de agentes?
Planifica con entre 3 y 4 veces los tokens de una sesión individual para un equipo típico. Cada compañero tiene su propia ventana de contexto completa. Un equipo de 4 compañeros cargando el mismo contexto del proyecto es 4 veces el costo de inicialización antes de que ocurra cualquier trabajo real. Para investigación, revisión y funcionalidades complejas entre capas, los tokens extra suelen valer la pena. Para cualquier cosa que una sola sesión pueda manejar en un solo paso, quédate con una sola sesión.