Claude Code Agent Teams: La Guía Que Me Tomó Semanas Crear

Claude Code Agent Teams: La Guía Que Me Tomó Semanas Crear

El agente de QA encontró once bugs. Once. En la primera pasada. Acababa de ver a otros dos agentes — un desarrollador front-end y un desarrollador back-end — pasar cuatro minutos construyendo una landing page para una startup de AI ficticia llamada Neuroflow. Texto, animaciones, esquemas de colores, diseño responsive, API endpoints. Todo ejecutándose en paralelo, cada agente trabajando en su propia sesión de Claude Code mientras yo observaba cómo la terminal se dividía en paneles codificados por colores. El agente front-end entregó su trabajo. El agente back-end entregó su trabajo. Entonces el agente de QA los destrozó a ambos. Hover states faltantes. Un API endpoint devolviendo datos en un formato que el front-end no esperaba. Una relación de contraste de color que no cumplía los estándares WCAG. Una animación que se disparaba antes de que el contenido se cargara, causando un destello de texto sin estilos. Esta es la parte que me dejó helado: no tuve que hacer nada. El agente de QA reportó sus hallazgos, etiquetó a los agentes responsables, y ambos desarrolladores tomaron las correcciones de inmediato. En la segunda pasada, QA aprobó todo. La landing page final parecía como si un pequeño equipo de diseño hubiera dedicado una semana a ella. Ese fue el momento en que entendí lo que realmente son los Claude Code agent teams. No una función. No una configuración que activas o desactivas. Una forma fundamentalmente diferente de construir software con AI — una donde los agentes no solo ejecutan tareas, sino que colaboran, discuten y se exigen responsabilidad mutuamente. Y llegar a ese momento requirió semanas de experimentación dolorosa que estoy a punto de comprimir en este artículo. Porque esto es lo que nadie te dice sobre los agent teams: la función es fácil de activar. ¿Lograr que produzca resultados como los que acabo de describir? Ahí es donde la mayoría fracasa. La diferencia entre un agent team bien orquestado y una hoguera caótica de tokens se reduce a cómo haces tus prompts, cómo estructuras los roles y cómo manejas las docenas de cosas que pueden salir mal. He quemado más tokens descifrando esto de lo que me gustaría admitir. Esta es la guía que desearía que hubiera existido cuando empecé.

Por qué existen los Agent Teams (y por qué los Sub Agents no son suficientes)

Si has usado los sub agents de Claude Code, ya conoces la propuesta: iniciar agentes independientes, dejarlos trabajar en paralelo, recoger resultados. Rápido, económico, efectivo para tareas delimitadas. Sigo usando sub agents a diario para cosas como "analiza este codebase y lista cada API endpoint" o "escribe tests unitarios para este módulo." Son perfectos cuando el trabajo es aislado. El problema aparece en el momento en que el trabajo no es aislado. Aprendí esto de la manera costosa mientras construía una aplicación de dashboard. Un sub agent se encargó del front-end en React. Otro construyó la API en Express. Un tercero escribió la capa de base de datos. Los tres se ejecutaron simultáneamente — y los tres tomaron decisiones independientes que se contradecían entre sí. El agente front-end esperaba respuestas paginadas. El agente de API devolvía todo en un solo payload. El agente de base de datos construyó queries optimizadas para un patrón de paginación del que ninguno de los otros agentes tenía conocimiento. Tres piezas brillantes de software que no podían comunicarse entre sí. Pasé más tiempo ensamblándolas de lo que los agentes tardaron en construirlas. Los sub agents son paralelos pero sordos. No pueden hacerse preguntas entre sí. No pueden negociar un contrato de API. No pueden decir "aviso, cambié el formato de respuesta del endpoint /users." Cada uno opera en un context window sellado, reporta al agente principal, y eso es todo. El agente principal se convierte en un cuello de botella — cada pieza de coordinación tiene que pasar por él. Los agent teams resuelven esto con una arquitectura completamente diferente. Tres componentes lo hacen funcionar: El líder del equipo — tu sesión principal de Claude Code. Comprende el panorama completo, descompone la misión, asigna dominios y coordina la integración. Piensa en él como el tech lead que no escribe todo el código pero se asegura de que todos estén construyendo el mismo producto. Los compañeros de equipo — instancias separadas de Claude Code, cada una con su propio context window completo. Se ejecutan en paralelo y son dueños de dominios específicos. El agente front-end solo piensa en asuntos del front-end. El agente back-end se enfoca completamente en la lógica de API. Sin contaminación de contexto entre ellos. Mensajería directa — y esta es la diferencia crítica. Los compañeros de equipo pueden comunicarse entre sí sin enrutar todo a través del líder del equipo. El agente front-end puede preguntar directamente al agente back-end: "¿Qué formato usa la respuesta de /users?" El agente back-end responde. El trabajo continúa. Sin cuello de botella. Cuando vi esto funcionando por primera vez, la comparación que me vino a la mente no fue técnica — fue organizacional. Los sub agents son como enviar emails a tres freelancers en tres países diferentes. Los agent teams son como poner a esos freelancers en un canal de Slack juntos. Mismo talento, capacidad de coordinación radicalmente diferente. Pero más coordinación también significa más complejidad, más tokens y más formas de arruinarlo. La configuración importa enormemente — y la mayoría de las guías que he leído se saltan las partes que realmente determinan el éxito o el fracaso.

Configurando Agent Teams: La configuración que realmente funciona

Los agent teams son experimentales a marzo de 2026 y están desactivados por defecto. Anthropic lanzó esto como una preview de investigación con Claude Code v2.1.32, lo que te dice dos cosas: es lo suficientemente potente como para lanzarlo, y lo suficientemente bruto como para que quieran que sepas en lo que te estás metiendo. Paso 1: Activa la función. Abre el settings.local.json de tu proyecto (o tu archivo global de configuración de Claude Code) y añade esto:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Reinicia Claude Code. Eso es todo para la configuración técnica. El feature flag le da a Claude acceso a herramientas de coordinación de equipo — crear compañeros de equipo, asignar tareas, enviar mensajes entre agentes y gestionar una lista de tareas compartida. Paso 2: Instala tmux (muy recomendado). No necesitas tmux estrictamente, pero ejecutar agent teams sin tmux es como conducir sin tablero de instrumentos. Tmux te permite ver la sesión de terminal de cada agente simultáneamente — codificada por colores según el rol, actualizándose en tiempo real. En macOS:

brew install tmux

Cuando los agent teams están activos y tmux está instalado, Claude Code divide automáticamente tu terminal en paneles para cada compañero de equipo. Puedes ver al agente front-end escribiendo JSX en un panel mientras el agente back-end configura rutas de Express en otro. Es genuinamente fascinante y prácticamente útil — puedes detectar fallos de coordinación mientras suceden en lugar de descubrirlos en el resultado final. Paso 3: Entrena tu proyecto de Claude Code. Este es el paso que la mayoría de los tutoriales omiten, y es el que marcó la mayor diferencia para mí. Antes de ejecutar tu primer agent team, importa la documentación de agent teams en el contexto de tu proyecto. Extraje los conceptos clave de la documentación de agent teams de Anthropic al archivo CLAUDE.md de mi proyecto — específicamente las secciones sobre reglas de propiedad de archivos, protocolos de comunicación y gestión de dependencias de tareas. ¿Por qué importa esto? Cuando Claude genera compañeros de equipo, cada uno comienza con un contexto fresco. No conocen automáticamente las mejores prácticas para la coordinación de agent teams. Pero si esas prácticas están en tu CLAUDE.md, cada compañero las lee al inicializarse. La diferencia en la calidad de coordinación es inmediata y dramática. Esta es la sección que añadí a mi CLAUDE.md:

## Agent Team Rules
- Each teammate owns specific files. Never modify files owned by another agent.
- Always communicate API contracts before implementation begins.
- QA agent must receive final output from all other agents before running checks.
- Save progress to temporary files after each major milestone.

Cuatro líneas. Previenen aproximadamente el 80% de los fallos de coordinación que encontré en mis primeras dos semanas. Paso 4: Pre-aprueba los comandos comunes. Los compañeros del agent team heredan permisos de la sesión principal. Por defecto, pausan y piden permiso cada vez que quieren ejecutar un comando de shell, escribir un archivo o ejecutar código. Con tres agentes ejecutándose simultáneamente, pasarás toda tu sesión haciendo clic en "Aprobar" en lugar de verlos trabajar. En la configuración de tu proyecto, pre-aprueba los comandos que tus agentes necesitarán. Lecturas de archivos, escrituras, comandos npm, ejecutores de tests — lo que tu proyecto requiera. Los comandos específicos dependen de tu stack, pero el principio es universal: elimina el cuello de botella de permisos antes de empezar, o tus agentes "paralelos" pasarán la mitad de su tiempo esperándote.

El Playbook de Prompts: Cómo decirle a los agentes qué construir

Aquí es donde la mayoría se equivoca. Activan los agent teams, escriben "constrúyeme una app de tareas pendientes," y se preguntan por qué la salida está fragmentada. La estrategia de prompts para agent teams es fundamentalmente diferente de hacer prompts a un agente individual, y la brecha entre un prompt mediocre y uno excelente se manifiesta en costo de tokens, calidad de salida y sobrecarga de coordinación. He probado docenas de estructuras de prompts durante las últimas semanas. Este es el patrón que consistentemente produce los mejores resultados. La anatomía de un prompt efectivo para agent teams:

Create a team of [number] agents using [model]:
1. [Role Name] — responsible for [specific domain].
   Owns files in: [directory or file pattern].
   Deliverables: [exact outputs expected].
2. [Role Name] — responsible for [specific domain].
   Owns files in: [directory or file pattern].
   Deliverables: [exact outputs expected].
3. [Role Name] — responsible for [specific domain].
   Owns files in: [directory or file pattern].
   Deliverables: [exact outputs expected].
Communication rules:
- [Agent A] must share [specific artifact] with [Agent B] before [specific action].
- [Agent C] reviews all deliverables before the team reports completion.
Final deliverables: [list everything the team should produce].
Goal: [one sentence describing the end state].

Déjame explicar por qué cada elemento importa. La asignación explícita de roles previene la superposición. Cuando dices "desarrollador front-end responsable de todos los componentes de UI, estilos e interacciones del lado del cliente," el agente sabe exactamente qué le pertenece y — igual de importante — qué no. Sin límites claros, he visto a dos agentes decidir ambos que deberían manejar la validación de formularios, produciendo implementaciones conflictivas en archivos diferentes. La propiedad de archivos previene conflictos de sobreescritura. Esto me costó horas antes de descubrirlo. Si dos agentes creen que ambos son dueños de app.js, uno sobreescribirá el trabajo del otro. Cada agente necesita saber qué archivos le pertenecen. "El agente front-end es dueño de todos los archivos en /src/components/ y /src/styles/." "El agente back-end es dueño de todos los archivos en /src/api/ y /src/models/." Sin ambigüedad. Sin conflictos. Las reglas explícitas de comunicación previenen el problema del freelancer sordo. La frase más efectiva que he puesto en un prompt de agent team es esta: "El agente back-end debe compartir el contrato de API endpoints con el agente front-end antes de que cualquiera de los dos comience la implementación." Esa sola frase elimina la categoría de bugs donde los agentes construyen contra suposiciones incompatibles. Sin ella, comenzarán a codificar inmediatamente — en paralelo, a toda velocidad, hacia destinos diferentes. Los entregables crean responsabilidad. "Entrega una aplicación funcional" es vago. "Entrega una app funcional, un reporte de pruebas de QA cubriendo todos los flujos críticos de usuario, y un README documentando los API endpoints" es específico. Cuando los agentes saben que serán evaluados por resultados específicos, el líder del equipo asigna el trabajo de manera diferente — y el agente de QA tiene criterios claros para su revisión. Aquí hay un prompt real que usé para el proyecto de la landing page de Neuroflow:

Create a team of 3 using Sonnet:
1. Front-End Developer — responsible for HTML structure, CSS styling,
   animations, and responsive design. Owns all .html and .css files.
   Deliverables: Complete, responsive landing page with hero section,
   features grid, pricing table, and footer.
2. Back-End Developer — responsible for JavaScript functionality,
   form handling, and any API mock endpoints. Owns all .js files.
   Deliverables: Working contact form, smooth scroll navigation,
   and dynamic pricing toggle.
3. QA Agent — responsible for testing all interactive elements,
   checking cross-browser compatibility, and verifying responsive
   breakpoints. Owns the /tests directory.
   Deliverables: Test report listing all issues found, severity ratings,
   and verification that fixes resolve each issue.
Communication rules:
- Front-End and Back-End must agree on element IDs and class names
  before implementation begins.
- QA reviews all work after initial build, sends issues back to
  responsible agents, and re-verifies after fixes.
Goal: A polished, production-quality landing page for Neuroflow,
an AI startup, that passes QA review with zero critical issues.

Ese prompt me tomó tres iteraciones para dejarlo bien. La primera versión no especificaba propiedad de archivos — dos agentes editaron el mismo archivo HTML y sobreescribieron el trabajo del otro. La segunda versión no incluía la regla de comunicación sobre IDs de elementos — el agente de JavaScript construyó event handlers apuntando a clases que no existían en el HTML. La tercera versión, la de arriba, produjo el resultado de once-bugs-luego-cero-bugs que describí al inicio. Tres a cinco agentes es el punto óptimo. He experimentado con equipos más grandes — siete agentes en un proyecto ambicioso — y la sobrecarga de coordinación se volvió aplastante. Los agentes pasaban más tiempo intercambiando mensajes que escribiendo código. La factura de tokens fue astronómica. Para la mayoría de los proyectos, un agente front-end, un agente back-end y un agente de QA cubren todo. Añade un cuarto para infraestructura o DevOps si el proyecto lo demanda. Ve más allá de cinco solo si genuinamente tienes cinco dominios de trabajo independientes que necesitan ejecución paralela.

Agent Teams vs. Sub Agents: El marco de decisión que realmente uso

He ejecutado ambos enfoques en suficientes proyectos como para tener un modelo mental claro de cuándo usar cuál. Esto no es teórico — nace de ver cómo las facturas de tokens se acumulaban cuando elegía mal. Usa sub agents cuando:

• La tarea es enfocada y delimitada. "Analiza este archivo." "Escribe tests para esta función." "Genera documentación para esta API."
• Las tareas son verdaderamente independientes. Sin decisiones compartidas, sin contratos de API que negociar, sin archivos que múltiples agentes puedan tocar.
• La velocidad y el costo importan más que la coordinación. Los sub agents son significativamente más baratos porque se saltan la sobrecarga de comunicación por completo.
• Necesitas un resultado rápido devuelto a tu sesión principal. Los sub agents son fire-and-forget — lanzar, obtener resultado, continuar. Usa agent teams cuando:
• El proyecto tiene múltiples dominios especializados que necesitan trabajar juntos. Un front-end en React, una API en Node.js y un esquema en PostgreSQL no son independientes — las decisiones en uno afectan a los otros.
• La calidad requiere feedback iterativo. El patrón del agente de QA que describí — donde un agente revisa y devuelve el trabajo para correcciones — solo funciona con agent teams. Los sub agents no pueden hacer ciclos de calidad de ida y vuelta.
• Necesitas ejecución paralela CON coordinación. Los sub agents te dan ejecución paralela. Los agent teams te dan ejecución paralela más comunicación. El "más comunicación" cuesta más pero previene las pesadillas de integración que consumen horas de limpieza manual.
• El proyecto es lo suficientemente complejo para justificar la sobrecarga. Mi umbral aproximado: si el proyecto le tomaría a un agente individual más de 15 minutos, los agent teams empiezan a tener sentido. Por debajo de eso, estás pagando impuestos de coordinación en un problema que no lo necesita. Nunca uses agent teams para:
• Tareas simples o secuenciales. Si una cosa debe ocurrir antes de la siguiente, el paralelismo no ayuda — perjudica.
• Tareas que requieren historial de conversación unificado. Cada compañero tiene su propio contexto. No hay memoria compartida de conversaciones anteriores.
• Proyectos con archivos altamente compartidos. Si cada agente necesita editar index.html, vas a tener problemas sin importar cuán cuidadosamente asignes la propiedad.
• Exploración y planificación. Cometí este error temprano — usar agent teams para "investigar y planificar" una arquitectura de proyecto. Los agentes gastaron todo su presupuesto discutiendo posibilidades en lugar de construir algo. Usa un agente individual para la planificación, luego trae al equipo para la ejecución. La diferencia de costo es real y significativa. Un agente individual podría quemar 45.000 tokens en una app de gestión de tareas. La misma app construida por un agent team puede alcanzar 150.000-200.000 tokens — tres a cuatro veces más — porque la comunicación entre agentes no es gratuita. Cada mensaje entre compañeros consume tokens de ambos lados. Solo el ciclo de revisión-y-corrección de QA puede duplicar el uso total. Para mi trabajo, la cuenta sale así: los agent teams producen salida de mayor calidad en proyectos complejos, pero el costo en tokens es 3-5x mayor. Solo recurro a agent teams cuando la diferencia de calidad importa lo suficiente para justificar el gasto — proyectos de clientes, aplicaciones en producción, cualquier cosa donde los bugs de integración costarían más de arreglar manualmente que lo que cuestan los tokens extra para prevenirlos.

Los errores que me costaron miles de tokens

Quiero ser honesto sobre los fracasos porque me enseñaron más que los éxitos. Aquí están los errores que cometí para que puedas saltártelos. Error 1: No asignar propiedad de archivos. Mis primeras tres sesiones de agent team produjeron código que se veía bien en la terminal de cada agente y estaba completamente roto al combinarse. Dos agentes creaban ambos un archivo utils.js. Un agente modificaba package.json mientras otro estaba en medio de leerlo. El líder del equipo intentaba integrar todo y encontraba cambios conflictivos dispersos por todo el proyecto. La solución fue vergonzosamente simple: decirle a cada agente exactamente qué archivos y directorios le pertenecen. "Puedes leer cualquier cosa, pero solo escribes en archivos de tu directorio." Perdí probablemente 300.000 tokens aprendiendo esta lección a lo largo de múltiples sesiones fallidas. Error 2: Dejar que los agentes se comuniquen libremente sin estructura. La mensajería irrestricta entre agentes suena genial en teoría. En la práctica, tres agentes con comunicación libre pasarán una cantidad alarmante de tiempo hablando en lugar de construyendo. Vi a un agente back-end y un agente front-end tener un intercambio de siete mensajes sobre la mejor manera de manejar el formato de fechas antes de que cualquiera de los dos hubiera escrito una sola línea de código. Ahora establezco puntos de control de comunicación explícitos: "Comparte el contrato de API antes de la implementación. Reporta la finalización a QA después de la implementación. No envíes mensajes a otros durante la implementación a menos que estés bloqueado." Esto redujo el uso de tokens aproximadamente un 40% sin reducir la calidad de la salida. Error 3: Usar el modelo equivocado para el rol equivocado. Ejecutar cada agente en Opus 4.6 se siente seguro — es el modelo más potente, así que todo debería funcionar mejor, ¿verdad? En la práctica, el costo es asombroso y la mejora de calidad para tareas de ejecución es marginal. Mi asignación actual de modelos:

• Líder del equipo: Opus 4.6 — está tomando decisiones arquitectónicas y coordinando dependencias complejas. Vale la pena el premium.
• Agentes desarrolladores (front-end, back-end): Sonnet — rápido, capaz, y aproximadamente 5x más barato por token que Opus. Para escribir código dentro de límites bien definidos, Sonnet rinde casi idénticamente.
• Agente de QA: Sonnet o incluso Haiku para proyectos más simples — está siguiendo patrones de pruebas, no inventando arquitecturas. El modelo más económico que puede ejecutar lógica de pruebas de forma confiable. Este enfoque escalonado redujo mis costos de agent team aproximadamente un 60% comparado con ejecutar Opus en todas partes. Error 4: No pre-aprobar permisos. Con tres agentes ejecutándose en paralelo, cada uno necesitando aprobación para operaciones de archivos y comandos de shell, yo me convertí en el cuello de botella. Los agentes se quedaban inactivos 30-60 segundos esperando a que yo hiciera clic en "Aprobar" en cada panel. Multiplica eso por docenas de operaciones por agente, y un proyecto que debería tomar cinco minutos se estira a veinte — no porque los agentes sean lentos, sino porque no puedo hacer clic lo suficientemente rápido. Pre-aprueba todo lo que tus agentes necesiten en la configuración de tu proyecto o local. La diferencia de productividad es enorme. Error 5: Ejecutar equipos sin agente de QA. Mis primeros agent teams eran dos desarrolladores y ningún QA. La salida era rápida pero plagada de problemas de integración — IDs que no coincidían, event handlers rotos, CSS que conflictuaba entre componentes. Yo mismo estaba haciendo QA, lo que anulaba el propósito de tener un equipo. Agregar un agente de QA dedicado cambió el juego. Detecta problemas de integración que me tomarían 10-15 minutos encontrar manualmente, y el ciclo de revisión-corrección-verificación ocurre sin mi intervención. El agente de QA cuesta quizás 20.000 tokens extra por sesión. El tiempo que me ahorra vale diez veces eso. Si prefieres que alguien configure estas configuraciones de agent team desde cero — prompts optimizados, asignaciones de modelos, workflows de QA, toda la infraestructura — acepto ese tipo de encargos. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Patrones Avanzados: Aprobación de Planes, Monitoreo con Tmux y Persistencia de Contexto

Una vez que tengas lo básico funcionando, tres funciones avanzadas llevarán tu workflow de agent teams de bueno a genuinamente potente. Modo de Aprobación de Plan Por defecto, los compañeros del agent team simplemente... arrancan. Reciben su asignación y comienzan a ejecutar inmediatamente. El modo de aprobación de plan añade un punto de control: cada agente genera un plan y espera aprobación antes de escribir cualquier código. El aprobador puedes ser tú, el líder del equipo, o un agente revisor designado. Lo uso selectivamente. Para proyectos donde conozco bien la arquitectura, dejo que los agentes ejecuten libremente — la velocidad importa más que el control. Para territorio desconocido o proyectos de clientes donde los errores son costosos, la aprobación de plan me da una puerta de revisión sin ralentizar todo el equipo a ejecución secuencial. Cada agente envía su plan en paralelo. Reviso todos los planes simultáneamente. Luego todos ejecutan en paralelo. La sobrecarga total suele ser menor a dos minutos, y previene el tipo de divergencia arquitectónica que requiere una reconstrucción completa. Monitoreo con Tmux Mencioné tmux antes para la división de terminal, pero el workflow de monitoreo merece más detalle. Cuando los agent teams están ejecutándose con tmux, cada agente obtiene un panel dedicado con un encabezado codificado por colores mostrando su rol. Puedes:

• Ver a todos los agentes trabajar simultáneamente
• Hacer clic en el panel de cualquier agente para enviar un mensaje directo
• Observar el flujo de mensajes entre agentes en tiempo real
• Detectar problemas de bloqueo antes de que se propaguen La capacidad de mensajería directa es particularmente valiosa. Si veo al agente front-end yendo por un camino que sé que no funcionará, puedo saltar a su panel y redirigir sin afectar a los otros agentes. "Oye, usa CSS Grid para este layout en lugar de Flexbox — los componentes anidados necesitarán alineación bidimensional." El agente se ajusta, y el agente back-end sigue trabajando sin perturbaciones. Este tipo de intervención quirúrgica no es posible con sub agents. Tendrías que cancelar el sub agent, reescribir el prompt y relanzar — perdiendo todo el trabajo que ya había hecho. Persistencia de Contexto a través de Archivos Temporales Los agent teams tienen una vulnerabilidad que me afectó dos veces: si un agente se cae o la sesión se interrumpe, cualquier trabajo que no se haya escrito en disco desaparece. El context window del agente se evapora, y el líder del equipo no tiene una copia del trabajo en progreso. Mi solución alternativa: instruir a los agentes para que guarden el progreso en archivos temporales después de cada hito importante. "Después de completar el componente header, guarda tu progreso en /tmp/frontend-checkpoint-1.md con un resumen de lo que está hecho y qué sigue." Si un agente muere a mitad de sesión, el agente de reemplazo lee el archivo de checkpoint y continúa donde el anterior se quedó en lugar de empezar desde cero. Esto añade quizás un 5% a tu uso de tokens y me ha salvado de dos reinicios completos de equipo. El primer reinicio, antes de implementar checkpoints, me costó aproximadamente 180.000 tokens de trabajo duplicado.

El Modelo Mental Que Hace Que Todo Encaje

Después de semanas de experimentación, he encontrado una forma de pensar sobre los agent teams que predice cuándo funcionarán bien y cuándo fallarán. Viene de la gestión de equipos del mundo real, no de teoría de AI. Los agent teams siguen las mismas reglas que los equipos humanos de ingeniería: La Ley de Brooks aplica. Agregar más agentes a un proyecto incrementa la sobrecarga de comunicación cuadráticamente. Tres agentes tienen tres canales de comunicación. Cinco agentes tienen diez. Siete agentes tienen veintiuno. El costo de coordinación no escala linealmente — explota. Mantén los equipos pequeños. Tres a cinco agentes. No más. La Ley de Conway aplica. La estructura de tu agent team se reflejará en la estructura del código que producen. Si tienes un agente front-end y un agente back-end, obtendrás un front-end y back-end claramente separados. Si tienes un agente manejando "UI y API" juntos, obtendrás código fuertemente acoplado. Diseña la estructura de tu equipo para que coincida con la arquitectura que deseas. El mítico hombre-mes aplica. Dos agentes no producen el doble de rápido que un agente en cada tarea. En algunas tareas — secuenciales, fuertemente acopladas, que requieren contexto compartido — dos agentes son más lentos que uno debido a la sobrecarga de coordinación. Los agent teams brillan cuando el trabajo es genuinamente paralelizable con límites de dominio claros. La implicación práctica: antes de generar un agent team, esboza el proyecto como un grafo de dependencias. Si tienes tres o más flujos de trabajo independientes que eventualmente necesitan integrarse, los agent teams tienen sentido. Si el trabajo es fundamentalmente secuencial o todo depende de todo lo demás, usa un agente individual. He empezado a hacerme una pregunta simple antes de cada proyecto: "¿Podría explicar esto a tres freelancers separados en tres habitaciones separadas y obtener un resultado coherente?" Si sí, agent teams. Si no, agente individual o sub agents con integración cuidadosa.

En qué estoy trabajando ahora — y qué viene después

Ahora mismo, estoy usando agent teams para casi cada proyecto con más de dos puntos de integración. El workflow se ha estabilizado en un patrón: planifico con una sesión individual de Opus, configuro la propiedad de archivos y reglas de comunicación, y luego genero un equipo de 3-4 agentes Sonnet para ejecutar mientras un agente de QA vigila la salida. Los resultados hablan a través del proceso, no del bombo publicitario. Mis landing pages vuelven más limpias porque el agente de QA captura cosas que yo pasaría por alto a las 2 AM. Mis builds full-stack se integran en la primera pasada porque los agentes negocian contratos de API antes de escribir código. Mis sesiones de debugging son más rápidas porque puedo tener tres agentes probando tres hipótesis diferentes simultáneamente en lugar de probarlas secuencialmente. La función no es perfecta. La estabilidad de sesión puede ser irregular — he tenido agentes que se desconectan a mitad de tarea en sesiones largas. El costo en tokens es genuinamente alto para proyectos complejos. Y la precisión de prompts requerida significa que hay una curva de aprendizaje que es más pronunciada de lo que la documentación de Anthropic sugiere. Pero esto es lo que me convenció de que esto es el futuro del desarrollo asistido por AI, no solo una función: el patrón de colaboración en sí. Ver a un agente de QA encontrar bugs, enviarlos al desarrollador responsable, recibir correcciones y verificar las soluciones — todo sin mi intervención — eso no es solo automatización. Eso es un equipo. Un equipo que resulta estar hecho de AI, pero un equipo al fin, con las mismas dinámicas de comunicación, responsabilidad y mejora iterativa de calidad que hacen efectivos a los equipos humanos de ingeniería. Las herramientas se volverán más baratas y estables. Los modelos se volverán más rápidos e inteligentes. Pero el patrón — agentes especializados colaborando a través de comunicación estructurada en objetivos compartidos — ese patrón es permanente. Aprenderlo ahora significa que estás construyendo una habilidad que se multiplica con cada mejora que Anthropic lance. Si todavía estás ejecutando todo a través de un agente individual y te preguntas por qué los proyectos complejos se sienten como empujar una roca cuesta arriba, prueba esto: toma tu próximo proyecto con múltiples componentes, define tres roles con propiedad clara de archivos, añade un agente de QA, y escribe una regla de comunicación. Solo una. "Acuerden el contrato de API antes de escribir código." Y luego observa lo que sucede.

Preguntas Frecuentes

¿Cómo activo los Claude Code agent teams?

Añade "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" al objeto env en el archivo settings.local.json de tu proyecto y reinicia Claude Code. Necesitas Claude Code v2.1.32 o posterior, disponible en planes Pro ($20/mes) o Max ($100-$200/mes).

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

Tres a cinco agentes es el punto óptimo para la mayoría de los proyectos. Más allá de cinco, la sobrecarga de comunicación entre agentes crece cuadráticamente y los costos de tokens escalan. Un equipo efectivo típico incluye un agente front-end, un agente back-end y un agente de QA. Para una mirada más profunda a la selección de modelos por rol, consulta mi guía de Claude agent teams.

¿Cuál es la diferencia entre agent teams y sub agents?

Los sub agents se ejecutan independientemente, completan una tarea y devuelven resultados al agente principal — no pueden comunicarse entre sí. Los agent teams tienen una lista de tareas compartida, mensajería directa entre agentes y un líder de equipo coordinando trabajo paralelo con ciclos de feedback iterativos. Los sub agents son más baratos y rápidos; los agent teams producen salida de mayor calidad en proyectos complejos y multidominio.

¿Los agent teams cuestan más tokens que un agente individual?

Sí, significativamente. Una tarea que cuesta 45.000 tokens con un agente individual típicamente cuesta 150.000-200.000 tokens con un agent team debido a la sobrecarga de comunicación entre agentes. Reduce costos usando Sonnet o Haiku para agentes de ejecución y reservando Opus solo para el líder del equipo.

¿Los compañeros del agent team pueden acceder a mis archivos de proyecto y herramientas?

Todos los compañeros heredan permisos de la sesión principal, incluyendo acceso al sistema de archivos, ejecución de comandos, servidores MCP y skills. No puedes otorgar diferentes niveles de permisos a diferentes compañeros — todos comparten la misma configuración de acceso.

Trabajemos Juntos

¿Buscas construir sistemas de AI, automatizar workflows o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (builds personalizados e integraciones): 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