Módulo 6: Subagents: delegar trabajo a agentes especializados
Introducción a Agent Teams: orquestación multi-agente
Introducción a Agent Teams: orquestación multi-agente
Descripción
⚠️ Agent Teams está actualmente en research preview/experimental. Las APIs, comandos y comportamientos descritos en esta cápsula pueden cambiar significativamente. Esta cápsula se enfoca en conceptos y modelos mentales, no en implementación paso a paso. Consulta la documentación oficial de Anthropic para el estado actual de la feature.
Hasta ahora has trabajado con subagents — agentes hijos que el agente principal crea, delega, y destruye. Los subagents son efímeros: nacen para una tarea, la completan, y desaparecen. Es un modelo eficiente para tareas puntuales, pero tiene limitaciones cuando el proyecto requiere coordinación sostenida entre múltiples agentes.
Agent Teams introduce un modelo diferente: un equipo persistente de agentes que trabajan juntos en un proyecto compartido. En lugar de un parent que crea children efímeros, tienes un team lead que coordina teammates autónomos, cada uno con su propio contexto, responsabilidades, y capacidad de tomar decisiones. Comparten un task board donde se asignan, rastrean, y completan tareas con resolución de dependencias.
Esta cápsula es conceptual. No te pedirá que implementes Agent Teams (porque está en preview y la API puede cambiar), pero sí que entiendas el modelo mental, las diferencias con subagents, y cuándo escalar de uno a otro. Cuando Agent Teams sea estable, tendrás la base conceptual para adoptarlo inmediatamente.
De subagents a Agent Teams: la evolución
El espectro de delegación
Claude Code ofrece un espectro continuo de delegación, y cada nivel agrega capacidades:
NIVEL 1 NIVEL 2 NIVEL 3 NIVEL 4
Sin Skills Subagents Agent Teams
delegación (experimental)
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Un agente│ │ Un agente│ │ Parent + │ │ Team lead│
│ hace │ │ con │ │ children │ │ + team- │
│ todo │ │ instruc- │ │ efímeros │ │ mates │
│ │ │ ciones │ │ │ │ persis- │
│ │ │ extra │ │ │ │ tentes │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │ │
▼ ▼ ▼ ▼
Simple Repetitivo Paralelo Complejo
1 archivo 1 tarea N subtareas N workstreams
1 sesión N sesiones 1 sesión N sesiones
Cada nivel es apropiado para un tipo de proyecto:
| Nivel | Ejemplo | Complejidad |
|---|---|---|
| Sin delegación | Fix un typo, cambiar un color | Trivial |
| Skills | Crear componente, escribir test | Repetitivo |
| Subagents | Refactorizar un módulo, migrar una dependencia | Complejo, una sesión |
| Agent Teams | Implementar un feature completo end-to-end con backend, frontend, tests, docs | Complejo, multi-sesión |
Por qué subagents no son suficientes para todo
Los subagents tienen tres limitaciones fundamentales que Agent Teams aborda:
1. Efímeros
Los subagents se crean y destruyen en cada invocación. Si un Explore subagent analizó tu codebase y encontró patterns importantes, esa información se pierde cuando termina. En la siguiente invocación, un nuevo subagent tiene que empezar de cero.
Agent Teams: los teammates persisten. Un teammate que analizó la arquitectura retiene ese conocimiento para futuras tareas.
2. Sin autonomía
Los subagents hacen exactamente lo que el parent les dice. No toman iniciativa ni identifican trabajo que necesita hacerse. Si el parent no pide "analiza los tests", nadie los analiza.
Agent Teams: los teammates pueden identificar trabajo, proponerlo al task board, y ejecutarlo autónomamente (con aprobación del team lead).
3. Sin coordinación entre sí
Los subagents no saben que otros subagents existen. Si lanzas un Explore subagent y un General-purpose subagent en paralelo, cada uno opera en aislamiento total.
Agent Teams: los teammates ven el task board compartido, saben qué están haciendo los otros, y pueden coordinarse (ej. "espera a que el teammate de backend termine el endpoint antes de hacer el test de integración").
Conceptos clave de Agent Teams
1. Team Lead
El team lead es el agente orquestador. Es análogo al agente principal en el modelo de subagents, pero con capacidades adicionales:
┌────────────────────────────────────────────────────────────┐
│ TEAM LEAD │
│ │
│ Responsabilidades: │
│ ├── Descomponer el proyecto en tareas │
│ ├── Asignar tareas a teammates │
│ ├── Resolver dependencias entre tareas │
│ ├── Revisar outputs de teammates │
│ ├── Integrar resultados parciales │
│ └── Comunicar progreso y decisiones │
│ │
│ Herramientas exclusivas: │
│ ├── Crear/modificar task board │
│ ├── Asignar/reasignar teammates │
│ └── Aprobar/rechazar outputs de teammates │
│ │
└────────────────────────────────────────────────────────────┘
El team lead no implementa directamente — coordina. Si un teammate tiene un bloqueo, el team lead lo resuelve o reasigna. Si el output de un teammate no es aceptable, el team lead pide correcciones.
2. Teammates
Los teammates son agentes especializados que ejecutan tareas asignadas. A diferencia de los subagents, los teammates:
- Persisten entre tareas (no se destruyen al completar una)
- Tienen especialización definida (ej. "backend developer", "test engineer")
- Pueden proponer trabajo adicional al task board
- Ven el task board y saben qué hacen los otros
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ TEAMMATE 1 │ │ TEAMMATE 2 │ │ TEAMMATE 3 │
│ Backend │ │ Frontend │ │ QA/Testing │
│ Developer │ │ Developer │ │ Engineer │
│ │ │ │ │ │
│ Skills: │ │ Skills: │ │ Skills: │
│ - API design│ │ - React │ │ - Test design│
│ - DB queries│ │ - CSS │ │ - E2E tests │
│ - Auth │ │ - A11y │ │ - Coverage │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└────────────────┼──────────────────┘
│
┌─────────────┐
│ TASK BOARD │
│ (compartido)│
└─────────────┘
3. Task Board
El task board es el espacio compartido donde viven las tareas del proyecto. Es visible para el team lead y todos los teammates:
┌──────────────────────────────────────────────────────────┐
│ TASK BOARD │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ BACKLOG │ │ IN PROGRESS │ │ DONE │ │
│ ├─────────────┤ ├─────────────┤ ├─────────────┤ │
│ │ #4 Write │ │ #2 Implement│ │ #1 Design │ │
│ │ API docs │ │ endpoints│ │ schema ✓ │ │
│ │ [unassig]│ │ [BE dev] │ │ [BE dev] │ │
│ │ │ │ │ │ │ │
│ │ #5 E2E tests│ │ #3 Build UI │ │ │ │
│ │ [blocked │ │ [FE dev] │ │ │ │
│ │ by #2] │ │ │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Dependencias: #5 blocked by #2, #3 depends on #1 │
│ │
└──────────────────────────────────────────────────────────┘
El task board no es solo una lista — tiene:
- Estados: backlog, in progress, in review, done
- Asignaciones: qué teammate trabaja en qué
- Dependencias: qué tareas bloquean a otras
- Prioridades: orden de ejecución
4. Resolución de dependencias
El team lead maneja las dependencias entre tareas. Si la tarea #5 (E2E tests) depende de la tarea #2 (implementar endpoints), el team lead:
- Asigna #2 al backend teammate
- Marca #5 como blocked
- Cuando #2 se completa, desbloquea #5
- Asigna #5 al QA teammate
- El QA teammate puede ver el output de #2 para escribir los tests
Este flujo de dependencias es automático — el team lead no necesita micromanagement manual.
Subagents vs Agent Teams: cuándo usar cada uno
Tabla comparativa
| Criterio | Subagents | Agent Teams |
|---|---|---|
| Duración | Efímeros (una tarea) | Persistentes (todo el proyecto) |
| Coordinación | Parent controla todo | Task board compartido |
| Autonomía | Cero — hacen lo que el parent dice | Parcial — pueden proponer trabajo |
| Número de tareas | 1-5 subtareas | 10+ tareas organizadas |
| Sesiones | Dentro de una sesión | Múltiples sesiones |
| Complejidad | Módulo/feature aislado | Feature end-to-end o proyecto completo |
| Overhead | Bajo | Mayor (setup, coordinación) |
| Estado | Estable (GA) | Experimental (research preview) |
Árbol de decisión
¿La tarea cruza múltiples dominios (backend + frontend + tests)?
├── NO → ¿Puede hacerse en una sesión?
│ ├── SÍ → SUBAGENTS (delegación puntual)
│ └── NO → ¿Necesita coordinación entre workstreams?
│ ├── NO → SUBAGENTS (múltiples sesiones secuenciales)
│ └── SÍ → AGENT TEAMS ⚠️ (experimental)
└── SÍ → ¿Son interdependientes los dominios?
├── NO → SUBAGENTS (paralelo, sin coordinación)
└── SÍ → AGENT TEAMS ⚠️ (task board + dependencias)
Ejemplos concretos
Usar subagents:
- "Refactoriza el servicio de autenticación" → un dominio, una sesión
- "Analiza los tests y la cobertura" → análisis puntual
- "Genera documentación para el módulo de pagos" → tarea acotada
Usar Agent Teams (cuando esté disponible):
- "Implementa el módulo de reportes: API, UI, tests, docs" → múltiples dominios, dependencias cruzadas
- "Migra de Express a Fastify manteniendo backward compatibility" → múltiples workstreams coordinados
- "Construye un feature de chat en tiempo real end-to-end" → backend WebSocket + frontend React + tests de integración + docs
La regla práctica
Si puedes describir la tarea en una sola instrucción y esperarías un resultado en una sesión → subagents. Si necesitas un "proyecto con múltiples tareas que se coordinan" → Agent Teams.
Cómo funciona Agent Teams (modelo conceptual)
⚠️ Los detalles de implementación pueden cambiar. Esta sección describe el modelo conceptual basado en la documentación preview de Anthropic.
Ciclo de vida de un Agent Team
1. SETUP
┌─────────────────────────────────────────┐
│ Team lead recibe el objetivo del usuario │
│ → Descompone en tareas │
│ → Define teammates necesarios │
│ → Crea task board con dependencias │
└─────────────────────────────────────────┘
│
▼
2. EJECUCIÓN
┌─────────────────────────────────────────┐
│ Teammates trabajan en tareas asignadas │
│ → Cada uno en su contexto │
│ → Reportan progreso al task board │
│ → Team lead resuelve bloqueos │
└─────────────────────────────────────────┘
│
▼
3. INTEGRACIÓN
┌─────────────────────────────────────────┐
│ Team lead integra resultados │
│ → Revisa output de cada teammate │
│ → Resuelve conflictos │
│ → Verifica coherencia del resultado │
└─────────────────────────────────────────┘
│
▼
4. ENTREGA
┌─────────────────────────────────────────┐
│ Resultado completo entregado al usuario │
│ → Resumen de lo implementado │
│ → Status de cada tarea │
│ → Decisiones tomadas y trade-offs │
└─────────────────────────────────────────┘
Ejemplo conceptual: Implementar un módulo de notificaciones
Imagina que le pides a Claude Code:
Implementa un sistema de notificaciones para la app:
- Backend: servicio de notificaciones con cola (Redis)
- Frontend: componente de notificaciones en tiempo real
- Tests: unitarios e integración
- Docs: documentación del API y guía de uso
Con Agent Teams, el flujo sería:
TEAM LEAD analiza y descompone:
Task Board:
┌──────────────────────────────────────────────────────────┐
│ #1 [BE] Crear NotificationService (Redis pub/sub) │
│ → Asignado: Backend teammate │
│ → Dependencias: ninguna │
│ │
│ #2 [BE] Crear endpoints REST para notificaciones │
│ → Asignado: Backend teammate │
│ → Dependencias: #1 │
│ │
│ #3 [FE] Crear NotificationPanel component │
│ → Asignado: Frontend teammate │
│ → Dependencias: #2 (necesita conocer la API) │
│ │
│ #4 [FE] Integrar WebSocket para tiempo real │
│ → Asignado: Frontend teammate │
│ → Dependencias: #1, #3 │
│ │
│ #5 [QA] Tests unitarios del NotificationService │
│ → Asignado: QA teammate │
│ → Dependencias: #1 │
│ │
│ #6 [QA] Tests de integración backend-frontend │
│ → Asignado: QA teammate │
│ → Dependencias: #2, #4 │
│ │
│ #7 [DOC] Documentación API + guía de uso │
│ → Asignado: Team lead (o cualquier teammate libre) │
│ → Dependencias: #2, #4 │
└──────────────────────────────────────────────────────────┘
Ejecución paralela:
- Backend empieza con #1 (sin dependencias)
- QA empieza con #5 cuando #1 se completa
- Frontend empieza con #3 cuando #2 se completa
- Etc.
Lo que antes tomaría múltiples sesiones manuales de coordinación se orquesta automáticamente.
Comparaciones y decisiones
Agent Teams vs herramientas de project management
Agent Teams no reemplaza Jira, Linear, o GitHub Projects. Es un sistema de coordinación entre agentes de IA, no entre humanos:
| Aspecto | Jira/Linear | Agent Teams |
|---|---|---|
| Quién usa | Humanos | Agentes de IA |
| Duración | Sprints (semanas) | Minutos a horas |
| Tareas | Definidas por humanos | Descompuestas por team lead |
| Asignación | Manual por PM | Automática por team lead |
| Ejecución | Humanos implementan | Agentes implementan |
Agent Teams es un micro-project-management para agentes, dentro de una o pocas sesiones de Claude Code.
Agent Teams vs CI/CD pipelines
Los pipelines de CI/CD ejecutan pasos predefinidos en secuencia. Agent Teams ejecuta tareas con razonamiento:
| Aspecto | CI/CD Pipeline | Agent Teams |
|---|---|---|
| Flexibilidad | Pasos fijos | Tareas adaptativas |
| Razonamiento | No | Sí (cada teammate razona) |
| Dependencias | Lineales | Grafo complejo |
| Error handling | Falla y notifica | Reintenta o reasigna |
¿Agent Teams es siempre mejor que subagents?
No. Agent Teams agrega overhead de coordinación. Para tareas que caben en una sesión con subagents, Agent Teams es overengineering:
Tarea: "Agrega paginación al endpoint de productos"
→ Subagents (Explore + parent). Agent Teams es overkill.
Tarea: "Implementa módulo de chat con WebSocket, UI, tests y docs"
→ Agent Teams (múltiples workstreams con dependencias).
La regla: si la coordinación entre tareas es trivial, usa subagents. Si es el desafío principal, Agent Teams tiene sentido.
Patterns comunes (conceptuales)
Pattern 1: Feature end-to-end
El caso más natural para Agent Teams: implementar un feature completo que cruza backend, frontend, y tests.
Objetivo: "Implementa búsqueda de productos con filtros"
Teammates:
- Backend: API endpoints con filtros y paginación
- Frontend: UI de búsqueda con filtros dinámicos
- QA: Tests unitarios y E2E
Dependencias:
- Frontend depende de Backend (necesita conocer la API)
- QA depende de ambos (testea la integración)
Pattern 2: Migración coordinada
Migraciones grandes donde los cambios deben ser coordinados para evitar romper el sistema:
Objetivo: "Migra de REST a GraphQL manteniendo backward compat"
Teammates:
- Schema designer: define el schema GraphQL
- Backend migrator: implementa resolvers
- Frontend migrator: actualiza llamadas
- Compat checker: verifica que REST sigue funcionando
Dependencias:
- Todo depende del schema
- Frontend depende de Backend
- Compat checker corre después de cada cambio
Pattern 3: Code review + fix
Un equipo donde un teammate revisa y otro corrige:
Objetivo: "Mejora la calidad del módulo de pagos"
Teammates:
- Reviewer: analiza y genera reporte de issues
- Fixer: arregla issues basándose en el reporte
- Tester: verifica que los fixes no introducen regresiones
Flujo:
Reviewer → reporte → Fixer → cambios → Tester → validación
Limitaciones actuales
⚠️ Estas limitaciones son del estado actual (research preview) y pueden cambiar.
Limitaciones técnicas
- Requiere configuración específica: Agent Teams no se activa por defecto. Requiere flags o configuración especial.
- Compatibilidad de modelos: Puede no funcionar con todos los modelos disponibles. Opus 5 es el modelo recomendado.
- Consumo de recursos: Múltiples teammates = múltiples context windows = mayor consumo de API.
- API inestable: Los comandos y la configuración pueden cambiar entre versiones.
Limitaciones prácticas
- Overhead de coordinación: Para proyectos pequeños, la coordinación consume más tiempo del que ahorra.
- Debugging complejo: Cuando algo falla en un equipo de 4 agentes, identificar el problema es más difícil.
- Resultados inconsistentes: Al ser experimental, los resultados pueden variar entre ejecuciones.
- Sin persistencia entre sesiones: Aunque los teammates persisten dentro de una ejecución, cerrar Claude Code los destruye.
Qué esperar en el futuro
Basándose en la dirección de la investigación de Anthropic:
- Persistencia real: Teammates que sobreviven entre sesiones
- Especialización más profunda: Teammates que aprenden del proyecto con el tiempo
- Integración con CI/CD: Agent Teams que se disparan desde pipelines
- Multi-repo: Teammates que trabajan en diferentes repositorios coordinadamente
- Human-in-the-loop: Checkpoints donde el team lead pide aprobación humana antes de continuar
Pitfalls y edge cases
Pitfall 1: Usar Agent Teams para todo
Agent Teams no es siempre la respuesta. La mayoría de tareas cotidianas se resuelven bien con el agente principal o subagents:
❌ Agent Teams para cambiar un color CSS
❌ Agent Teams para agregar un campo a un formulario
✅ Agent Teams para implementar un feature multi-dominio complejo
Pitfall 2: No definir dependencias claramente
Si las dependencias entre tareas no están claras, los teammates pueden trabajar con información desactualizada:
❌ "Implementa backend y frontend del chat" (sin especificar orden)
✅ "Implementa el backend primero (endpoints + WebSocket).
Cuando esté listo, frontend consume esa API."
Pitfall 3: Asumir estabilidad
Agent Teams está en preview. No construyas workflows de producción que dependan de esta feature. Úsala para experimentar y aprender el modelo mental.
Pitfall 4: Ignorar el costo
Cada teammate consume context window y API calls. Un equipo de 4 teammates puede consumir 4x los tokens de un solo agente. Evalúa si el beneficio justifica el costo.
Edge case: Conflictos entre teammates
Si dos teammates modifican el mismo archivo, puede haber conflictos. El team lead debe resolver estos conflictos. En la práctica, una buena descomposición de tareas minimiza los conflictos (cada teammate trabaja en archivos diferentes).
Edge case: Teammate bloqueado
Si un teammate está bloqueado por una dependencia que tarda, el team lead puede:
- Reasignar la tarea bloqueante
- Desbloquear proporcionando información parcial
- Reorganizar el task board para maximizar el trabajo paralelo
Ejemplo completo integrado
Escenario conceptual: Construir un módulo de reportes end-to-end
Imagina que quieres construir un módulo de reportes para un e-commerce. Con Agent Teams, el flujo conceptual sería:
Instrucción al team lead
Construye un módulo de reportes para el e-commerce:
- Backend: endpoints para generar reportes de ventas
(diario, semanal, mensual) con filtros por categoría
y rango de fechas
- Frontend: dashboard con gráficos (Chart.js o Recharts)
- Tests: unitarios para la lógica de aggregation,
integración para los endpoints
- Docs: documentación del API en OpenAPI format
Task board generado por el team lead
TAREAS (generadas automáticamente):
#1 [BE] Crear ReportService con lógica de aggregation
Estado: todo | Asignado: BE teammate | Deps: -
#2 [BE] Crear ReportRepository con queries optimizadas
Estado: todo | Asignado: BE teammate | Deps: -
#3 [BE] Crear endpoints GET /reports/{type}
Estado: todo | Asignado: BE teammate | Deps: #1, #2
#4 [FE] Crear ReportDashboard component
Estado: todo | Asignado: FE teammate | Deps: #3
#5 [FE] Integrar Recharts para gráficos
Estado: todo | Asignado: FE teammate | Deps: #4
#6 [QA] Tests unitarios de ReportService
Estado: todo | Asignado: QA teammate | Deps: #1
#7 [QA] Tests de integración de endpoints
Estado: todo | Asignado: QA teammate | Deps: #3
#8 [DOC] OpenAPI spec para endpoints de reportes
Estado: todo | Asignado: team lead | Deps: #3
Ejecución (conceptual)
Fase 1 (paralelo):
BE teammate: #1 ReportService + #2 ReportRepository
Fase 2 (paralelo):
BE teammate: #3 Endpoints (depende de #1, #2)
QA teammate: #6 Tests de ReportService (depende de #1)
Fase 3 (paralelo):
FE teammate: #4 ReportDashboard + #5 Recharts
QA teammate: #7 Tests integración (depende de #3)
Team lead: #8 OpenAPI spec (depende de #3)
Resultado final:
Módulo completo: backend + frontend + tests + docs
Todo coordinado automáticamente
Este escenario ilustra el poder de Agent Teams: lo que manualmente requeriría 4-6 sesiones con instrucciones explícitas de coordinación se organiza automáticamente.
Conexión con el resto de la guía
Hacia atrás
- Módulo 04 (Workflow): El ciclo Explore → Plan → Code sigue siendo la base. Agent Teams lo escala a múltiples agentes ejecutando el ciclo en paralelo.
- Módulo 05 (Skills/Hooks): Los teammates pueden usar skills definidos en
.claude/skills/. Los hooks siguen ejecutándose en cada acción. - Cápsula 02 (Built-in subagents): Los subagents built-in son los bloques base. Agent Teams los orquesta a mayor escala.
- Cápsula 03 (Custom subagents): Los custom subagents pueden evolucionar a definiciones de teammates en Agent Teams.
Hacia adelante
- Módulo 07 (Integraciones): Git workflows, SDK headless, y Remote Control se integran con Agent Teams (ej. un teammate que hace commits mientras otro implementa).
- Módulo 08 (Proyecto integrador): El proyecto se puede abordar con subagents (recomendado, dado que Agent Teams es experimental) o con Agent Teams (para los aventureros).
- Guía #9 (Advanced Claude Code Workflows): La guía avanzada cubrirá Agent Teams en profundidad cuando sea GA (Generally Available).
Ejercicios prácticos
Estos ejercicios se enfocan en el modelo mental de Agent Teams, no en implementación (dado que la feature es experimental).
Ejercicio 1: Descomponer en tareas
Toma un feature de tu proyecto (real o hipotético) y descompónlo como lo haría un team lead. Define:
- 6-8 tareas con descripciones claras
- Dependencias entre tareas (qué bloquea a qué)
- Asignación a teammates (backend, frontend, QA, docs)
- Orden de ejecución óptimo (maximizar paralelismo)
Ejemplo de solución
Feature: "Agregar sistema de comentarios a un blog"
Tareas:
- [BE] Crear modelo Comment con relaciones (User, Post) → Deps: -
- [BE] Crear endpoints CRUD para comments → Deps: #1
- [BE] Implementar moderación automática (filtro de spam) → Deps: #1
- [FE] Crear componente CommentSection → Deps: #2
- [FE] Crear formulario de nuevo comentario con validación → Deps: #2
- [QA] Tests unitarios del modelo y servicio → Deps: #1, #3
- [QA] Tests E2E del flujo completo → Deps: #4, #5
- [DOC] Documentar API de comments en OpenAPI → Deps: #2
Orden óptimo:
- Fase 1: #1 (sin deps)
- Fase 2: #2, #3, #6 (paralelo, dependen de #1)
- Fase 3: #4, #5, #8 (paralelo, dependen de #2)
- Fase 4: #7 (depende de #4, #5)
Ejercicio 2: Subagents vs Agent Teams
Para cada escenario, decide si usarías subagents o Agent Teams y justifica:
- Agregar dark mode a la app
- Implementar un sistema de autenticación con OAuth
- Refactorizar un archivo de 500 líneas
- Migrar la base de datos de MongoDB a PostgreSQL
- Agregar internacionalización (i18n) a toda la app
- Fix de un bug en producción
Solución
- Subagents — un solo dominio (frontend), cambios en CSS/theme. No necesita coordinación compleja.
- Depende — si es solo backend → subagents. Si incluye frontend login flow + backend + tests → Agent Teams podría justificarse por las dependencias cruzadas.
- Subagents (o incluso solo el parent) — un archivo, sin coordinación necesaria.
- Agent Teams — migración que afecta modelos, queries, migraciones, tests, y potencialmente frontend. Múltiples workstreams con dependencias fuertes.
- Agent Teams — afecta todos los archivos con strings, requiere extracción de strings + traducción + testing + configuración. Múltiples dominios.
- Parent directo — urgencia, un solo problema, debugging iterativo. Ni subagents ni Agent Teams.
Ejercicio 3: Diseñar un Agent Team
Elige el escenario más complejo del ejercicio anterior (o uno propio) y diseña el Agent Team completo:
- Define 3 teammates con nombre, especialización, y tools
- Crea el task board con 8+ tareas
- Define todas las dependencias
- Identifica el camino crítico (la secuencia más larga de dependencias)
Criterios de evaluación
Un buen diseño de Agent Team tiene:
- Teammates claramente diferenciados (no overlap de responsabilidades)
- Dependencias mínimas (maximizar trabajo paralelo)
- Camino crítico identificado (saber qué tarea optimizar primero)
- Sin dependencias circulares (#A depende de #B que depende de #A → error)
- Tareas de granularidad apropiada (ni "implementa todo" ni "cambia esta línea")
Ejercicio 4: Simular Agent Teams con subagents
Ya que Agent Teams está en preview, simula el modelo usando subagents:
- Define las tareas como lo haría un team lead
- Ejecuta cada "fase" como un prompt separado a Claude Code
- Usa subagents (Explore, Plan) para las tareas de análisis
- Ejecuta tareas de implementación secuencialmente respetando dependencias
Fase 1: "Explora el proyecto y diseña el schema para
la nueva feature" (Explore + Plan subagents)
Fase 2: "Implementa el backend basándote en el plan"
(Parent agent)
Fase 3: "Implementa el frontend que consume la API"
(Parent agent, con contexto del paso 2)
Fase 4: "Genera tests para la feature completa"
(Parent agent o custom subagent)
Qué aprender de este ejercicio
Este ejercicio te enseña:
- La diferencia entre coordinación manual (subagents) y automática (Agent Teams)
- Cuánto esfuerzo de coordinación ahorraría Agent Teams
- Los puntos donde la información necesita fluir entre fases (y por qué el task board de Agent Teams es valioso)
- Que el modelo mental de Agent Teams se puede aplicar incluso sin la feature
Resumen
Agent Teams representa el siguiente paso en la evolución de Claude Code: de un agente que delega puntualmente (subagents) a un equipo persistente de agentes que se coordinan autónomamente. Aunque todavía está en research preview, entender el modelo mental te prepara para adoptarlo cuando sea estable.
Lo que aprendiste en esta cápsula:
- Agent Teams introduce: team lead, teammates, task board, y resolución de dependencias
- La diferencia clave con subagents: persistencia, autonomía, y coordinación
- Subagents son suficientes para la mayoría de tareas; Agent Teams es para proyectos multi-dominio complejos
- El overhead de Agent Teams solo se justifica cuando la coordinación es el cuello de botella
- El modelo mental (descomposición, dependencias, paralelismo) es aplicable incluso sin la feature
- Agent Teams está en research preview — experimenta pero no construyas workflows de producción sobre él
Módulo completado. Has recorrido el espectro completo de delegación en Claude Code: built-in subagents, custom subagents, y Agent Teams. En el Módulo 07 aprenderás integraciones (Git workflows, SDK headless, Remote Control) que expanden lo que tus agentes pueden hacer.
Recursos adicionales
Documentación oficial
- Sub-agents — Arquitectura de subagents y Agent Teams
- Claude Code Overview — Capabilities y roadmap del producto
- Best Practices — Workflows multi-agente recomendados
Multi-agent systems
- Anthropic Research: Multi-agent coordination — Papers y blog posts sobre orquestación multi-agente
- Plugins Reference — Skills, agents, hooks: el ecosistema completo
Complementarios
- Interactive Mode — Task management y coordinación
- CLI Reference — Flags y configuración para Agent Teams
- Settings — Configuración de permisos para equipos de agentes