GUION VIDEO: Claude Code Agent Teams: 4 Agentes que Crean Skills para Otros Agentes

GUION VIDEO: Claude Code Agent Teams: 4 Agentes que Crean Skills para Otros Agentes

Título: Claude Code Agent Teams: 4 Agentes que Crean Skills para Otros Agentes Duración estimada: 43-47 minutos Formato: Concepto + Demo en vivo (1 demo completa con 4 agentes) Filosofía: “Sin Humo” — proceso real, no resultado mágico Serie: Trilogía Claude Code Avanzado — Video 3 de 3

---

ESTRATEGIA DE RETENCIÓN

Indicadores en el Guion

Indicador	Significado	Propósito
OPEN LOOP	Promesa que entregas DESPUÉS	Generar anticipación
PAYOFF	Entrega del valor prometido	Recompensar al viewer
PATTERN INTERRUPT	Cambio de ritmo, visual o energía	Romper monotonía
CURIOSITY GAP	Generar curiosidad sobre algo específico	Mantener atención
PROGRESS TRACKING	Mostrar avance en el video	Validar tiempo invertido

Mapa de Retención Minuto a Minuto

Minuto	Técnica	Objetivo
0:00	HOOK — dolor universal de construir	Identificación inmediata
0:45	OPEN LOOP #1	”Minuto 25: 4 agentes debatiendo en vivo, sin que tú intervengas”
1:15	OPEN LOOP #2	”El Redactor va a mejorar algo que ni tú ni el Arquitecto verían al principio”
2:00	CURIOSITY GAP	”¿Cómo saben los agentes qué información buscar?“
5:00	PATTERN INTERRUPT	Cambio a diagrama — Teams vs Subagentes
8:00	PAYOFF conceptual	Explicación completa del CLAUDE.md con roles
11:00	PATTERN INTERRUPT	Task list en pantalla — mecánica visible
17:00	PROGRESS TRACKING	”Ya tienes el setup. Ahora el demo.”
20:00	MEGA PAYOFF #1	Demo empieza — 4 agentes activos
25:00	PAYOFF OPEN LOOP #1	El debate real entre Arquitecto y Revisor
35:00	PAYOFF OPEN LOOP #2	El Redactor mejora lo que el Arquitecto construyó
38:00	MEGA PAYOFF #2	Skill publicada en el portal
40:00	PATTERN INTERRUPT	Análisis post-demo — qué aportó cada agente
43:00	PAYOFF FINAL	Árbol de decisión + cierre de la trilogía

---

KEYWORDS A ATACAR

Primarias (mencionar en primeros 2 minutos):

• “claude code agent teams” — buscar volumen en VidIQ
• “ai agent teams” — buscar volumen en VidIQ
• “claude code experimental” — búsquedas técnicas específicas

Secundarias (distribuir en el video):

• “agent skills” (127K — ya validado en video 1)
• “claude code tutorial” — audiencia de developers
• “ai agents collaborate” — concepto emergente
• “multi agent system” — conecta con video ADK

En español:

• “agentes ia” — general
• “claude code agentes” — específico del canal

---

ESTRUCTURA GENERAL

[0:00-2:00]    HOOK + OPEN LOOPS
[2:00-5:00]    RECAPITULACIÓN DE LA TRILOGÍA
[5:00-8:00]    EL PROBLEMA UNIVERSAL
[8:00-15:00]   AGENT TEAMS vs SUBAGENTES + CLAUDE.md
[15:00-17:00]  POR QUÉ ES DESARROLLO, NO PRODUCCIÓN
[17:00-20:00]  SETUP DEL DEMO
[20:00-38:00]  DEMO LIVE — 4 AGENTES CREAN UNA SKILL
[38:00-41:00]  ANÁLISIS POST-DEMO
[41:00-43:00]  ÁRBOL DE DECISIÓN
[43:00-45:00]  CIERRE DE LA TRILOGÍA + CTA

---

GUION MINUTO A MINUTO

---

[0:00 — 2:00] HOOK + OPEN LOOPS

TOMA: Cámara directa, sin setup, fondo oscuro

GUION:

“Hay un momento en el proceso de diseño que todos hemos vivido.”

[Pausa 1 segundo]

“Terminas algo. Lo revisas. Tiene sentido. Lo publicas o lo presentas con confianza.”

“Y después aparece el caso que no habías pensado. El prerequisito que faltaba. El paso que asumiste que todos conocen.”

[Pausa — mirar directo a cámara]

“No es falta de experiencia. Es que en el momento en que construyes, tienes acceso a una sola perspectiva — la tuya. Y toda perspectiva tiene puntos ciegos.”

“La diferencia cuando trabajas en equipo es que alguien te pregunta ‘¿y si pasa esto?’ antes de que llegue al usuario. Ese cuestionamiento en el momento justo es lo que cambia el resultado.”

[Beat — pausa de 2 segundos]

“Agent Teams mete ese cuestionamiento en tu proceso, en el momento que construyes. No después.”

OPEN LOOP #1 (segundo 45):

“En el minuto 25 vas a ver cuatro agentes debatiendo en tiempo real el diseño de una herramienta. Sin que yo intervenga en el debate. El Arquitecto propone, el Revisor cuestiona, el debate ocurre solo.”

[Mostrar brevemente: terminal con 4 panes activos — agentes trabajando]

OPEN LOOP #2 (segundo 75):

“Y en el minuto 35 el Redactor va a mejorar algo que el Arquitecto construyó — de una manera que ni el Arquitecto ni yo hubiéramos pensado al principio. Eso es lo que me interesa mostrarte: el resultado de tener perspectivas distintas en el momento justo.”

CURIOSITY GAP:

“Y antes de llegar al demo, hay una pregunta que necesitas tener respondida: ¿cómo saben los agentes qué información buscar para construir algo que no les hardcodiaste? Eso lo resolvemos en el minuto 8.”

[Pausa — transición]

“Esto es el tercer video de una trilogía. Si no viste los dos anteriores no pasa nada — vas a entender todo. Pero si los viste, vas a ver exactamente dónde encaja esto en el sistema completo. Vamos.”

TIP DE GRABACIÓN:

• El dolor del primer párrafo debe ir lento, pausado — que aterrice
• “No es falta de experiencia” es el momento de conexión — pausa antes de decirlo
• Los OPEN LOOPs deben sonar como promesas genuinas, no hype
• Velocidad: lenta al inicio, aumenta desde los OPEN LOOPs
• NO mencionar Cloudflare ni ninguna tecnología en los primeros 90 segundos

---

[2:00 — 5:00] RECAPITULACIÓN DE LA TRILOGÍA

TOMA: Cámara a ti 50% + clips de videos anteriores 50%

MICRO-PAYOFF:

“Este es el tercer video de una trilogía. Cada uno responde una pregunta distinta sobre cómo trabajar con agentes IA.”

MOSTRAR EN PANTALLA:

TRILOGÍA CLAUDE CODE AVANZADO

Video 1 — Agent Skills
"¿Cómo defines lo que un agente puede hacer?"
→ Las Reglas

Video 2 — ADK + A2A
"¿Cómo construyes sistemas multi-agente que corren solos?"
→ La Fábrica

Video 3 — Agent Teams (hoy)
"¿Cómo amplificas tu proceso cuando construyes?"
→ El Taller de Desarrollo

[Video 1 — Agent Skills]:

“En el primer video vimos Agent Skills. La idea central: hay dos capas para controlar un agente. Capa 1 — instrucciones en un SKILL.md que guían el comportamiento, el agente puede seguirlas o ignorarlas. Capa 2 — restricciones arquitecturales como tools=[] en ADK, que son imposibles de saltarse porque el agente no tiene acceso a esas funciones. Son esas skills — esos archivos SKILL.md — los que hoy el equipo de agentes va a CREAR.”

[Video 2 — ADK + A2A]:

“En el segundo video construimos la fábrica. Siete agentes con Google ADK coordinados por el protocolo A2A. Cada agente tenía tools=[] como restricción real de Capa 2. Eso puede correr en un servidor, 24/7, sin que yo esté presente. Eso es producción.”

[Frase puente — mirar a cámara]:

“Hoy no corremos nada 24/7. Hoy diseñamos el artefacto que después podría ir a producción. Agent Skills fueron las reglas. ADK fue la fábrica. Agent Teams es el taller de desarrollo donde creas las herramientas que definen las reglas.”

TIP DE GRABACIÓN:

• Esta sección debe durar máximo 3 minutos — no es el foco del video
• Los clips de los videos anteriores deben ser los momentos más visuales (terminal funcionando, agentes en ADK)
• La frase puente “reglas / fábrica / taller de desarrollo” es el momento de articulación — decirla despacio

---

[5:00 — 8:00] EL PROBLEMA UNIVERSAL

TOMA: Cámara directa 70% + diagrama simple 30%

PATTERN INTERRUPT — cambio a tono más conversacional:

“Quiero ir más profundo en el problema, porque si no lo entiendes, el demo va a parecer un truco.”

[Pantalla: diagrama de una persona diseñando]

“En el momento en que construyes algo, tienes acceso a una sola perspectiva — la tuya. Decides qué prerequisitos incluir, qué ejemplos poner, qué casos de error documentar.”

“Y hay categorías enteras de problemas que se te van a pasar — no por negligencia, sino porque en ese momento no los estás viendo.”

MOSTRAR EN PANTALLA:

LOS PUNTOS CIEGOS DEL DISEÑO INDIVIDUAL:

• Usas Mac. No se te ocurre que el comando no existe en Windows.
• Tienes el token de API configurado hace meses. No se te ocurre
  incluir el paso de cómo generarlo.
• Nunca usas Docker en este contexto. No se te ocurre que el
  mapeo de puertos cambia el flujo completo.
• El DNS tardó 2 minutos en propagarse cuando lo probaste.
  No sabes que en producción puede tardar 48 horas.

Estos no son errores de competencia.
Son puntos ciegos de perspectiva.

“Esos no son errores de competencia. Son puntos ciegos de perspectiva. Todos los tenemos.”

[Diagrama: equipo de personas revisando]

“En un equipo tienes revisiones de pares. Alguien que pregunta ‘¿y si pasa esto?’ antes de que llegue al usuario. El problema es que esa revisión no siempre ocurre en el momento justo — hay deadline, el revisor no tiene contexto, simplemente no hay tiempo.”

[Mirar a cámara]

“Agent Teams no te reemplaza. Te da esas perspectivas adicionales en el momento que construyes. Antes de publicar, no después de recibir el error.”

TIP DE GRABACIÓN:

• La lista de puntos ciegos debe ir lento — que cada uno resuene
• “Estos no son errores de competencia” es el momento de validación — pausa antes
• El diagrama puede ser simple (Excalidraw o incluso dibujado a mano)

---

[8:00 — 15:00] AGENT TEAMS vs SUBAGENTES + EL CLAUDE.md

TOMA: Cámara 40% + pantalla 60%

PATTERN INTERRUPT — cambio a pantalla con código/diagramas:

[8:00 — 10:30] Subagentes vs Agent Teams

“Antes del demo, necesitas entender qué hace Agent Teams diferente a lo que Claude Code ya tenía.”

[Diagrama: Agente Principal → Subagente A, B, C]

“Claude Code tiene subagentes hace tiempo. Cuando le dices usa subagentes, lanza instancias independientes que hacen una tarea acotada y te reportan el resultado. La comunicación es en un solo sentido: hacia arriba. El subagente no sabe que existen los otros. No debaten. Hacen su tarea y devuelven el resultado.”

“Son perfectos cuando solo el resultado importa: buscar documentación, validar un archivo, publicar algo a un API.”

[Diagrama: Lead ↔ Arquitecto ↔ Revisor ↔ Redactor, subagentes colgando]

“Agent Teams es diferente en un punto fundamental: los teammates se hablan directamente entre sí. Comparten una task list. Pueden asignarse trabajo. El Arquitecto le puede decir al Revisor ‘revisa el borrador’ — y el Revisor le responde con objeciones concretas, sin que yo intervenga.”

MOSTRAR TABLA:

                    SUBAGENTES          AGENT TEAMS
                    ──────────          ───────────
¿Quién habla?       Solo al principal   Entre sí + al principal
Coordinación        El principal        Task list compartida
Costo en tokens     Bajo                Alto — cada teammate = sesión
Ideal para          Ejecución acotada   Trabajo que requiere debate

“La pregunta práctica para decidir es una sola: ¿los trabajadores necesitan hablarse para hacer el trabajo bien? Si no — subagentes, más barato, más rápido. Si sí — Agent Teams.”

“Diseñar una skill de cero requiere debate. Validarla y publicarla no. Por eso en este demo vamos a combinar los dos.”

[10:30 — 13:00] El CLAUDE.md — cómo defines los roles

PAYOFF del CURIOSITY GAP (minuto 2: “¿cómo saben los agentes qué información buscar?”):

“Y acá viene la respuesta a la pregunta que planteé al principio: ¿cómo saben los agentes qué buscar? No lo saben solos — tú les defines el rol en el CLAUDE.md.”

[Pantalla: editor con el CLAUDE.md del proyecto]

“En ADK+A2A definías cada agente con código Python: instruction=, tools=[], model=. Acá lo haces en un archivo Markdown en la raíz del proyecto. Los agentes lo leen al iniciar y saben cuál es su rol.”

MOSTRAR el contenido del CLAUDE.md — sección de roles:

## Roles del Agent Team

### Lead
Coordina el pipeline.
Crea las tareas en la task list con sus dependencias.
No diseña ni revisa contenido. Solo asegura que el flujo avance.

### Arquitecto
Diseña el contenido técnico de la skill.
ANTES de escribir nada, lanza el subagente Investigador para
buscar la documentación real de la herramienta solicitada.
Escribe el SKILL.md siguiendo el spec de agentskills.io.

### Revisor
Lee el SKILL.md del Arquitecto y lo cuestiona.
DEBE encontrar al menos 2 riesgos reales, 2 ambigüedades o proponer 2 tests
antes de aprobar. Si no los encuentra, debe explicar por qué no.
Preguntas que tiene que hacerse:
- ¿Funciona esto en Docker?
- ¿Qué pasa si el usuario no tiene X configurado?
- ¿Los comandos son válidos para la versión actual?
NO aprueba sin haber encontrado algo concreto.

### Redactor
Entra después del consenso entre Arquitecto y Revisor.
Su trabajo: hacer la skill usable.
Para CADA paso o comando, agregar siempre:
- Output esperado (qué debería ver el usuario si funciona)
- Cómo verificar que funcionó
- Cómo debuggear si algo salió mal
- Mensajes de error con instrucciones exactas de qué ejecutar

“Fíjate en el Revisor: no le pido ‘dos objeciones’ — le pido encontrar riesgos reales, ambigüedades concretas o proponer tests. Si inventa objeciones para cumplir una cuota, se nota. Si no encuentra nada, tiene que explicar por qué. Eso fuerza calidad, no cantidad.”

[Mirar a cámara — énfasis]

“Y esto es importante que lo entiendas: el Revisor bloquea el proceso porque yo se lo pedí en las instrucciones — en Capa 1. No porque el sistema se lo impida físicamente. Si yo no hubiera escrito esa regla en el CLAUDE.md, el Revisor aprobaría sin cuestionar nada. Por eso sigo siendo el humano en el loop. El criterio viene de mí. El equipo lo ejecuta.”

“Y el Investigador no está en esta lista porque no es un teammate — es un subagente que el Arquitecto lanza cuando lo necesita. Aparece, busca la documentación real, y desaparece. No ocupa un pane del terminal permanente.”

[Mirar a cámara]

“Todo esto es Capa 1 — equivalente a instruction= en ADK. Guía el comportamiento pero no lo fuerza arquitecturalmente. Por eso el ambiente necesita supervisión.”

[13:00 — 15:00] La task list — la mecánica que hace al equipo único

“Y la otra pieza que diferencia Agent Teams de subagentes en paralelo es la task list compartida.”

MOSTRAR diagrama de la task list:

TASK LIST COMPARTIDA

[TASK 1] Investigar docs Cloudflare Tunnels  → Investigador   [disponible]
[TASK 2] Diseñar SKILL.md                    → Arquitecto     [dep.→TASK 1]
[TASK 3] Revisar SKILL.md                    → Revisor        [dep.→TASK 2]
[TASK 4] Mejorar ejemplos y errores          → Redactor       [dep.→TASK 3]
[TASK 5] Validar                             → subagente      [dep.→TASK 4]
[TASK 6] Publicar a Hermit                   → subagente      [dep.→TASK 5]

“Publicar no puede empezar hasta que Validar esté completo. Validar hasta que el Redactor termine. El Redactor no puede empezar hasta que el Revisor apruebe. Cada agente ve la lista y toma su tarea cuando las dependencias están resueltas — sin que el Lead tenga que decirle cuándo.”

“Eso es lo que diferencia Agent Teams de lanzar subagentes uno por uno. No hay un orquestador enviando mensajes en cada paso — los agentes se coordinan usando el estado compartido.”

PROGRESS TRACKING:

“Perfecto. Ya sabes la diferencia entre Teams y Subagentes, cómo definir roles en el CLAUDE.md, y cómo funciona la task list. Ahora viene lo que faltaba: por qué esto NO se usa en producción — y por qué eso no es una limitación.”

TIP DE GRABACIÓN:

• El CLAUDE.md debe estar en pantalla suficiente tiempo — es el momento técnico clave
• La instrucción al Revisor (“riesgos reales, no cantidad”) es el insight de diseño — enfatizarlo
• La task list con dependencias es visual — usar colores o highlights para mostrar qué está disponible y qué espera
• Cuando una tarea cambia de estado (dep. pendientes → deps resueltas → in_progress → completed), hacer zoom/overlay de 5-8 segundos sobre el panel de tasks
• Velocidad: moderada, que procesen el CLAUDE.md

---

[15:00 — 17:00] POR QUÉ AGENT TEAMS ES DESARROLLO, NO PRODUCCIÓN

TOMA: Cámara directa

“Antes del setup, algo importante — y esto no es una preferencia, es cómo está diseñado técnicamente.”

“Agent Teams está marcado como experimental con una flag explícita. Anthropic no lo recomienda para sistemas que corren solos, sin supervisión. Tres razones concretas:”

MOSTRAR EN PANTALLA:

POR QUÉ AGENT TEAMS ES DESARROLLO, NO PRODUCCIÓN:

1. Si los teammates debaten y uno toma una dirección equivocada,
   los demás pueden seguirlo. Necesitas un humano para corregir.

2. Agent Teams vive dentro de tu sesión interactiva de Claude Code.
   No es un servicio que despliegas. Cuando cierras el terminal, termina.

3. Los teammates operan en un contexto de supervisión interactiva.
   El supuesto del sistema es que hay alguien mirando.
   No es un runtime autónomo como ADK.

4. Para tareas riesgosas, Agent Teams tiene plan approval:
   el teammate muestra su plan y espera aprobación explícita tuya
   antes de ejecutar. No lo hace automáticamente — espera.
   Más control, no menos.

“Entonces no es que elijo usarlo solo para desarrollo. Es que está diseñado para eso. El caso de uso correcto es este: tú en tu laptop, diseñando algo con el equipo trabajando a tu lado.”

“Y fíjate en el punto 4 — plan approval. Cuando una tarea es riesgosa, el agente no ejecuta solo. Te muestra qué va a hacer y espera que digas sí. Eso no es una limitación — es el mecanismo que mantiene al humano en el loop cuando el sistema lo necesita.”

“El resultado sí va a producción — la skill que creen se publica y cualquiera la puede usar. El proceso de crearla es interactivo, supervisado, tuyo.”

TIP DE GRABACIÓN:

• Tono directo, informativo — no disculpatorio
• Las cuatro razones deben quedar claras — son el diferenciador respecto a ADK
• El punto 4 (plan approval) es el que más conecta con el dolor del hook — enfatizarlo

---

[17:00 — 20:00] SETUP DEL DEMO

TOMA: Pantalla + cámara pequeña arriba

17:00 — Habilitar Agent Teams

“Dos cosas para habilitar esto. Primero, la flag experimental.”

[Mostrar: ~/.claude/settings.json]

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

“Sin esta flag el feature no existe. Con esto activado, Claude Code puede crear teammates cuando se lo pides.”

17:30 — El portal: Hermit

“Las skills que el equipo cree necesitan ir a algún lado. Uso Hermit — portal open source, self-hosted, Docker Compose. No voy a entrar en detalle acá porque no es el foco — lo importante es que es un portal real con API.”

[Terminal: docker compose up -d — 10 segundos] [Browser a localhost:8080]

“Portal vacío ahora. Al final del demo, aparece la skill.”

18:00 — El repositorio

[Mostrar estructura de archivos]

├── CLAUDE.md         ← roles de cada agente (ya lo vimos)
├── validate.sh       ← valida SKILL.md contra el spec
├── publish.sh        ← publica a Hermit
└── skills/           ← donde el equipo crea las skills

“El validate.sh y publish.sh los ejecutan subagentes — no los teammates. El equipo debate y diseña. Los subagentes ejecutan.”

“El validate.sh corre contra el spec de agentskills.io usando skills-ref si está instalado, o una validación local como fallback. No es magia — es una convención que puedes adaptar. Los links están en la descripción.”

PROGRESS TRACKING — HOOK B (re-enganche antes del demo):

“Todo está listo. Ahora viene el momento que esperas: le voy a decir a Claude que cree una skill — en lenguaje natural, sin especificar nada técnico — y el equipo va a investigar, diseñar, debatir y publicar. Sin que yo intervenga en el medio.”

[Pausa]

“Recuerda del Open Loop: ¿cómo saben los agentes qué buscar si yo no les hardcodeo nada? Lo vas a ver ahora.”

TIP DE GRABACIÓN:

• Hermit debe ser rápido — 30 segundos máximo
• El PROGRESS TRACKING es clave para que el viewer no se vaya antes del demo
• El recordatorio del Open Loop reaviva la curiosidad

---

[20:00 — 38:00] DEMO LIVE — 4 AGENTES CREAN UNA SKILL

TOMA: Pantalla completa — terminal de Claude Code

MEGA PAYOFF #1:

[20:00 — 21:30] El prompt — todo empieza con lenguaje natural

“Todo empieza con una frase natural. Sin código, sin especificaciones técnicas.”

[Escribir en Claude Code:]

Necesito una skill para configurar Cloudflare Tunnels desde cero.

Activa el Agent Team con estos roles:
- Arquitecto: diseña la skill. Usa el subagente Investigador
  para buscar documentación real en docs.cloudflare.com y
  developers.cloudflare.com antes de escribir nada.
  Si no encuentras fuente primaria, dilo y pide confirmación.
- Revisor: cuestiona cada decisión. Busca riesgos reales,
  ambigüedades o propone tests. Si no encuentras nada concreto,
  explica por qué.
- Redactor: toma el borrador aprobado. Para cada paso agrega:
  output esperado, cómo verificar, cómo debuggear.

No intervengo en el debate técnico, salvo si se salen del scope
o empiezan a inventar comandos sin fuente.

Cuando los tres lleguen a consenso, usa subagentes para
validar y publicar en Hermit.

“Eso es todo. A partir de acá, el equipo trabaja.”

[21:30 — 23:30] La task list — la mecánica visible

[Mostrar la task list mientras el Lead la construye]

“Lo primero que hace el Lead es crear la task list. Mira la pantalla.”

[Mostrar en pantalla las tareas siendo creadas con sus dependencias]

“Publicar no puede empezar hasta que Validar esté completo. Validar hasta que el Redactor termine. El Redactor no puede empezar hasta que el Revisor apruebe. El Revisor hasta que el Arquitecto diseñe.”

“Y el Arquitecto no puede diseñar hasta que el Investigador le traiga la documentación real.”

“Todo esto lo definió el Lead solo, basándose en el CLAUDE.md. Yo no dicté la secuencia — está inferida de los roles.”

[Mostrar el Investigador siendo lanzado como subagente]

“El Arquitecto toma la TASK 2 y lo primero que hace es lanzar el Investigador. Fíjate: aparece como subagente, no como teammate. No va a debatir, no va a opinar — va a buscar y volver.”

[23:30 — 25:00] El Investigador trabaja

“El Investigador está buscando la documentación actual de Cloudflare Tunnels. No la versión de hace dos años — la actual. Comandos válidos de la CLI cloudflared, el flujo de autenticación, los requisitos de red, los pasos de DNS.”

[Mostrar el reporte que devuelve al Arquitecto — y la documentación original de Cloudflare al lado]

“Le devuelve al Arquitecto un resumen estructurado: versión actual de cloudflared, comandos con sus flags, los pasos en orden, los requisitos de red.”

[Pantalla dividida: doc oficial de Cloudflare Tunnels + reporte del Investigador]

“Fíjate en esto. A la izquierda, la documentación real de Cloudflare. A la derecha, el reporte del Investigador. Los comandos son los mismos. Los flags son los mismos. El agente no inventó nada — buscó, leyó y resumió. Eso es Sin Humo: cuando el resultado viene de una fuente real, no de lo que el modelo recuerda o asume.”

“El Arquitecto va a construir sobre información verificada, no sobre alucinaciones.”

[25:00 — 28:00] El Arquitecto diseña

PAYOFF OPEN LOOP #1:

“El Arquitecto tiene la información. Ahora escribe la skill. Recuerda del Open Loop del inicio — ‘vas a ver cuatro agentes debatiendo en tiempo real’. Acá empieza el debate.”

[Mostrar el Arquitecto escribiendo el SKILL.md]

“Está escribiendo: prerrequisitos, los pasos en orden, un ejemplo básico de configuración. Es un buen primer borrador — tiene la información correcta porque el Investigador buscó docs reales. Pero tiene los puntos ciegos que cualquier primera versión tiene.”

[SKILL.md primer borrador aparece en el editor]

“Terminó. Actualiza la task list — TASK 2 completa. El Revisor lo ve y toma la TASK 3.”

[28:00 — 32:00] El Revisor debate

“El Revisor lee el borrador. Primera objeción:”

[Mostrar mensaje del Revisor al Arquitecto:]

El paso 3 asume que el usuario ejecuta cloudflared directamente
en el host. Si está en Docker, el tunnel necesita
network_mode: host o un mapeo explícito de puertos.
Sin eso, el tunnel no va a poder alcanzar los servicios
internos. ¿Cómo cubrimos el caso Docker?

“El Arquitecto incorpora una sección de Docker. El Revisor vuelve:”

[Segunda objeción:]

El paso de verificación final dice 'visitá tu dominio y
debería funcionar'. Si el DNS no propagó todavía, el usuario
va a ver un error genérico y no va a saber si el problema
es el tunnel o el DNS. Necesita un comando para verificar
propagación antes de ese paso.

“Fíjate en esto. Yo no intervine en ningún momento. El debate ocurrió entre los dos agentes. El Arquitecto incorporó los dos casos. El Revisor aprobó.”

[Pausa — mirar a cámara]

“Esos dos casos — Docker y DNS propagation — son exactamente los que se te pueden pasar cuando construyes solo. El Revisor los encontró antes de que lo publicáramos.”

[32:00 — 36:00] El Redactor mejora

PAYOFF OPEN LOOP #2:

“Arquitecto y Revisor llegaron a consenso. La estructura es correcta. Ahora entra el Redactor — y acá viene el Open Loop que prometí al inicio.”

[Mostrar el Redactor tomando el borrador revisado]

“El trabajo del Redactor no es validar la lógica — es hacer que sea usable. Mira lo que hace con uno de los ejemplos.”

[Mostrar el before/after del ejemplo principal — pantalla dividida]

Antes — del Arquitecto:

# Crear el tunnel
cloudflared tunnel create mi-tunnel

Después — del Redactor:

# Crear el tunnel
cloudflared tunnel create mi-tunnel

# Output esperado:
# Created tunnel mi-tunnel with id abc-123-def-456
# ⚠️ Guarda ese ID — lo vas a necesitar en el Paso 4.

# Si ves "tunnel already exists":
# cloudflared tunnel list  ← para ver tus tunnels existentes
# Usá el ID del tunnel ya creado en lugar de crear uno nuevo.

“¿Ves la diferencia? El Arquitecto puso el comando correcto. El Redactor agregó el output esperado, el aviso de guardar el ID, y qué hacer si aparece el error de ‘tunnel already exists’. Nadie le dijo que eso podía pasar — lo infirió del contexto.”

[Mostrar el mensaje de error de DNS reescrito]

Antes:

Error: Could not verify DNS record

Después:

Error: Could not verify DNS record
→ El DNS no propagó todavía. Normal — puede tardar hasta 5 minutos.
  Para verificar:
  dig @1.1.1.1 tu-subdominio.tudominio.com

  Si no aparece el registro después de 5 min:
  → Verificá en el dashboard de Cloudflare que el CNAME
    apunta a <tunnel-id>.cfargotunnel.com

“Eso no lo hubiera incluido el Arquitecto en el primer borrador. Lo hubiera incluido después de recibir cuatro mensajes preguntando qué significa ese error.”

[36:00 — 38:00] Validación y publicación

“El Redactor marca su tarea completa. El Lead lanza los subagentes en secuencia.”

[Mostrar output del validate.sh]

🔍 Validando: skills/cloudflare-tunnels/SKILL.md

  ✓ Frontmatter presente (---)
  ✓ Campo 'name' en kebab-case
  ✓ Campo 'version' en formato semver
  ✓ Campo 'description' menor a 200 caracteres
  ✓ Campo 'allowed-tools' presente
  ✓ Sección '## Instructions' presente
  ✓ Sección '## Usage Examples' presente
  ✓ Al menos 1 bloque de código presente

────────────────────────────────────────
✅ Validación pasada: 0 errores, 0 advertencias

“Todo verde. El Publisher hace el POST a Hermit.”

[Mostrar curl response → ir al browser]

“Y aquí está. En el portal. Con la sección de Docker, con el comando de verificación de DNS, con los mensajes de error que explican qué hacer.”

[Pausa — mirar a cámara]

“Todo lo que no hubiera incluido si lo hubiera diseñado solo en 10 minutos.”

TIP DE GRABACIÓN:

• El debate Arquitecto ↔ Revisor es EL momento del video — dejarlo correr sin apurar
• Mostrar los mensajes reales entre los agentes, no solo el resultado
• El before/after del Redactor necesita pantalla dividida o transición clara
• El momento de publicación en el portal es el MEGA PAYOFF visual — pausa dramática antes
• Velocidad: demo debe ir a velocidad natural — no acelerar los outputs de los agentes

---

[38:00 — 41:00] ANÁLISIS POST-DEMO — QUÉ APORTÓ CADA AGENTE

TOMA: Cámara directa + SKILL.md con highlights en pantalla

PATTERN INTERRUPT — pausa del demo, análisis:

“Quiero pausar y hacer el análisis que vale la pena hacer.”

[Pantalla: SKILL.md final con secciones resaltadas por color según agente]

“Esta es la skill publicada. Voy a mostrarte qué aportó cada uno.”

[Resaltar secciones:]

“La estructura base — prerrequisitos, pasos en orden, flujo principal — viene del Arquitecto. Es lo que yo también hubiera producido, posiblemente.”

“La sección de Docker y el comando de verificación de DNS — eso es del Revisor. Yo no lo hubiera incluido porque no era parte de mi flujo habitual. El Revisor preguntó ‘¿y si…?’ antes de publicar.”

“Los outputs esperados en cada comando, los mensajes de error con instrucciones específicas, el ‘guarda ese ID’ en el momento justo — eso es del Redactor. La diferencia entre documentación técnicamente correcta y documentación que alguien puede seguir.”

[Mirar a cámara]

“Tres perspectivas, un resultado. Y el proceso tomó menos tiempo que yo construyendo, publicando, recibiendo errores, corrigiendo y republicando.”

[Mostrar tabla en pantalla]

LA TRILOGÍA COMPLETA

Herramienta    ¿Dónde vive?        Objetivo                   Capa de control
────────────   ─────────────────   ────────────────────────   ──────────────────────────────
Agent Skills   Repositorio         El contrato — las reglas   Capa 1 — instrucciones (SKILL.md)
ADK + A2A      Servidor (prod)     Ejecución autónoma         Capa 2 — restricción real (tools=[])
Agent Teams    Terminal (dev)      Desarrollo y refinamiento  Capa 1 + humano en el loop

“Cada herramienta tiene su lugar, su objetivo y su nivel de control. No son intercambiables — son complementarias. Agent Skills define el contrato. ADK lo ejecuta en producción. Agent Teams lo construye en tu laptop antes de que llegue a ningún lado.”

TIP DE GRABACIÓN:

• Los colores por agente en el SKILL.md son clave — preparar el archivo con highlights antes de grabar
• Este momento es de reflexión — bajar la velocidad, tono más tranquilo
• Es el momento donde el viewer entiende el “por qué” del video

---

[41:00 — 43:00] ÁRBOL DE DECISIÓN — CUÁNDO USAR QUÉ

TAMA: Pantalla con árbol de decisión animado o estático

HOOK C — insight final:

“Para cerrar, el mapa de decisión. Porque Agent Teams no reemplaza a los otros — tiene su caso de uso específico.”

MOSTRAR ÁRBOL:

¿Los agentes necesitan hablarse para hacer el trabajo bien?
│
├── NO → Subagentes
│         Ejecución acotada, solo el resultado importa.
│         Más barato, más rápido.
│         Ejemplos: buscar docs, validar un archivo, publicar a API.
│
└── SÍ → ¿El resultado va a correr solo en producción, 24/7?
          │
          ├── SÍ → ADK + A2A
          │         Restricciones reales de Capa 2 (tools=[]).
          │         Corre sin supervisión.
          │         Ejemplos: pipeline de facturación,
          │         soporte automatico, IDP completo.
          │
          └── NO → Agent Teams
                    Diseño asistido — humano en el loop.
                    Supervisado, interactivo, en tu laptop.
                    Ejemplos: crear skills, construir arquitecturas,
                    revisar documentación antes de publicar.
                    ⚠️ No reemplaza tests ni CI —
                       acelera el diseño y la revisión.

“La pregunta más importante no es qué herramienta usar — es qué garantías necesitas. Si necesitas que algo funcione solo, sin errores, sin supervisión: ADK. Si necesitas que algo salga mejor de lo que producirías solo, con alguien cuestionando tus decisiones: Agent Teams.”

TIP DE GRABACIÓN:

• El árbol debe revelarse progresivamente — no de golpe
• Las tres ramas (Subagentes, ADK, Teams) deben quedar claras visualmente
• Velocidad: moderada — que lo copien si quieren

---

[43:00 — 45:00] CIERRE DE LA TRILOGÍA + CTA

TOMA: Cámara directa

PAYOFF FINAL — cierre de los tres videos:

“Con esto cerramos los tres videos.”

[Pausa]

“ADK es ejecución autónoma. Agent Teams es diseño asistido. Agent Skills es el contrato que empaqueta lo diseñado.”

“Tres herramientas, tres propósitos, un sistema completo para trabajar con agentes IA en cualquier contexto.”

CTA:

“El repositorio completo — el CLAUDE.md, los scripts, la skill de ejemplo publicada — está en el link de la descripción.”

“Si lo vas a probar, empieza con una skill de algo que ya conoces bien. Así puedes evaluar si el debate del equipo te da valor real o está inventando problemas que no existen. Esa calibración también es parte del proceso.”

“Si el video te aportó algo, el like le dice al algoritmo que hay gente interesada en este tipo de contenido. Y si tienes preguntas sobre la implementación, los comentarios.”

“Nos vemos en el próximo.”

TIP DE GRABACIÓN:

• “ADK es ejecución autónoma…” — decirlo lento, que suene como el resumen que es
• El CTA debe ser genuino — no robótico
• Dejar 2 segundos de silencio al final antes de cortar

---

NOTAS DE PRODUCCIÓN

Tomas requeridas

• Cold open: en cámara, directo, sin setup — historia del dolor de construir solo
• Cámara: bloques 0:00, 2:00, 5:00, 15:00, 38:00, 41:00, 43:00
• Screen recording: bloques 8:00 en adelante (CLAUDE.md, task list, demo completo)
• Diagrama animado: Subagentes vs Agent Teams (CapCut o Excalidraw)
• Árbol de decisión: con revelación progresiva
• SKILL.md final con highlights por color de agente (preparar antes de grabar)
• Pantalla dividida before/after del Redactor (2 terminales o editor partido)
• Clips de referencia: videos 1 y 2 para el recapitulado

Archivos a preparar antes de grabar

• CLAUDE.md con roles definidos (Lead, Arquitecto, Revisor, Redactor + subagentes: Investigador, Validador, Publisher)
• validate.sh y publish.sh funcionando contra Hermit local
• Portal Hermit corriendo en Docker — probar 48h antes
• .env con token de Hermit configurado
• Skill pregrabada como backup si el demo falla
• SKILL.md con highlights por color (para el análisis post-demo)

Decisión de setup visual — ANTES DE GRABAR

¿Cómo mostrar los 4 panes del terminal?

• Opción A — tmux o iTerm2: 4 panes reales en pantalla simultáneamente. Más impacto visual, más complejo de configurar. Requiere tmux con split panes o iTerm2 con paneles divididos.
• Opción B — modo in-process de Claude Code: Los teammates se muestran en una sola ventana y los ciclas con Shift+Down. Más simple, menos visual, pero es el modo default.

Decidir esto antes del demo — afecta la miniatura “4 AGENTES DEBATEN” y el OPEN LOOP #1.

Advertencias del demo en vivo

• Agent Teams es lento — múltiples sesiones activas. Grabar con red estable.
• Si el Revisor aprueba sin objeciones, pausar y preguntarle explícitamente: “¿qué casos borde no cubrimos?”
• Tener resultado pregrabado del portal como backup si el demo falla en el publish.
• Puerto de Hermit 8080 — verificar que no colisione con otros servicios.

---

SHORTS RECICLADOS

Batch A: Concepto (4 shorts)

Short 1: “El dolor de construir solo” (WHY) — 45 seg

• Timestamp: 0:00-1:00
• El hook completo — el punto ciego universal
• Tags: agent teams, ai agents, desarrollo software

Short 2: “Teams vs Subagentes en 60 segundos” (HOW) — 60 seg

• Timestamp: 8:00-10:30 comprimido
• La tabla comparativa + la pregunta de decisión
• Tags: claude code, agent teams, subagentes ia

Short 3: “El CLAUDE.md que define un equipo de agentes” (HOW) — 60 seg

• Timestamp: 10:30-13:00
• Mostrar el CLAUDE.md con los roles — insight técnico
• Tags: claude code tutorial, ai agents setup

Short 4: “Por qué Agent Teams no es para producción” (WHY) — 45 seg

• Timestamp: 15:00-17:00
• Las tres razones técnicas — diferenciación respecto a ADK
• Tags: claude code experimental, agent teams vs adk

Batch B: Demo (4 shorts)

Short 5: “4 agentes debaten el diseño de una herramienta” (WOW) — 60 seg

• Timestamp: 25:00-32:00 comprimido
• El debate Arquitecto ↔ Revisor en tiempo real
• Tags: agent teams demo, ai agents collaborate, claude code

Short 6: “El before/after del Redactor” (WOW) — 45 seg

• Timestamp: 32:00-36:00
• Pantalla dividida: ejemplo antes y después
• Tags: agent teams, ai developer tools, claude code

Short 7: “Así se publica una skill a un marketplace de IA” (WOW) — 30 seg

• Timestamp: 36:00-38:00
• El portal con la skill publicada — el resultado visual
• Tags: agent skills, ai marketplace, claude code teams

Short 8: “Qué aportó cada agente en la skill” (HOW) — 60 seg

• Timestamp: 38:00-41:00
• El análisis post-demo con el SKILL.md con colores
• Tags: agent teams analysis, ai agents design

Estimado de impacto

Short	Potencial	Razón
Short 5 (debate en vivo)	Alto	Visual, real-time, nunca se ha mostrado así
Short 6 (before/after)	Alto	Resultado tangible e inmediato
Short 7 (marketplace)	Medio-alto	Concepto nuevo + visual impactante
Short 1 (dolor de construir)	Medio	Identificación universal

---

DESCRIPCIÓN SEO

Primeras 3 líneas (críticas para SEO):

Claude Code Agent Teams: 4 agentes que crean Skills para otros
agentes y las publican en un portal self-hosted. En este video
ves el debate en vivo — Arquitecto diseña, Revisor cuestiona,
Redactor mejora — sin que yo intervenga. Tercer video de la
trilogía Claude Code Avanzado.

Tags recomendados:

claude code agent teams, agent teams claude, claude code tutorial,
agent skills, ai agents collaborate, multi agent system,
claude code experimental, ai developer tools, agentes ia,
claude code agentes, agent teams vs subagents, ai agents design

---

COMENTARIO FIJADO

🔗 Repositorio completo (CLAUDE.md, scripts, skill de ejemplo):
→ github.com/nneira/skills-portal-demo

🐳 Portal Hermit (self-hosted):
→ github.com/hermit-labs/hermit

⏱️ Timestamps:
0:00 — Hook: el dolor de construir con una sola perspectiva
2:00 — Recapitulación de la trilogía
5:00 — El problema universal
8:00 — Agent Teams vs Subagentes
10:30 — El CLAUDE.md: cómo defines los roles
13:00 — La task list compartida
15:00 — Por qué es desarrollo, no producción
17:00 — Setup (flag + Hermit + repo)
20:00 — DEMO: el prompt inicial
21:30 — La task list en vivo
23:30 — El Investigador busca documentación real
25:00 — El Arquitecto diseña
28:00 — El Revisor debate
32:00 — El Redactor mejora
36:00 — Validación y publicación en el portal
38:00 — Análisis post-demo: qué aportó cada agente
41:00 — Árbol de decisión: Teams vs Subagentes vs ADK
43:00 — Cierre de la trilogía

🎬 Video anterior — ADK + A2A: [link]
🎬 Video anterior — Agent Skills: [link]

---

MINIATURA (3 opciones)

Opción 1: “El debate”

• Fondo oscuro
• Terminal dividida en 4 panes — agentes trabajando
• Texto grande: “4 AGENTES DEBATEN”
• Texto pequeño: “para crear herramientas para IA”
• Tu cara 20% — expresión de quien observa algo sorprendente

Opción 2: “Before / After”

• Split horizontal: arriba = código simple del Arquitecto, abajo = código completo del Redactor
• Texto central: “ANTES vs DESPUÉS”
• Tu cara pequeña en la esquina
• Sin explicación — la imagen lo dice sola

Opción 3: “El portal”

• Screenshot del portal Hermit con la skill publicada
• Texto encima: “CREADA POR 4 AGENTES IA”
• Tu cara señalando el portal

---

Versión: 3.1 | Fecha: 2026-03-02 | Estado: Correcciones técnicas aplicadas — listo para grabar