🎬 GUION: Claude Code Agent Teams + Subagentes — Construye Mejor con IA Colaborativa

🎬 GUION: Claude Code Agent Teams + Subagentes — Construye Mejor con IA Colaborativa

Duración estimada: 45-50 minutos Formato: Concepto + Arquitectura + Demo en vivo Serie: Claude Code (continuación de Agent Skills + ADK + A2A) Repositorio: github.com/nneira/skills-portal-demo (por crear)

---

ESTRUCTURA GENERAL

Segmento	Tiempo	Duración
Hook	0:00 - 2:00	2 min
El problema: construir solo con IA	2:00 - 5:00	3 min
Subagentes vs Agent Teams	5:00 - 15:00	10 min
Arquitectura del sistema	15:00 - 22:00	7 min
Setup en vivo	22:00 - 28:00	6 min
Demo: el team en acción	28:00 - 45:00	17 min
Conexión con los otros videos	45:00 - 47:30	2.5 min
Cierre + CTA	47:30 - 50:00	2.5 min

---

HOOK (0:00 - 2:00)

[Pantalla: Portal skills.nicolasneira.com vacío]

“Este portal no existe todavía.”

[Pantalla: Terminal — 4 panes en tmux, 4 agentes trabajando simultáneamente]

“En unos minutos, un equipo de cuatro agentes IA va a diseñar la infraestructura para levantarlo, debatirla, revisarla, y deployarla en un servidor real con dominio propio y SSL. Sin que yo escriba una línea de Terraform.”

[Time-lapse 30 segundos: agentes debatiendo, terraform plan, terraform apply]

[Pantalla: skills.nicolasneira.com respondiendo 200 OK]

“Pero lo que me importa no es el resultado. Es lo que pasó en el medio.”

[Pantalla: mensaje del Security Engineer al Architect]

Security Engineer → Architect:
"Abriste el puerto 22 a 0.0.0.0/0.
Eso es una botnet en 20 minutos.
No apruebo hasta que lo corrijas."

“Ese mensaje lo mandó un agente a otro agente. No a mí. Entre ellos. Y eso cambió lo que llegó al servidor.”

“Hoy vamos a ver por qué construir con un equipo de agentes produce resultados que un agente solo nunca alcanza. Y la diferencia entre cuándo usar un equipo y cuándo usar subagentes.”

---

PARTE 1: EL PROBLEMA (2:00 - 5:00)

[Cámara directa]

“Hay una trampa en la que caemos cuando empezamos a trabajar con agentes de IA.”

“Le damos una tarea compleja a UN solo agente y esperamos que lo haga perfecto.”

“Y lo hace… más o menos. Genera algo funcional. Pero le faltan cosas. Tiene huecos de seguridad. Decisiones que nadie cuestionó.”

[Pantalla: Terraform generado por un agente solo]

“Miren esto. Puerto 22 abierto a todo internet. State file local — si se pierde el .tfstate, perdemos el control de toda la infra. Instance nano que no da para Docker con tres servicios corriendo.”

“¿El agente se equivocó? No. Hizo exactamente lo que le pedí. El problema es que nadie lo cuestionó.”

“Cuando construís solo — humano o agente — nadie te dice que estás cometiendo un error hasta que el error ya está en producción.”

[Diagrama: un agente vs un equipo]

“La solución no es un agente más inteligente. Es un equipo donde alguien tiene el trabajo explícito de cuestionar.”

“Eso es exactamente lo que vamos a construir hoy.”

---

PARTE 2: SUBAGENTES vs AGENT TEAMS (5:00 - 15:00)

2.1 Qué son los Subagentes (5:00 - 8:00)

[Diagrama en pantalla]

“Antes de meternos al demo, necesito que entiendas la diferencia entre dos patrones de coordinación porque el video entero depende de eso.”

“Un subagente es simple. El agente principal le delega una tarea específica. El subagente la ejecuta y devuelve el resultado. Punto.”

“No hay conversación. No hay debate. El principal le dice qué hacer, el subagente lo hace, calla, y desaparece.”

[Código en pantalla]

“¿Cuándo usás subagentes? Cuando la tarea es acotada y solo importa el output. Buscar en la documentación de AWS qué bundle IDs están disponibles. Ejecutar terraform validate. Hacer un request a una API.”

“Tareas donde el CÓMO no importa. Solo importa lo que devuelve.”

2.2 Qué son los Agent Teams (8:00 - 12:00)

[Diagrama: teammates con flechas bidireccionales]

“Un Agent Team es diferente en una sola cosa que cambia todo: los teammates se pueden hablar directamente entre ellos.”

“No a través del lead. Directamente. El Security Engineer le manda un mensaje al Architect. El Architect responde. Debaten. Se corrigen.”

“¿Cuándo necesitás eso? Cuando el trabajo requiere que alguien cuestione lo que está haciendo otro.”

“Diseñar infraestructura de producción no es ejecutar comandos. Es tomar decisiones con consecuencias reales. ¿Qué puerto abrimos? ¿Qué instance size? ¿Dónde guardamos el state file? Eso requiere criterio. Y el criterio mejora cuando alguien lo cuestiona.”

2.3 La pregunta que decide cuál usar (12:00 - 15:00)

[Pantalla: una sola pregunta grande]

“La pregunta es una sola — y es exactamente la que usa la documentación oficial:”

¿Los trabajadores necesitan comunicarse entre sí
para hacer bien el trabajo?

Sí  →  Agent Team
No  →  Subagentes

“Validar un archivo de Terraform: no necesitan debatir. Un subagente lo ejecuta y devuelve si pasó o falló.”

“Decidir si ese Terraform está listo para producción: sí necesitan debatir. Eso requiere criterio compartido.”

“Y hay un matiz importante que la doc señala: Agent Teams son para research, revisión e hipótesis en paralelo. Si la tarea es secuencial, si todos editan el mismo archivo, si hay muchas dependencias — conviene un agente solo o subagentes. El team no es siempre mejor. Es mejor cuando el trabajo lo requiere.”

[Tabla comparativa en pantalla]

	Subagentes	Agent Teams
Comunicación	Solo reportan al principal	Se hablan entre sí
Coordinación	El principal maneja todo	Task list compartida
Costo tokens	Bajo	Alto
Para qué	Tareas acotadas, solo importa el output	Trabajo que requiere debate y criterio

“Y lo que vamos a ver hoy usa los dos juntos. El team toma las decisiones difíciles. Los subagentes ejecutan sin pensar.”

---

PARTE 3: ARQUITECTURA DEL SISTEMA (15:00 - 22:00)

3.1 El sistema completo (15:00 - 18:00)

[Diagrama en pantalla]

VOS
 │
 ▼
TEAM LEAD
 ├── Infra Architect (Teammate)
 │     └── Subagente: busca bundle IDs actuales en AWS docs
 │     └── Subagente: busca Cloudflare Terraform provider docs
 │     └── Subagente: escribe main.tf, variables.tf, outputs.tf
 │
 ├── Security Engineer (Teammate)
 │     └── Subagente: terraform validate
 │     └── Subagente: revisa puertos, IAM, state file encryption
 │
 └── FinOps Reviewer (Teammate)
       └── Subagente: compara precios de instancias Lightsail
       └── Subagente: verifica que el portal responde 200 OK

“Cuatro teammates. La doc recomienda entre 3 y 5 para la mayoría de workflows — más que eso empieza a generar overhead sin ganancia real. Cuatro calza perfecto con los roles que necesitamos.”

“Lead coordina. Architect diseña. Security cuestiona. FinOps controla los costos.”

“Los subagentes aparecen cuando un teammate necesita ejecutar algo puntual, y desaparecen cuando terminan. Sin overhead de coordinación.”

3.2 Qué vamos a crear: lightsail-cloudflare-deployer (18:00 - 20:00)

[Pantalla: spec de la skill]

“El objetivo del team es crear una skill. No cualquier skill: una que cuando la instales en Claude Code o Cursor, te permite decir ‘levantá un servidor con Docker y Cloudflare’ y el agente genera el Terraform completo y lo deploya.”

“Y vamos a usar esa misma skill para deployar el portal skills.nicolasneira.com en vivo. La skill crea la infraestructura donde ella misma va a vivir.”

3.3 La conexión con Agent Skills (20:00 - 22:00)

[Pantalla: diagrama de las dos capas del video anterior]

“Si viste el video de Agent Skills, esto te va a sonar familiar.”

“Ahí vimos que todo agente tiene dos capas: instrucciones que guían — que el agente puede ignorar — y capacidades que restringen — imposible saltárselas.”

“El Security Engineer del team existe exactamente por eso. Antes de que esta skill llegue a cualquier agente en producción, alguien tiene que revisar que no le estamos dando capacidades peligrosas.”

“No es burocracia. Es el principio de mínimo privilegio aplicado antes de que algo toque un servidor real.”

---

PARTE 4: SETUP (22:00 - 28:00)

4.1 Activar Agent Teams (22:00 - 24:00)

[Editor: settings.json de Claude Code]

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

“Agent Teams es experimental. Deshabilitado por defecto. Lo activo explícitamente porque acá no hay humo: la API puede cambiar, hay limitaciones conocidas, y el comportamiento no está garantizado 100%. Lo digo porque importa saberlo.”

“Y quiero ser preciso sobre qué estamos haciendo: esto es orquestación en CLI para diseñar mejor y generar artefactos de mayor calidad. No es un pipeline autónomo de producción. Es una herramienta que te hace construir mejor lo que después va a producción.”

[Pantalla: dos modos de visualización]

“Antes de arrancar, un punto práctico. Agent Teams tiene dos modos de visualización.”

“In-process: todos los teammates en la misma terminal. Usás Shift+Down para navegar entre ellos. Funciona en cualquier terminal.”

“Split panes: cada teammate en su propio panel. Visual, todo visible a la vez. Requiere iTerm2 o tmux — no funciona en VS Code integrated terminal ni en Windows Terminal.”

“Para el video uso split panes porque es lo más visual. Si están en terminal normal, in-process con Shift+Down hace exactamente lo mismo.”

4.2 Estructura del proyecto (25:00 - 27:00)

[Estructura de archivos en pantalla]

claude-code-teams-subagents/
├── CLAUDE.md          # contexto del proyecto para todos los agentes
├── skills/            # donde se guarda la skill generada
├── publish.sh         # publica al portal Hermit
└── validate.sh        # valida con skills-ref

“El CLAUDE.md es lo que todos los teammates leen al arrancar. Les explica qué vamos a crear, cuál es el rol de cada uno, y qué tiene que pasar antes de que algo se publique.”

[Abrir CLAUDE.md]

“Y esto importa por algo que no es obvio: los teammates NO heredan la conversación del lead. Cargan el CLAUDE.md, las skills del proyecto, los MCP configurados — pero no el historial. Si no dejás escrito el contexto acá, cada teammate arranca desde cero.”

“Por eso el CLAUDE.md tiene los roles explícitos, el flujo de aprobación, y las reglas del proyecto. Sin esto, el team no tiene contexto compartido.”

4.3 Levantar Hermit (26:00 - 28:00)

[Terminal]

git clone https://github.com/hermit-labs/hermit
cd hermit
docker compose up -d
# Portal en localhost:8080

“El portal donde vamos a publicar la skill. Open source, self-hosteable, API incluida. No construimos el portal — lo clonamos. El trabajo de los agentes es crear la skill, no reinventar el marketplace.”

---

PARTE 5: DEMO EN VIVO (28:00 - 45:00)

5.1 Lanzar el Agent Team (28:00 - 31:00)

[Terminal, iTerm2 con 4 panes]

“Activamos el split de panes para ver todos los teammates al mismo tiempo. Esto es lo que hace el Agent Team visualmente distinto de cualquier demo que hayan visto.”

Prompt al Team Lead:
"Necesito crear la skill `lightsail-cloudflare-deployer`.
Una skill que permita a Claude Code deployar un VPS en
AWS Lightsail con Docker, dominio en Cloudflare y SSL.
Spawnea al Infra Architect y al Security Engineer.
El Security Engineer debe aprobar antes de publicar.
Cuando esté aprobada, spawneá al FinOps para revisión final."

[Los 4 panes aparecen]

“Fíjense. El Team Lead spawneó a los teammates. Cada uno tiene su propia sesión, su propio contexto.”

[Pantalla: task list compartido]

Tasks:
[ ] terraform-skeleton        → Architect
[ ] security-review           → Security Engineer  (bloqueada hasta terraform-skeleton)
[ ] cost-review               → FinOps             (bloqueada hasta security-review)
[ ] publish-skill             → Lead               (bloqueada hasta cost-review)

“Ven el task list compartido. No es solo una lista — tiene dependencias reales. Security review no puede arrancar hasta que el Architect termine el skeleton. Publish está bloqueado hasta que FinOps apruebe.”

“Esto es coordinación real. Si un teammate intenta marcar su task como completa sin cumplir los criterios, un hook puede impedirlo y devolverle feedback para que corrija. No es enforcement de prod — es coordinación con guardrails.”

5.2 Architect trabaja + lanza subagentes (31:00 - 36:00)

[Pane del Architect activo]

“El Architect está leyendo el CLAUDE.md. Ahora lanza un subagente para buscar los bundle IDs actuales de Lightsail y otro para el Cloudflare Terraform provider.”

[Subagentes disparados, resultados devueltos]

“Los subagentes devolvieron los datos. El Architect los usa para escribir el Terraform. Los subagentes hicieron su trabajo, callaron, y se fueron. Eso es exactamente el patrón correcto.”

[Architect generando main.tf]

resource "aws_lightsail_instance" "portal" {
  name              = var.instance_name
  availability_zone = "${var.region}a"
  blueprint_id      = "ubuntu_22_04"
  bundle_id         = "nano_3_0"
  user_data         = file("scripts/setup.sh")
}

resource "cloudflare_record" "portal" {
  zone_id = var.cloudflare_zone_id
  name    = var.subdomain
  value   = aws_lightsail_static_ip.portal.ip_address
  type    = "A"
  proxied = true
}

“Miren el Terraform tomando forma. Lightsail instance, IP estática, record DNS en Cloudflare, Cloudflare proxy activado para SSL automático.”

5.3 Security Engineer entra — PRIMER MOMENTO WOW (36:00 - 40:00)

[Pane del Security Engineer activo]

“El Architect terminó su versión y se la mandó al Lead. El Lead activó al Security Engineer para revisión. Y acá viene algo que vale la pena pausar.”

[Security Engineer leyendo el Terraform]

“El Security Engineer está leyendo el código. No validando sintaxis — eso lo hace un subagente. Está RAZONANDO sobre si esto es seguro.”

[Mensaje directo del Security Engineer al Architect — visible en pantalla]

Security Engineer → Architect:
"Encontré tres problemas antes de aprobar:

1. Puerto 22 abierto a 0.0.0.0/0 en el firewall.
   Cualquier bot lo encuentra en minutos.
   Usa allowlist de IPs o eliminá el acceso SSH directo.

2. State file local. Si se pierde el .tfstate,
   perdemos el control de toda la infra.
   Necesitamos S3 backend con locking.

3. user_data corre como root sin validación.
   Si el script falla a mitad, el servidor queda
   en estado inconsistente sin forma de recuperarlo.
   Agrega set -e y logging."

“Ese mensaje lo mandó el Security Engineer directamente al Architect. No a mí. Yo solo lo estoy leyendo.”

“Y fíjense qué pasó: no validó sintaxis. Razonó sobre consecuencias reales. Puerto 22 abierto — botnet. State file local — pérdida de control. Script sin manejo de errores — servidor inconsistente.”

“Eso no lo hace un subagente. Eso requiere criterio. Requiere entender qué significa cada decisión en producción. Eso es exactamente para qué existe el Agent Team.”

[Architect incorpora el feedback]

“El Architect corrigió los tres puntos. S3 backend configurado, puerto 22 con allowlist, script con manejo de errores.”

[Subagente ejecuta terraform validate]

terraform validate
✓ Success! The configuration is valid.

5.4 FinOps entra — SEGUNDO MOMENTO WOW (40:00 - 43:00)

[Lead activa al FinOps Reviewer]

“Security aprobó. Ahora el Lead activa al FinOps.”

[Mensaje del FinOps al Architect]

FinOps → Architect:
"El bundle nano_3_0 es $3.50/mes — bien.
Pero tenés Docker + Hermit + Nginx corriendo juntos.
Con 512MB RAM, el portal va a swappear constantemente.

Opciones:
- micro_3_0: $5/mes, 1GB RAM — recomendado para este stack
- Quedarse con nano + configurar swap de 1GB — gratis pero más lento
- nano ahora, snapshot + upgrade cuando la carga justifique — más trabajo

¿Cuál preferís? No puedo aprobar sin una decisión documentada."

“El FinOps no rechazó la decisión. La cuestionó con contexto real y presentó opciones. Eso es diferente.”

“Y lo importante: pide que la decisión quede DOCUMENTADA. El Terraform que sale de esto no tiene solo código. Tiene el razonamiento de por qué se eligió ese tamaño.”

[Architect responde y actualiza]

Architect → FinOps:
"Vamos con micro_3_0. El portal es el punto de entrada
del canal — no tiene sentido ahorrar $1.50 y tener
una experiencia lenta."

[FinOps aprueba]

FinOps → Lead:
"Decisión documentada. micro_3_0 justificado
por caso de uso. Aprobado."

5.5 Publicar la skill al portal local (43:00 - 44:00)

[Lead ejecuta el pipeline de publicación]

“Ambas revisiones aprobadas. El Lead activa el subagente de publicación.”

[Subagente ejecuta validate.sh]

./validate.sh skills/lightsail-cloudflare-deployer
✅ Validación pasada: 0 errores

[Subagente ejecuta publish.sh]

./publish.sh skills/lightsail-cloudflare-deployer
✅ Skill publicada (HTTP 201)
🌐 Ver en portal: http://localhost:8080/skills/lightsail-cloudflare-deployer

[Portal Hermit local — skill aparece]

“Ahí está. En el portal local.”

5.6 Usar la skill para deployar el portal real — MOMENTO FINAL (44:00 - 45:00)

[Nueva terminal, Claude Code con la skill instalada]

“Ahora lo meta del demo. Vamos a usar la skill que el team acaba de crear para deployar el portal REAL en producción.”

# Instalar la skill
claude skills install http://localhost:8080/skills/lightsail-cloudflare-deployer

# Pedir el deploy
> "Deployá skills.nicolasneira.com con esta skill.
>  micro_3_0, región us-east-1, Hermit como servicio."

[Claude Code ejecuta el Terraform que el team diseñó]

terraform plan
  + aws_lightsail_instance.portal
  + aws_lightsail_static_ip.portal
  + aws_s3_bucket.terraform_state
  + cloudflare_record.portal

Plan: 4 to add, 0 to change, 0 to destroy.

terraform apply
Apply complete! Resources: 4 added.

Outputs:
  portal_ip  = "52.x.x.x"
  portal_url = "https://skills.nicolasneira.com"

[Navegar a skills.nicolasneira.com en el browser]

“skills.nicolasneira.com. En producción. Con SSL. Diseñado por cuatro agentes que se cuestionaron entre sí. Deployado con la skill que ellos mismos crearon.”

“El Terraform que llegó a este servidor no lo revisé yo solo. Lo revisaron un Security Engineer que atrapó tres huecos de seguridad y un FinOps que justificó cada dólar.”

“Lo que llegó a producción es mejor porque fue debatido antes de llegar.”

---

PARTE 6: CONEXIÓN CON LOS OTROS VIDEOS (45:00 - 47:30)

[Diagrama en pantalla]

“Quiero cerrar con algo que conecta los tres videos de esta serie porque creo que juntos cuentan una historia completa.”

ADK + A2A     →  Construiste 7 agentes que corrían en producción
                  Cada uno con tools=[] — restricciones reales,
                  imposible saltárselas.
                  Capa 2 de verdad.

Agent Skills  →  Entendiste el patrón.
                  Capa 1 instrucciones, Capa 2 capacidades.
                  Por qué se diseñan así, de dónde viene.

Agent Teams   →  Viste cómo construir mejor.
                  No más agentes. Mejores decisiones
                  antes de que algo toque producción.

“Son tres respuestas a tres preguntas diferentes.”

“ADK responde: ¿cómo corro agentes con restricciones reales? Agent Skills responde: ¿por qué se diseñan así? Agent Teams responde: ¿cómo construyo cosas que valgan la pena deployar?”

“Y noten algo: el Security Engineer aplicó exactamente el principio de Agent Skills. Mínimo privilegio. El Terraform que llegó a producción tiene los permisos justos y necesarios — no porque yo lo dije, sino porque un agente lo cuestionó antes.”

“Si mañana quisieras que ese deploy pase automáticamente cada vez que alguien pushea código a main — sin vos en el loop, event-driven, 24/7 — ese es ADK. Lo que construimos hoy sería el artefacto que ese agente ADK ejecutaría. No compiten. Se complementan.”

---

PARTE 7: CIERRE + CTA (47:30 - 50:00)

7.1 Lo que aprendiste (47:30 - 49:00)

[Pantalla: resumen]

“Resumen de lo que vimos:“

✅ Subagentes: tareas acotadas, solo importa el output
✅ Agent Teams: trabajo que requiere debate y criterio
✅ La pregunta clave: ¿necesitan cuestionarse entre sí?
✅ Security Engineer atrapó 3 huecos antes de producción
✅ FinOps documentó la decisión de costo
✅ La skill deployó el portal donde ella misma vive
✅ Lo que llegó a producción es mejor porque fue debatido

7.2 Limitaciones honestas (49:00 - 49:30)

“Las limitaciones reales porque acá no hay humo.”

“Agent Teams es experimental. La doc lo dice explícito.”

“Primero: /resume y /rewind no restauran teammates. Si reanudás la sesión, el lead puede intentar hablar con teammates que ya no existen. El fix: decirle al lead que spawnee nuevos. Incómodo pero funciona.”

“Segundo: el task status a veces lagea y puede bloquear dependencias que ya deberían estar desbloqueadas. Si pasa, marcá la task manualmente.”

“Tercero: una sola sesión de team por vez. No hay teams anidados. El lead es fijo.”

“Cuarto: el shutdown puede ser lento. Si cerrás la terminal antes de que terminen, puede haber procesos colgados.”

“Para diseñar, para construir mejores artefactos, para este tipo de workflow donde vos estás en el loop: funciona increíblemente bien. Para un pipeline crítico sin supervisión humana: todavía no.”

7.3 CTA (49:30 - 50:00)

“Todo el código está en el repositorio en la descripción. CLAUDE.md, scripts, la skill completa — todo listo para que lo clones y construyas encima.”

“Si esto te pareció útil, suscribite. Estamos construyendo acá la comunidad más técnica de agentes IA en español.”

“Y si tenés preguntas sobre cuándo usar Agent Teams versus ADK versus subagentes — dejala en los comentarios. Esa es la conversación que quiero tener.”

“Nos vemos en el próximo.”

---

NOTAS DE PRODUCCIÓN

Setup técnico antes de grabar

• Hermit clonado y corriendo en localhost:8080
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 configurado
• iTerm2 con 4 split panes configurados
• CLAUDE.md del proyecto revisado
• skills-ref instalado: npm install -g @agentskills/skills-ref
• S3 bucket para terraform state creado
• Variables de entorno: AWS_ACCESS_KEY_ID, CLOUDFLARE_API_TOKEN, HERMIT_TOKEN
• Repo github.com/nneira/skills-portal-demo público

Momentos clave — NO cortar

• Mensaje del Security Engineer al Architect (36:00) — el debate real
• Los tres problemas detectados — leerlos despacio, uno por uno
• La respuesta del FinOps con las tres opciones (40:00)
• El terraform apply con los 4 recursos (44:30)
• skills.nicolasneira.com en el browser (44:50)

Diagramas a preparar

1. Subagentes vs Agent Teams (comparación lado a lado)
2. Arquitectura completa (Lead + 3 teammates + 6 subagentes)
3. Las tres capas / tres preguntas (conexión con los otros videos)

Posibles shorts del video

1. “El mensaje del Security Engineer” — el debate entre agentes (45 seg)
2. “¿Cuándo Team, cuándo Subagente?” — la pregunta clave (30 seg)
3. “La skill deployó el portal donde ella misma vive” — el momento meta (40 seg)
4. “FinOps justificó cada dólar” — el análisis de costos (45 seg)

Thumbnail ideas

• 4 terminales en split pane + portal live en producción
• Texto grande: “4 AGENTES IA” + “debaten tu infra”
• Cara pequeña esquina inferior

---

KEYWORDS SEO

Título principal: Claude Code Agent Teams: Construye Mejor con IA Colaborativa (Demo Real)

Alternativas:

• Agent Teams vs Subagentes: Cuándo Usar Cada Uno (Terraform en Producción)
• Cómo 4 Agentes IA Diseñan y Despliegan Infraestructura Mejor que Uno Solo

Keywords descripción: claude code agent teams, subagentes claude, agent teams tutorial español, claude code experimental, terraform agentes ia, lightsail cloudflare terraform, agentes ia coordinados, multi-agent systems, agent skills portal, construir con ia, ia en producción