Agent Teams en Claude Code: Cuándo 5 Agentes Valen Más que 1

Introducción

He pasado el fin de semana entero probando Agent Teams de Claude Code. No con un proyecto de juguete: con un desarrollo enterprise real, con arquitectura DDD, múltiples capas (Domain, Application, Infrastructure), múltiples repositorios, y decenas de reglas de negocio que respetar.

Los resultados me han sorprendido. Tanto que necesitaba escribir sobre ello.

Si antes tenía que ir guiando a Claude paso a paso — “ahora los tests”, “revisa los endpoints”, “documenta con los datos de las pruebas manuales” — con Agent Teams he conseguido una implementación completa en un solo prompt. Con una buena especificación, eso sí.

Pero no todo es magia. Merece la pena entender cuándo tiene sentido y cuándo no, porque el coste en tokens se multiplica por 7-10x.

El problema: guiar paso a paso

Cuando trabajas con Claude Code en una sesión normal, la exploración es secuencial. Claude investiga, implementa, y pasa al siguiente paso. Para el 90% de los casos funciona bien.

Pero en desarrollos complejos con múltiples capas, la dinámica cambia. Necesitas que alguien diseñe la arquitectura, otro implemente el dominio, otro la infraestructura, otro los tests, otro revise el código… y todo tiene que encajar.

En mis desarrollos anteriores con sesión individual, el proceso era así: le explicaba qué implementar y lo hacía. Bien. Pero luego tenía que decirle “ahora escribe los tests”. Y después “prueba los endpoints”. Y después “documenta los endpoints con las respuestas reales de las pruebas”. Múltiples sesiones, múltiples prompts, perdiendo contexto entre medias.

Y si pudieras tener todos esos roles trabajando en paralelo, coordinándose entre ellos? Eso es Agent Teams.

Qué son Agent Teams

Agent Teams es una funcionalidad experimental de Claude Code. Permite coordinar múltiples instancias de Claude trabajando en paralelo como un equipo real. Si todavía no conoces Claude Code, lee mi guía completa con 15 consejos de uso diario antes de continuar.

La diferencia con los subagentes que ya conoces de Claude Code:

Subagentes: El agente principal delega una tarea, el subagente la ejecuta aisladamente, devuelve el resultado. No hay comunicación entre subagentes.

Agent Teams: Los teammates se envían mensajes entre sí, comparten una lista de tareas común, se desafían y coordinan de forma autónoma. El team lead orquesta pero no centraliza toda la comunicación.

Es la diferencia entre tener freelancers trabajando en silos versus un equipo real que colabora.

El equipo que monté

Para la prueba de concepto monté un equipo de 7 agentes, cada uno con su archivo de configuración, sus herramientas, y su modelo:

Architect (Opus): Propone la estructura DDD antes de que nadie escriba código. Bounded Context, Aggregates, relaciones entre entidades, tipo de migraciones. Solo lee y diseña, no implementa.

Domain Developer (Sonnet): Implementa el corazón del negocio. Entidades, Value Objects, repositorios, finders, excepciones de dominio, servicios de aplicación, commands y queries.

Infrastructure Developer (Sonnet): Conecta el dominio con el mundo exterior. ORM, repositorios Doctrine, controllers, FormTypes, migraciones, permisos, traducciones en 5 idiomas.

Unit Tester (Sonnet): Cobertura 100% de la capa de Application. Cada servicio, cada handler, cada camino posible. Mutation testing para asegurar que los tests son útiles de verdad.

Documenter (Sonnet): Documenta cada endpoint una vez probado. Genera la documentación técnica con los requests y responses reales de las pruebas, y actualiza la colección de Bruno para que el equipo de frontend tenga todo listo.

Code Reviewer (Opus): Revisión final contra todas las reglas del proyecto. PHPStan, tests de regresión, adherencia a convenciones.

Devil’s Advocate (Opus): Intenta romper todo. Cuestiona decisiones de diseño, busca vulnerabilidades, valida invariantes de dominio, edge cases, concurrencia.

Cada agente tiene instrucciones detalladas de qué puede y qué no puede hacer. El Domain Developer no toca infraestructura. El Infrastructure Developer no toca dominio. El Architect no escribe código. Esto es clave para evitar conflictos.

La elección de modelo importa: Opus para los roles que necesitan criterio (architect, reviewer, devil’s advocate) y Sonnet para los que necesitan velocidad (developers, tester). Optimiza coste sin sacrificar calidad donde importa.

El flujo de implementación

El team lead lee la especificación técnica y orquesta:

1. Lanza al Architect para que proponga la estructura
2. En paralelo, Domain Developer e Infrastructure Developer implementan sus capas
3. Unit Tester escribe los tests
4. Se prueban los endpoints y el Documenter documenta cada uno con los datos reales de las pruebas
5. Code Reviewer valida calidad y regresión
6. Devil’s Advocate busca problemas

Las tareas independientes se ejecutan en paralelo. Las que tienen dependencias, en secuencial. Domain antes que Infrastructure. Pero dentro de cada capa, las entidades independientes van a la vez.

Y todo esto arranca con un solo prompt que incluye la ruta a la especificación. Un solo prompt.

Los resultados

Aquí es donde la cosa se pone interesante.

Antes (sesión individual): Múltiples sesiones, guiando paso a paso. Implementa, luego tests, luego endpoints, luego documentación. Tenía que estar encima revisando cada paso y pidiendo el siguiente. Si perdía contexto entre sesiones, había que re-explicar cosas.

Ahora (Agent Teams): Desarrollo completo en un solo prompt. Código, migraciones, endpoints probados, documentación, tests unitarios, code review. Todo.

Y lo que más me sorprendió: en la revisión del código no tuve que ajustar nada. La implementación salió mucho más acertada que en sesiones individuales. El Devil’s Advocate encontraba edge cases que en una sesión normal se escapan. El Code Reviewer pillaba violaciones de reglas que a mí se me pasaban.

La clave no fue Agent Teams en sí. Fue la combinación de agentes bien definidos + especificación detallada + reglas claras del proyecto. Sin esos tres ingredientes, Agent Teams sería igual de mediocre que una sesión individual mal configurada.

Activación

Agent Teams es experimental. Hay dos formas de activarlo:

Variable de entorno:

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

En tu settings.json (recomendado):

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  },
  "language": "Español",
  "alwaysThinkingEnabled": true
}

El settings.json está en ~/.claude/settings.json. Una vez configurado, inicia Claude Code normalmente. La funcionalidad estará disponible pero tienes que pedirle explícitamente que cree un team.

El coste real

No voy a engañar a nadie: Agent Teams es caro.

Métrica	Sesión Individual	Agent Teams	Multiplicador
Tokens consumidos	~20,000-25,000	~150,000-200,000	7-10x
Tiempo de setup	0 min	15-30 min	-
Perspectivas	1 generalista	7 especializadas	7x

Si pagas $15 por millón de tokens de input y $75 por millón de output (tarifas de Opus 4.6), un desarrollo complejo con Agent Teams puede costarte $15-20 frente a $2-3 en sesión individual.

La pregunta es: ¿compensa?

Depende. Si el desarrollo te ahorra 3-4 sesiones de ida y vuelta corrigiendo cosas, sí. Si la calidad del código sale bien a la primera y no tienes que revisar tanto, sí. Si es una tarea simple que se resuelve en 5 minutos, obviamente no.

Coordinación, no automatización

Agent Teams no es “lanza y olvida”. Como team lead, tienes que supervisar:

• Monitorear el progreso de cada teammate
• Intervenir cuando alguien se atasca
• Tomar decisiones pragmáticas (a veces hay que hacer shutdown de un agente que está tardando demasiado)
• Resolver conflictos de coordinación

Edición concurrente de archivos

Varios agentes pueden intentar editar el mismo archivo a la vez. No hay file-locking. La solución es asignar ownership claro: el Domain Developer no toca Infrastructure, el Infrastructure Developer no toca Domain.

Si defines bien los roles, los conflictos son mínimos. En mi prueba del fin de semana, no tuve ninguno. Cada agente sabía qué archivos eran suyos y cuáles no.

Estado experimental

Agent Teams es experimental. Las APIs pueden cambiar, hay bugs, y los comportamientos inesperados son parte del juego. He tenido sesiones donde teammates se desincronizaban o donde el messaging fallaba. Si vas a probarlo, tenlo en cuenta.

El compilador de C de Anthropic

Para poner en perspectiva el potencial de la coordinación multi-agente, Anthropic publicó un caso extremo: 16 instancias paralelas de Claude implementaron un compilador completo de C desde cero.

Números del proyecto:

• 16 instancias paralelas, ~2,000 sesiones de Claude Code en 2 semanas
• 100,000 líneas de código en Rust generadas
• Coste: $20,000 en API calls (2B tokens input, 140M tokens output)
• Resultado: compila el kernel de Linux 6.9, QEMU, FFmpeg, SQLite, PostgreSQL y Redis
• 99% de éxito en el GCC torture test suite

Lo que me parece más relevante del artículo es que el autor dice que “la mayor parte de mi esfuerzo fue diseñar el entorno alrededor de Claude”: tests de alta calidad, documentación exhaustiva, y mecanismos de feedback. No los agentes en sí.

Eso encaja con mi experiencia: la calidad de las specs y las reglas del proyecto es lo que marca la diferencia, no la cantidad de agentes que lances.

Cuándo SÍ, cuándo NO

Usa Agent Teams cuando:

• Desarrollo multi-capa: Necesitas implementar Domain, Application, Infrastructure, tests y documentación coordinados
• Exploración paralela: Múltiples hipótesis a investigar a la vez (debugging complejo)
• Tasks independientes: Trabajo que se puede dividir sin muchas dependencias
• Expertise especializada: Cada agente aporta perspectiva diferenciada
• El presupuesto lo permite: El multiplicador de 7-10x está justificado
• Tienes buenas specs y reglas: Sin esto, Agent Teams no aporta mucho

NO uses Agent Teams cuando:

• Tareas sencillas: Un cambio pequeño, un bugfix simple
• Todo depende de todo: Si cada paso necesita el anterior, no hay paralelización posible
• No tienes reglas claras: Si tus agentes no saben qué hacer, el resultado será caótico
• Primera vez: Explora primero con sesión individual, entiende el problema, y solo entonces escala

Regla práctica: Si no estás seguro, empieza con sesión individual. Escala a Agent Teams cuando tengas evidencia de que la paralelización aporta valor.

Consejos prácticos

Menos agentes, mejor definidos

No crees 10 agentes. 3-5 bien definidos son más efectivos que 10 mediocres. Cada uno con rol claro, expertise diferenciado, y ownership de archivos definido.

Define flujos claros

Antes de lanzar el team, documenta el orden: quién va primero, quién espera a quién, qué se puede paralelizar. Sin workflow claro, los agentes se descoordinan y duplican trabajo.

Invierte en specs y reglas

La calidad del output de Agent Teams es directamente proporcional a la calidad de tus especificaciones y reglas de proyecto. He tenido decenas de reglas en .claude/rules/ afinadas durante meses. Eso es lo que permite que los agentes hagan el trabajo bien a la primera.

Usa modelos diferentes por rol

Opus para los que necesitan criterio. Sonnet para los que necesitan velocidad de implementación. Esto optimiza coste sin sacrificar calidad donde importa.

Conclusión

Agent Teams no es para todo. Es para ese 5-10% de casos donde el desarrollo es complejo, multi-capa, y una sola sesión se queda corta.

Lo que más me ha sorprendido del fin de semana no es la velocidad (que también), sino la calidad. Cuando cada agente tiene un rol especializado y unas reglas claras, el resultado es mejor que una sesión generalista. El Devil’s Advocate encuentra cosas que se te escapan. El Code Reviewer pilla violaciones que tú no verías.

¿La clave? No son los agentes. Son las specs, las reglas, y la definición de roles. Agent Teams es la herramienta, pero sin la preparación detrás, no funciona.

Y una cosa más: si llevas meses usando Claude Code, probablemente ya tienes las reglas afinadas. Agent Teams es el siguiente paso natural para sacarles más partido.

---

P.D.: Si estás probando Agent Teams o tienes experiencias que compartir, me encuentras en Twitter como @lmmartinb. Y si todavía no usas Claude Code, empieza por mi guía de consejos de uso diario.