Equipos de agentes en Claude Code: configuración, consejos y casos de uso

Equipos de agentes en Claude Code: configuración, consejos y casos de uso

Quemé un presupuesto de $47 en tokens en diecinueve minutos. Cuatro agentes, todos corriendo Opus 4.6, todos trabajando en el mismo codebase de Next.js, todos editando layout.tsx al mismo tiempo.

El orquestador no detectó el conflicto. El agente de front-end sobrescribió el wrapper de autenticación del agente de back-end. El agente de QA probó una versión del archivo que ya no existía. Y el agente de diseño — el que había creado para "pulir la UI" — introdujo una clase de Tailwind que rompió el grid responsive que el agente de front-end había pasado ocho minutos construyendo.

Diecinueve minutos. Cuarenta y siete dólares. Un codebase peor que cuando empecé.

Eso fue en febrero de 2026. Acababa de activar los equipos de agentes de Claude Code por primera vez, y cometí todos los errores contra los que te advierte la documentación — más algunos que ni siquiera menciona. Desde entonces, he ejecutado equipos de agentes en más de treinta proyectos reales, desde dashboards SaaS hasta migraciones de API y un pipeline de contenido que ahora alimenta el blog que estás leyendo. La funcionalidad pasó de "desastre costoso" a la herramienta más poderosa de mi flujo de desarrollo.

Esta es la guía que me hubiera gustado tener cuando empecé. No la versión de marketing. No el quickstart de tres párrafos. El panorama completo — configuración, ajustes, más de 30 consejos ganados a pulso y los seis casos de uso donde los equipos de agentes realmente superan todo lo demás que he probado.

Qué son realmente los equipos de agentes (y por qué los sub-agentes no son suficientes)

Antes de tocar cualquier configuración, necesitas un modelo mental más preciso que "múltiples agentes trabajando juntos". La diferencia entre sub-agentes y equipos de agentes es la diferencia entre contratar freelancers y armar un escuadrón — y confundir los dos te va a costar dinero real.

Los sub-agentes son instancias independientes de Claude Code lanzadas por tu sesión principal. Cada uno recibe su propia ventana de contexto. Cada uno ejecuta su tarea y reporta al padre. El detalle crítico: los sub-agentes no pueden hablar entre sí. Reportan hacia arriba al orquestador, punto. Si el Agente A descubre que el esquema de la base de datos necesita una nueva columna, el Agente B no lo sabrá a menos que transmitas esa información manualmente.

Los equipos de agentes agregan una capa de comunicación sobre esto. Los compañeros de equipo pueden enviarse mensajes directamente entre sí. El agente de front-end puede preguntarle al agente de back-end "¿qué formato devuelve el endpoint /users?" y obtener una respuesta sin pasar por el orquestador. Un agente actúa como líder del equipo — coordinando, delegando, sintetizando — mientras los compañeros trabajan de forma independiente pero se mantienen conectados mediante el paso de mensajes.

Esta es la analogía que finalmente me hizo entenderlo: los sub-agentes son como el email. Envías instrucciones, te devuelven resultados. Los equipos de agentes son como Slack. Todos están en el mismo canal, los mensajes fluyen en tiempo real y el líder del proyecto mantiene todo en orden.

Las implicaciones son prácticas e inmediatas. Los sub-agentes funcionan perfectamente para tareas que son genuinamente independientes — ejecutar linting, generar documentación, crear scaffolding de tests. No se necesita coordinación, no se comparte contexto, no se intercambian mensajes. Rápido y barato.

Los equipos de agentes brillan cuando el trabajo es interdependiente. Cuando el front-end necesita conocer el contrato de la API antes de construir las llamadas fetch. Cuando el agente de QA necesita la estructura real de los componentes para escribir tests significativos. Cuando un cambio en el esquema de la base de datos debería propagarse al entendimiento del sistema de cada agente.

A continuación te explico el proceso exacto de configuración, pero esta distinción debería informar cada decisión que tomes de aquí en adelante. Si tus tareas no necesitan coordinación, los equipos de agentes son una forma costosa de hacer algo que los sub-agentes resuelven por una fracción del precio.

La configuración completa: de cero a equipo funcionando

Los equipos de agentes todavía están marcados como experimentales en Claude Code a marzo de 2026. Eso significa que tienes que optar por activarlos, y el comportamiento de la funcionalidad puede cambiar entre versiones. Esta es la secuencia exacta que sigo en una configuración desde cero.

Paso 1: Activa la flag experimental

Abre tu archivo de configuración de Claude Code. En macOS, está en ~/.claude/settings.json. Agrega la flag experimental de equipos de agentes:

{
  "experimental": {
    "agentTeams": true
  }
}

También puedes establecer la variable de entorno CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 si prefieres no tocar el archivo de configuración. Yo uso el archivo de configuración porque persiste entre sesiones de terminal sin contaminar mi perfil de shell.

Paso 2: Elige tu modo de visualización

Esta decisión tiene un impacto mayor en tu flujo de trabajo del que esperarías. Los equipos de agentes soportan dos modos de renderizado:

El modo de paneles divididos con tmux le da a cada compañero de equipo su propio panel de terminal. Ves a todos los agentes trabajando simultáneamente, lado a lado. Puedes hacer clic en cualquier panel e interactuar directamente con ese agente específico. Esta es mi configuración preferida para proyectos complejos — la retroalimentación visual es invaluable.

Requisitos: tmux instalado (brew install tmux en macOS), y debes lanzar Claude Code desde dentro de una sesión de tmux. Empieza con tmux new -s dev, luego lanza Claude Code dentro de esa sesión.

El modo in-process ejecuta todo dentro de una sola ventana de terminal. La salida de los compañeros de equipo aparece en línea, e interactúas con los agentes a través del líder. Menos carga visual, funciona en todas partes, pero más difícil de seguir lo que cada agente está haciendo en tiempo real.

Configura esto en tus ajustes:

{
  "teammateMode": "tmux"
}

Las opciones son "tmux", "in-process" o "auto" (que por defecto usa tmux si detecta una sesión de tmux, in-process en caso contrario).

Un problema que me atrapó: el modo de paneles divididos no funciona en la terminal integrada de VS Code, Windows Terminal ni Ghostty. Si estás usando alguno de esos, quédate con in-process o cambia a una terminal independiente. Yo uso iTerm2, que también soporta paneles divididos de forma nativa a través de su Python API — instala el CLI it2 y activa la Python API en la configuración de iTerm2.

Paso 3: Define los roles del equipo usando lenguaje natural

Aquí es donde los equipos de agentes se diferencian de los frameworks de orquestación tradicionales. No escribes archivos de configuración para cada agente. Le describes tu equipo al agente líder en español (o inglés) simple.

Este es un prompt real que usé para un proyecto SaaS reciente:

I need a team of 4 agents for this project:

1. Lead (you) - Architecture decisions, task delegation, integration review
2. Frontend specialist - React, TypeScript, Tailwind, component architecture
3. Backend specialist - Node.js, Express, PostgreSQL, API design
4. QA specialist - Testing, validation, integration checks

Rules:
- Frontend and backend must agree on API contracts before building
- QA writes tests only after receiving the actual implementation
- Nobody touches files outside their domain without lead approval

El agente líder crea compañeros de equipo basándose en tu descripción. Cada compañero recibe su propia ventana de contexto (aproximadamente 200K tokens a partir de Opus 4.6) y su especialidad asignada.

Paso 4: Asigna modelos estratégicamente

Este es el mayor punto de control de costos que tienes. No todos los agentes necesitan Opus 4.6. Mi asignación estándar de modelos:

Un equipo de cuatro agentes todos con Opus cuesta aproximadamente 4 veces lo que cuesta un equipo con modelos mixtos. La diferencia de calidad para tareas de nivel de ejecución — escribir componentes React, construir endpoints CRUD, crear scaffolding de tests — es insignificante entre Opus y Sonnet. Guarda Opus para el razonamiento que realmente lo requiere.

Paso 5: Planifica antes de ejecutar

Esto es innegociable. Antes de que el equipo escriba una sola línea de código, usa el modo de planificación para mapear el trabajo. El modo de planificación es barato — es un agente pensando en el enfoque. El modo de ejecución con un equipo completo es caro — son cuatro agentes consumiendo tokens en paralelo.

Mi flujo de trabajo: activo el modo de planificación con el agente líder, obtengo un desglose completo de tareas y un plan de arquitectura, lo reviso, lo ajusto, y solo entonces cambio a ejecución con el equipo completo. Esto crea un punto de control antes de comprometer tokens reales.

Piénsalo así: el modo de planificación es el plano arquitectónico. La ejecución del equipo de agentes es la cuadrilla de construcción. No enviarías una cuadrilla a una obra sin planos. Mismo principio, diferente medio.

Más de 30 consejos que me ahorraron miles en tokens

He estado recopilando estos desde febrero. Algunos vienen de mis propios errores costosos. Otros de patrones que noté en docenas de proyectos. Los agrupé por categoría porque una lista plana de 30 elementos es imposible de aplicar.

Composición del equipo

1. Empieza con 3 agentes, no 5. La sobrecarga de coordinación entre agentes escala de forma no lineal. Tres agentes pueden coordinarse eficientemente. Cinco agentes gastan un porcentaje significativo de sus tokens solo hablando entre sí. Empiezo cada proyecto con tres y solo agrego un cuarto si la carga de trabajo claramente lo exige.

2. Cada agente necesita un límite de dominio claro. "Agente de front-end" es claro. "Agente ayudante" no lo es. Si no puedes describir el dominio de un agente en una oración, el rol no está lo suficientemente definido y el agente se desviará al territorio de otros agentes.

3. El agente líder debería ser tu modelo más caro. El líder toma decisiones arquitectónicas, resuelve conflictos entre compañeros de equipo y mantiene la visión holística del proyecto. Ahorrar en razonamiento aquí causa errores costosos en todas las demás partes.

4. Empareja la capacidad del modelo con la complejidad de la tarea. Escribir tests unitarios no requiere razonamiento de nivel Opus. Diseñar un esquema de base de datos con relaciones complejas sí. Asigna modelos según la demanda cognitiva del rol, no con un enfoque genérico de "todo recibe el mejor modelo".

5. No crees un equipo para trabajo secuencial. Si la Tarea B no puede empezar hasta que la Tarea A termine, no necesitas dos agentes — necesitas un agente haciendo dos cosas. Los equipos de agentes rinden cuando las tareas pueden ejecutarse en paralelo.

Planificación de tareas

6. Limita las tareas a 5-6 por agente. He descubierto que este es el punto óptimo. Menos de 3 y estás subutilizando al agente. Más de 7 y el agente pierde el hilo de su propio progreso, empieza a repetir trabajo o se olvida de decisiones anteriores.

7. Escribe las descripciones de tareas como si estuvieras informando a un contratista nuevo. Incluye qué construir, qué restricciones aplican, qué archivos tocar y qué archivos evitar. Las tareas ambiguas producen resultados ambiguos — y esos resultados cuestan tokens de arreglar.

8. Define criterios de éxito para cada tarea. "Construye el sistema de auth" es vago. "Construye auth basada en JWT con refresh tokens, devolviendo un 401 para tokens expirados y soportando acceso basado en roles para los roles admin/user/viewer" le dice al agente exactamente cuándo ha terminado.

9. Planifica los puntos de integración antes de dividir el trabajo. El agente líder debería producir un contrato compartido — esquemas de API, modelos de base de datos, definiciones de tipos, formatos de eventos — antes de que cualquier compañero de equipo empiece a construir. Esto elimina la mayoría de los problemas de integración.

10. Carga el pensamiento al principio, la construcción al final. Dedica el 20% de tu sesión a planificar y el 80% a ejecutar. La mayoría de la gente invierte esta proporción y lo paga en retrabajo.

Comunicación y contexto

11. El intercambio de contexto se limita al paso de mensajes. Los agentes no comparten memoria ni ventanas de contexto. Si el Agente A descubre algo que el Agente B necesita saber, esa información debe enviarse explícitamente como mensaje. Nada es automático.

12. Alimenta a los compañeros de equipo con contexto crítico desde el inicio. Cuando defines los roles del equipo, incluye las decisiones arquitectónicas clave, el stack tecnológico y las restricciones en el prompt inicial. Cada token gastado en contextualización inicial ahorra diez tokens en comportamiento confuso del agente después.

13. Establece protocolos de comunicación explícitos. No dejes que los agentes se envíen mensajes libremente. Define puntos de traspaso: "El agente de front-end envía las expectativas de API al agente de back-end antes de escribir las llamadas fetch". "El agente de back-end comparte el contrato final del endpoint con QA antes de que se escriban los tests". La estructura previene el ruido.

14. Usa el agente líder como enrutador, no como cuello de botella. El líder debería delegar y revisar, no retransmitir cada mensaje entre compañeros de equipo. La mensajería directa entre agentes existe por una razón — si toda la comunicación pasa por el líder, has recreado el modelo de sub-agentes pero con más sobrecarga.

15. Mantén los mensajes entre agentes concisos. Un agente enviando toda su salida de código a otro agente desperdicia tokens en ambos lados. Los mensajes deberían contener decisiones, contratos y definiciones de interfaz — no implementaciones completas.

Gestión de archivos y conflictos

16. Nunca dejes que dos agentes editen el mismo archivo simultáneamente. Este es el error que me costó $47 en diecinueve minutos. Los conflictos de archivos en equipos de agentes son silenciosos — no hay diálogo de conflicto de merge. Un agente simplemente sobrescribe el trabajo de otro. Asigna la propiedad de archivos explícitamente.

17. Crea un mapa de propiedad de archivos. Antes de que empiece la ejecución, el agente líder debería producir un mapeo claro: "El agente de front-end es dueño de todo en /src/components y /src/hooks. El agente de back-end es dueño de /src/api y /src/db. QA es dueño de /tests." Las zonas grises causan colisiones.

18. Usa un directorio compartido de tipos o contratos. Yo creo un directorio /src/shared o /src/contracts del cual ambos agentes de front-end y back-end leen pero solo el agente líder escribe. Esto previene la divergencia de contratos.

19. Si un agente necesita modificar un archivo de otro agente, pasa por el líder. El líder revisa el cambio, confirma que no genera conflicto, y o bien hace el cambio él mismo o aprueba explícitamente al agente solicitante para que proceda. Esto agrega unos segundos de latencia pero previene minutos de debugging.

Control de costos

20. Monitorea el uso de tokens activamente, no pasivamente. No esperes a que la sesión termine para revisar tu factura. Claude Code muestra el consumo de tokens en tiempo real. Si un agente está quemando tokens más rápido de lo esperado, algo está mal — probablemente está atrapado en un loop o generando salida excesiva.

21. Cierra los agentes inactivos inmediatamente. Un agente que ha terminado sus tareas pero sigue corriendo aún consume recursos. El orquestador maneja la limpieza, pero he visto agentes quedarse inactivos por minutos antes de ser terminados. El cierre manual es más rápido y barato.

22. Usa sub-agentes para tareas independientes, equipos para interdependientes. No puedo enfatizar esto lo suficiente. Ejecutar cuatro agentes coordinándose para hacer cuatro tareas independientes es como programar una reunión que podría haber sido cuatro emails. Usa sub-agentes para trabajo aislado. Reserva los equipos de agentes para trabajo que genuinamente requiere coordinación.

23. Agrupa tareas relacionadas. En lugar de crear un nuevo agente para cada tarea pequeña, agrupa tareas relacionadas bajo un agente. Un agente manejando "construir los tres endpoints de API para gestión de usuarios" es más eficiente que tres agentes construyendo cada uno un endpoint.

24. Haz un estimado de costos antes de comprometerte. Cálculo rápido: un equipo de 3 agentes corriendo durante 30 minutos en Opus 4.6 consume aproximadamente 200K-300K tokens. Al precio actual, eso son $15-25. En un equipo con modelos mixtos (un Opus, dos Sonnet), la misma sesión cuesta $6-10. Conoce tus números antes de empezar.

Monitoreo y dirección

25. Revisa cada 10-15 minutos. Los equipos de agentes no son de configurar y olvidar. Reviso el progreso a intervalos regulares, detecto desvíos temprano y ajusto las asignaciones de tareas si un agente está bloqueado mientras otro está inactivo.

26. Puedes interactuar directamente con cualquier compañero de equipo. En el modo de paneles divididos de tmux, haz clic en el panel de un agente y dale instrucciones directas. No estás limitado a hablar a través del líder. Cuando noto que un agente específico va en la dirección incorrecta, intervengo directamente en lugar de retransmitir la corrección a través del orquestador.

27. Usa hooks para eventos del ciclo de vida. Claude Code soporta hooks que se disparan cuando los compañeros de equipo quedan inactivos, completan tareas o encuentran errores. Yo los conecté a notificaciones de Slack para que me avise cuando un agente termina o se atasca — sin necesidad de estar mirando la terminal constantemente.

28. Cuidado con los loops infinitos. Ocasionalmente, dos agentes entrarán en un patrón de ping-pong — el Agente A le hace una pregunta al Agente B, el Agente B responde con otra pregunta, y entran en loop. Si ves el consumo de tokens dispararse sin progreso visible, intervén inmediatamente.

Ciclo de vida y limpieza

29. Los agentes se detienen automáticamente cuando su cola de tareas se vacía. El orquestador gestiona el apagado, pero el timing no siempre es inmediato. Si ya terminaste con la sesión, dile explícitamente al agente líder que cierre.

30. Un equipo por sesión. Un agente líder solo puede gestionar un equipo a la vez. Si necesitas una composición de equipo diferente para un proyecto diferente, inicia una nueva sesión.

31. Los compañeros de equipo no pueden crear sus propios equipos. La jerarquía es plana: un líder, múltiples compañeros. Sin sub-equipos, sin orquestación recursiva. Si tu proyecto necesita ese nivel de anidamiento, probablemente te conviene más tener múltiples sesiones independientes.

32. Limpia los procesos de agentes después de crashes. Si una sesión se cae a mitad de equipo, los procesos huérfanos de agentes pueden quedarse corriendo. Busca procesos inactivos y termínalos manualmente. Esto evita tanto el desperdicio de recursos como posibles conflictos cuando inicies una nueva sesión.

33. Documenta lo que funcionó. Después de cada sesión de equipo, dedico dos minutos a anotar qué asignaciones de modelos, tamaños de equipo y patrones de comunicación funcionaron mejor para ese tipo de proyecto. Esta biblioteca de plantillas ahora me permite armar equipos optimizados en menos de tres minutos.

Seis casos de uso donde los equipos de agentes superan a los agentes individuales

La teoría está bien. Lo que realmente importa es saber cuándo recurrir a esta herramienta. Después de más de treinta proyectos, estos seis escenarios justifican consistentemente la sobrecarga de coordinación.

1. Desarrollo de aplicaciones full-stack

Este es el caso de uso canónico, y realmente cumple. Tres agentes — líder de arquitectura, especialista en front-end, especialista en back-end — trabajando en paralelo en un codebase compartido. El líder produce el contrato de API primero, ambos agentes de implementación construyen contra ese contrato simultáneamente, y los problemas de integración se detectan a través de mensajería entre agentes en lugar de debugging después del hecho.

En un proyecto reciente — un dashboard multi-tenant con acceso basado en roles y actualizaciones en tiempo real con WebSocket — el equipo de agentes entregó en 35 minutos lo que a un agente solo le habría tomado cerca de 90 minutos. No porque los agentes escribieran más rápido, sino porque el agente de front-end estaba construyendo componentes mientras el agente de back-end estaba construyendo endpoints. Verdadera ejecución paralela en trabajo interdependiente.

La clave: el patrón de contrato primero que describí en el consejo #9 es obligatorio aquí. Sin un contrato de API compartido, los agentes construyen sobre suposiciones que divergen inmediatamente.

2. Code review con enfoques especializados

Este caso de uso me sorprendió por lo bien que funciona. Asigna tres agentes a revisar el mismo PR, cada uno con un enfoque diferente: vulnerabilidades de seguridad, cuellos de botella de rendimiento y brechas en la cobertura de tests. Cada agente examina el código a través de su lente especializado y produce un reporte enfocado. El agente líder sintetiza los tres reportes en una sola revisión.

El resultado es más exhaustivo que cualquier revisión de una sola pasada, y el enfoque especializado significa que cada agente detecta cosas que un generalista pasaría por alto. Un agente enfocado en seguridad detectó un vector de SQL injection en una consulta parametrizada que a primera vista parecía correcta — el escape de parámetros no manejaba entradas de tipo array. Un agente enfocado en rendimiento detectó una consulta N+1 oculta detrás de una abstracción del ORM. Ninguno de los dos hallazgos habría salido a la luz en una revisión estándar.

El costo de un code review con tres agentes ronda los $3-5 en tokens. Para PRs críticos, es una ganga.

3. Debugging con hipótesis competidoras

Cuando un bug tiene múltiples causas raíz posibles, el enfoque tradicional es secuencial: investigar la hipótesis A, si no es esa, probar la hipótesis B. Los equipos de agentes te permiten investigar todas las hipótesis simultáneamente.

Tuve un problema en producción donde los tiempos de respuesta de la API se disparaban de 200ms a 3 segundos cada pocas horas. Tres posibles causas: agotamiento del pool de conexiones a la base de datos, fuga de memoria en un worker de background, o un servicio upstream aplicando throttling. Asigné cada hipótesis a un agente diferente y los dejé investigar en paralelo. Veinte minutos después, el Agente C encontró el throttling del upstream — un rate limit en una API de geocoding que nadie había documentado. Los otros dos agentes no encontraron evidencia para sus hipótesis, lo cual fue igualmente valioso porque eliminó dos días de potencial búsqueda infructuosa.

4. Flujos de trabajo de escritura y edición

Este se mapea directamente al pipeline de contenido que uso para este blog. Tres agentes con roles distintos: investigador (recopila fuentes, datos, información actual), escritor (produce el borrador siguiendo la voz de marca y la estructura) y editor (revisa calidad, precisión, consistencia y SEO).

El investigador termina primero y pasa sus hallazgos al escritor. El escritor produce el borrador y se lo entrega al editor. El editor revisa y envía notas de revisión de vuelta. Este flujo secuencial con comunicación produce una salida notablemente mejor que un solo agente intentando investigar, escribir y auto-editarse simultáneamente — porque cada agente se enfoca en una tarea cognitiva sin cambio de contexto.

5. Investigación y exploración en paralelo

Cuando necesitas evaluar múltiples herramientas, enfoques o arquitecturas antes de tomar una decisión, los equipos de agentes te permiten explorar todos los caminos simultáneamente. Usé esto cuando evaluaba tres enfoques diferentes de gestión de estado para un proyecto React — un agente probó Zustand, otro probó Jotai, otro probó la API nativa de React Context. Cada agente construyó una pequeña prueba de concepto, documentó las ventajas y desventajas, y reportó al líder.

La regla crítica para tareas de investigación: mantén a los agentes en modo solo lectura durante la fase de exploración. Deja que lean código, ejecuten benchmarks y escriban prototipos desechables — pero no les permitas modificar el codebase principal hasta que el líder haya revisado los hallazgos y elegido una dirección. De lo contrario, terminas con tres enfoques diferentes a medio implementar en tu código de producción.

6. Paridad de funcionalidades cross-platform

Si estás lanzando la misma funcionalidad en múltiples plataformas — iOS y Android, web y mobile, o incluso diferentes microservicios que necesitan comportamiento sincronizado — los equipos de agentes mantienen la paridad haciendo que cada agente de plataforma comparta los detalles de su implementación con los demás. Cuando el agente de Android implementa una utilidad de formato de fechas, le envía un mensaje al agente de iOS con el string de formato exacto para que ambas plataformas produzcan una salida idéntica.

Solo he usado esto dos veces, pero ambas veces detectó divergencias que se habrían convertido en bugs visibles para el usuario. La sobrecarga de coordinación es alta para este patrón, así que solo lo recomiendo para funcionalidades donde la inconsistencia entre plataformas sería un problema serio — flujos de pago, serialización de datos, cualquier cosa donde "comportamiento ligeramente diferente en iOS vs Android" significa un ticket de soporte.

Las fases del flujo de trabajo: cómo se desarrolla realmente una sesión

Para quienes quieran ver el panorama de principio a fin, así es como fluye una sesión típica de equipo de agentes de inicio a final. Usaré un ejemplo real — construir una herramienta interna para rastrear el estado del pipeline de contenido.

Fase 1 — Inicialización. Abro una sesión de tmux, lanzo Claude Code y verifico que la flag experimental de agentes esté activa. Le describo el proyecto al agente líder en detalle: el stack tecnológico (Next.js 15, Prisma, PostgreSQL), los requisitos (dashboard mostrando estado del contenido, asignaciones de autores, fechas de publicación) y las restricciones (debe integrarse con el sistema de auth existente, no debe modificar el esquema de base de datos compartido).

Fase 2 — Creación del equipo. Le digo al agente líder qué equipo necesito. En este caso: un agente de front-end para la UI del dashboard, un agente de back-end para la capa de API y consultas a la base de datos, y un agente de QA. El líder crea tres compañeros de equipo, cada uno apareciendo en su propio panel de tmux. Puedo ver los cuatro agentes simultáneamente.

Fase 3 — Planificación de tareas. Antes de que nadie escriba código, el agente líder produce un plan de tareas. Detalla cada entregable, asigna tareas a agentes específicos, define el contrato de API entre front-end y back-end, y establece los criterios de tests de integración. Reviso este plan, ajusto dos asignaciones de tareas que no tenían sentido y apruebo.

Fase 4 — Ejecución en paralelo. Los agentes se ponen a trabajar. El front-end empieza a construir los componentes del dashboard. El back-end crea el esquema de Prisma y las rutas de API. Puedo ver el progreso de ambos agentes en tiempo real a través de los paneles de tmux. Cuando el agente de front-end necesita aclaración sobre la forma de respuesta del endpoint /content, le envía un mensaje directamente al agente de back-end.

Fase 5 — Monitoreo y dirección. Aproximadamente a los doce minutos, noto que el agente de front-end está construyendo un componente de filtro complejo que no estaba en la especificación. Hago clic en su panel y lo redirijo: "Salta los filtros avanzados por ahora. Concéntrate en el tablero de estado y la vista de autores." El agente se ajusta inmediatamente.

Fase 6 — Integración y QA. Una vez que ambos agentes de implementación señalan que terminaron, el agente de QA se activa. Lee los componentes de front-end y los endpoints de back-end, escribe tests de integración y los ejecuta. Dos fallos: un desajuste en el formato de fechas y un error boundary faltante. El agente de QA reporta estos al agente correspondiente, quienes los arreglan en menos de dos minutos.

Fase 7 — Resumen y limpieza. El agente líder compila un resumen: qué se construyó, qué tests pasan, qué queda pendiente. Reviso la salida, confirmo que todo funciona y cierro la sesión. Tiempo total: 28 minutos. Costo total en tokens con la configuración de modelos mixtos: aproximadamente $8.

Toda la secuencia se sintió menos como "usar una herramienta" y más como gestionar un pequeño equipo de desarrollo. Lo cual, en un sentido significativo, es exactamente lo que es.

Las compensaciones honestas de las que nadie habla

Te haría un mal servicio si pintara los equipos de agentes como universalmente superiores. No lo son. Esto es lo que he aprendido sobre sus limitaciones reales después de meses de uso diario.

El costo escala linealmente, pero el valor no. Tres agentes cuestan tres veces más que uno. Pero no siempre entregan tres veces el valor. Para proyectos de complejidad moderada — la mayoría de apps CRUD, la mayoría de herramientas de una sola página, la mayoría de scripts — un agente solo es más rápido, más barato y produce una salida más fácil de depurar porque un solo cerebro la escribió.

El paso de mensajes no es intercambio gratuito de contexto. Los agentes pueden enviarse mensajes entre sí, pero esos mensajes consumen tokens tanto del lado del emisor como del receptor. La comunicación intensa entre agentes puede costar más que la programación en sí. He visto sesiones donde el 30% del uso total de tokens fue mensajería entre agentes.

El orquestador es un punto único de fallo. Si el agente líder se confunde sobre el estado del proyecto — y pasa — todo el equipo se desvía. La ventana de contexto del líder es finita, y rastrear el estado del trabajo de cinco compañeros de equipo a través de docenas de tareas puede abrumar incluso a Opus 4.6. Por eso limito los equipos a 3-4 agentes y las tareas a 5-6 por agente.

Depurar la salida de un equipo es más difícil que depurar la salida de un solo agente. Cuando algo falla en la salida de un agente solo, sabes quién lo escribió. Cuando algo falla en la salida de un equipo, necesitas rastrear qué agente produjo el código problemático, qué contexto tenía cuando tomó esa decisión, y si el mensaje de otro agente influyó en la elección. El radio de impacto de un error es mayor.

La funcionalidad todavía es experimental. La reanudación de sesiones no es confiable. El apagado de compañeros de equipo no siempre ocurre limpiamente. La indexación de paneles de tmux puede fallar si tu configuración usa índices base no predeterminados. Estos son bordes ásperos, y vale la pena tolerarlos para proyectos complejos — pero significan que los equipos de agentes aún no son herramientas de nivel producción. Son una funcionalidad avanzada para personas dispuestas a manejar la fricción.

Esta es mi posición honesta después de tres meses: los equipos de agentes son la elección correcta para quizás el 15-20% de los proyectos en los que trabajo. Pero para ese 15-20%, son dramáticamente mejores que la alternativa. La habilidad está en saber cuál es ese 15-20%.

Si prefieres que alguien construya y configure este tipo de flujo de trabajo multi-agente para tu proyecto, acepto encargos personalizados de automatización con IA. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Cómo empezaría si estuviera configurando esto hoy

Si pudiera volver a febrero y darme un plan de cinco pasos, esto es lo que me entregaría.

Primera sesión: agente solo, solo modo de planificación. No toques los equipos de agentes. Construye tu plan de proyecto con una sola instancia de Claude Code. Define bien la arquitectura, establece los contratos de API, mapea la estructura de archivos. Esto no cuesta casi nada y produce el plano que tu equipo ejecutará.

Segunda sesión: dos agentes, una tarea pequeña. Crea un líder y un compañero de equipo. Dales una pieza contenida y de bajo riesgo del proyecto — una sola funcionalidad con límites claros. Observa cómo fluye la comunicación. Aprende la interfaz de tmux. Acostúmbrate al ritmo.

Tercera sesión: tres agentes, trabajo real. Ahora sabes lo suficiente para ser efectivo. Líder en Opus, dos compañeros en Sonnet, límites de dominio claros, contratos compartidos, 5-6 tareas por agente. Esta es tu configuración de producción para el 90% de los proyectos que ameritan un equipo.

Cada sesión después de esa: refina tus plantillas. Documenta qué asignaciones de modelos, tamaños de equipo y patrones de comunicación funcionan para cada tipo de proyecto. Después de diez sesiones, tendrás una biblioteca de plantillas de equipo que hace que la configuración sea casi instantánea.

Lo único que cambiaría: empezaría leyendo la documentación oficial de Anthropic sobre equipos de agentes en code.claude.com/docs/en/agent-teams en lugar de aprender por ensayo y error. La documentación es genuinamente buena — simplemente no existía cuando empecé a experimentar.

El mayor cambio en mi pensamiento durante estos tres meses no es sobre la tecnología. Es sobre el rol. Cuando uso equipos de agentes, dejo de ser un desarrollador que usa IA y empiezo a ser un líder técnico que gestiona desarrolladores de IA. Las habilidades que importan cambian: escritura clara de requisitos, descomposición de tareas, monitoreo de progreso, planificación de integración. Las mismas habilidades que hacen a un buen engineering manager hacen a un buen operador de equipos de agentes.

Tu terminal ya no es un editor de texto. Es un centro de mando. Y los agentes están esperando órdenes.

Preguntas frecuentes

¿Cómo activo los equipos de agentes en Claude Code?

Agrega "agentTeams": true a la sección "experimental" de ~/.claude/settings.json, o establece la variable de entorno CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Necesitas una suscripción Claude Pro o Max con acceso a Opus 4.6 para el rol de agente líder.

¿Cuántos agentes debería usar en un equipo de Claude Code?

Empieza con 3 compañeros de equipo para la mayoría de los proyectos — un líder, dos especialistas. Tres agentes equilibran el rendimiento en paralelo con la sobrecarga de coordinación. Los equipos de 5 o más gastan una cantidad desproporcionada de tokens en mensajería entre agentes. Para un desglose más detallado, consulta los consejos de Composición del equipo más arriba.

¿Los equipos de agentes de Claude Code cuestan más que los sub-agentes?

Sí. Un equipo de 3 agentes usa aproximadamente 3-4 veces los tokens de una sola sesión haciendo el mismo trabajo. Puedes reducir costos asignando modelos más baratos (Sonnet 4.5 o Haiku) a los compañeros de equipo enfocados en ejecución mientras mantienes Opus en el líder. Los equipos de agentes solo son rentables cuando la complejidad del proyecto genuinamente demanda coordinación en tiempo real.

¿Pueden los compañeros de equipo de Claude Code editar el mismo archivo?

Pueden, pero absolutamente no deberían. Los equipos de agentes no tienen detección de conflictos de merge — un agente sobrescribe silenciosamente los cambios de otro. Asigna la propiedad explícita de archivos a cada agente antes de que empiece la ejecución, y dirige cualquier cambio de archivos entre dominios a través del agente líder.

¿Cuál es la diferencia entre equipos de agentes y sub-agentes en Claude Code?

Los sub-agentes son trabajadores aislados que reportan resultados de vuelta a la sesión padre — sin comunicación entre agentes. Los equipos de agentes agregan paso directo de mensajes entre compañeros de equipo, habilitando coordinación en tiempo real en tareas interdependientes. Usa sub-agentes para trabajo paralelo independiente, equipos de agentes para trabajo colaborativo que requiere contexto compartido.

Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (builds e integraciones personalizadas): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io