GUION v1 — 13 AGENTES desplegando ADK/A2A en PRODUCCIÓN

“6 Agentes Claude Code despliegan 7 Agentes ADK en Cloud Run usando el protocolo A2A”

Duración objetivo: 45-50 minutos Patrón: Resultado primero → contexto → concepto → demo en vivo → momento wow → cierre Fecha: 2026-04-01

INTRO — RESULTADO PRIMERO (0:00 - 1:30) 🔥

[PANTALLA: Terminal con 7 URLs de Cloud Run activas]

VOZ:

“¿Y si te dijera que esas 7 URLs que ves ahí son 7 agentes de IA corriendo en producción real, en Google Cloud Run, comunicándose entre ellos usando el protocolo A2A, y que para llegar ahí no toqué ni un solo comando de GCloud manualmente?”

[CORTE A: Claude Code con 6 agentes activos en pantalla — el Deployer ejecutando gcloud run deploy por séptima vez]

VOZ:

“Todo esto lo hicieron 6 agentes de Claude Code. En vivo. Sin intervención humana.”

[CORTE A: Terminal mostrando una llamada A2A real — POST /tasks/send al primer agente, respuesta en JSON con el IDP generado]

TÚ: “Esto es lo que vamos a construir hoy. 13 agentes en total: 6 de Claude Code Agent Teams que hacen el deploy, y 7 agentes ADK que quedan corriendo en producción como servidores A2A independientes. Y todo va a pasar en vivo, frente a la cámara.”

[TÍTULO: “13 AGENTES desplegando ADK/A2A en PRODUCCIÓN (Claude Agent Teams)“]

OPEN LOOPS (1:30 - 2:30)

TÚ: “Tres cosas que vas a ver en este video que no vas a ver en ningún otro lado:”

[PRIMER OPEN LOOP] “Primero: vas a ver al Planner y al Reviewer debatir. No te voy a decir qué van a debatir, pero el debate va a cambiar la configuración del deploy antes de que toque un solo comando.”

[SEGUNDO OPEN LOOP] “Segundo: vas a ver cómo se ve un error real en producción. No lo voy a cortar. No lo voy a editar. El Builder va a encontrar algo, lo va a resolver, y vas a ver cómo lo resuelve.”

[TERCER OPEN LOOP] “Tercero: al final, el agente QA va a hacer una llamada A2A real a los 7 servicios en Cloud Run y me va a decir si la cadena entera funciona. Ese es el momento donde todo se valida. O funciona, o no funciona. Sin editar.”

CONTEXTO — LOS DOS VIDEOS ANTERIORES (2:30 - 6:00)

TÚ: “Antes de arrancar, contexto rápido para los que no vieron los videos anteriores. Porque este video es el crossover de dos cosas que ya construimos.”

[MOSTRAR: Screenshot del video ADK]

“Hace unos meses publiqué este video. 7 agentes ADK construyendo un IDP completo: Platform Architect, Infrastructure, Security, CI/CD, Observability, DevEx, Web Portal. Todo corriendo local, en Docker, usando Google ADK como SequentialAgent. Funcionó. El video anduvo bien.”

[MOSTRAR: Screenshot del video Claude Code Agent Teams]

“Después publiqué este otro. Claude Code Agent Teams: 7 agentes de Claude creando skills de forma autónoma. Lead, Planner, Reviewer, Builder, Deployer, QA. Ese video también anduvo bien.”

TÚ: “Y los dos comparten algo: todo corría local. Era desarrollo. Era demo. Pero no era producción.”

[PAUSA]

“La pregunta que me quedó dando vueltas después de los dos videos fue: ¿qué pasa si combinamos los dos? ¿Si los agentes Claude Code Agent Teams despliegan los agentes ADK a producción real? ¿Cuántos agentes necesitamos en total para hacer eso?”

[MOSTRAR: Diagrama simple — 6 agentes Claude + 7 agentes ADK = 13]

“La respuesta es 13. Y eso es exactamente lo que vamos a hacer hoy.”

CONCEPTO CENTRAL (6:00 - 20:00)

El salto de local a producción (6:00 - 9:00)

TÚ: “El problema con los agentes ADK del video anterior era este.”

[MOSTRAR: Código del orchestrator_adk.py — SequentialAgent]

“Todos los agentes corrían en el mismo proceso Docker. Un SequentialAgent. El Platform Architect terminaba, escribía un archivo, y el Infrastructure lo leía. Compartían filesystem. Eso funciona perfectamente en local.”

[MOSTRAR: Diagrama — filesystem compartido]

“Pero en producción, en Cloud Run, cada agente es un contenedor independiente. No hay filesystem compartido. No hay forma de que el Platform Architect escriba un archivo que el Infrastructure pueda leer.”

[PAUSA — dejar que eso aterrice]

“Entonces tuve que refactorizar. Cada agente necesitaba convertirse en un servidor HTTP independiente. Necesitaba su propia URL, su propio contenedor, y una forma de pasar el contexto entre ellos sin usar disco.”

El protocolo A2A (9:00 - 14:00)

TÚ: “La solución se llama A2A. Agent-to-Agent. Es un protocolo abierto que donó Google a la Linux Foundation. Y es exactamente para esto.”

[MOSTRAR: Diagrama A2A — JSON-RPC 2.0 sobre HTTPS]

“El protocolo es simple. Cada agente expone dos cosas: un agent card en /.well-known/agent.json que describe sus capacidades, y un endpoint POST /tasks/send donde recibes tareas.”

[MOSTRAR: Ejemplo de request A2A]

POST /tasks/send
{
  "jsonrpc": "2.0",
  "method": "tasks/send",
  "params": {
    "id": "task-001",
    "message": {
      "role": "user",
      "parts": [{ "text": "CONTEXTO: {...} TAREA: genera infraestructura" }]
    }
  }
}

“El agente recibe el mensaje, lo procesa, y responde. El orquestador encadena los 7: toma el output del Platform Architect y lo inyecta como contexto en el mensaje al Infrastructure. Y así sucesivamente.”

[MOSTRAR: orchestrator_a2a.py — función build_message]

“Este es el cambio clave respecto al video anterior. El estado ya no vive en disco. Vive en los mensajes. Cada agente recibe todo el contexto que necesita en el cuerpo del request A2A.”

La arquitectura de 13 agentes (14:00 - 18:00)

TÚ: “Con eso claro, la arquitectura completa queda así.”

[DIAGRAMA EN PANTALLA — los 13 agentes organizados]

“Capa 1: Claude Code Agent Teams. 6 agentes. Estos son los que hacen el deploy.”

Lead          → coordina todo, pregunta antes de arrancar
Planner       → teammate: diseña la config de Cloud Run
Reviewer      → teammate: debate y aprueba la config
Builder       → subagente: hace el build y push de las 7 imágenes
Deployer      → subagente: hace el deploy de los 7 servicios a Cloud Run
QA            → subagente: testea los 7 endpoints A2A

“Capa 2: Los 7 agentes ADK en producción. Una vez que el Deployer termina, estos son servicios vivos en Cloud Run con URLs públicas.”

Platform Architect  → https://platform-architect-xxx.run.app
Infrastructure      → https://infrastructure-xxx.run.app
Security            → https://security-xxx.run.app
CI/CD               → https://cicd-xxx.run.app
Observability       → https://observability-xxx.run.app
DevEx               → https://devex-xxx.run.app
Web Portal          → https://web-portal-xxx.run.app

TÚ: “Y hay algo importante sobre los 6 agentes de Claude. No son todos iguales.”

[MOSTRAR: Diferencia teammates vs subagentes]

“El Planner y el Reviewer son teammates. Se pueden ver entre ellos. Pueden debatir, enviar mensajes, llegar a consenso antes de que el Lead tome una decisión. Los otros tres son subagentes: ejecutan sin debatir, cada uno en su dominio.”

“La diferencia importa. El debate del Planner y el Reviewer va a cambiar algo en el deploy. Ya van a ver qué.”

Por qué un Dockerfile por agente (18:00 - 20:00)

TÚ: “Antes de la demo, una pregunta que se van a hacer: ¿por qué cada agente tiene su propio Dockerfile?”

[MOSTRAR: Estructura de carpetas — 7 Dockerfiles]

“Porque cada agente es un servicio independiente en Cloud Run. Para hacer gcloud run deploy --source=. por agente, necesitas que cada carpeta sea autosuficiente: Dockerfile, pyproject.toml, uv.lock.”

[MOSTRAR: Dockerfile — oficial Google]

FROM python:3.13-slim
COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/
EXPOSE 8080
WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN uv sync --no-dev --frozen
COPY . /app/platform_architect/
ENTRYPOINT ["uv", "run", "adk", "api_server", "--host", "0.0.0.0", "--port", "8080"]

“Este es el Dockerfile oficial de Google para ADK en Cloud Run. python:3.13-slim, no Alpine — alpine rompe con grpcio. uv como package manager. Y el entrypoint es adk api_server, que automáticamente expone los endpoints A2A.”

“Siete Dockerfiles idénticos salvo por el nombre del agente. Y esa repetición es intencional: cada servicio es autónomo.”

DEMO EN VIVO (20:00 - 42:00) 🚀

Setup (20:00 - 22:00)

TÚ: “Okay. Demo en vivo. Tengo el proyecto listo acá.”

[MOSTRAR: Estructura de carpetas]

“Tengo los 7 agentes refactorizados. Tengo el orchestrator A2A. Tengo el CLAUDE.md que le dice a los agentes Claude Code exactamente qué tienen que hacer.”

“Voy a abrir Claude Code y lanzar el Lead. El Lead va a coordinar todo.”

[ABRIR: Claude Code]

Momento 1 — El Lead pregunta antes de arrancar (22:00 - 26:00)

TÚ: “Doy la instrucción al Lead: ‘Despliega los 7 agentes ADK a Cloud Run.’”

[MOSTRAR: Lead procesando — lanza a Planner y Reviewer como teammates]

[MOSTRAR: El Lead SE DETIENE y hace una pregunta]

TÚ: “Mira esto. Igual que en el video anterior, el Lead pregunta antes de arrancar. No asumió nada.”

[LEER la pregunta del Lead en voz alta]

[Aquí va la pregunta real que haga el Lead durante la grabación — algo sobre región, memoria, CPU, o si quieres auth o no en los endpoints]

TÚ: “Si hubiera asumido la región, hubiera deployado en la región equivocada. Si hubiera asumido la memoria, los agentes con más carga hubieran fallado. Esta pregunta vale más que el deploy en sí mismo.”

Momento 2 — El debate del Planner y Reviewer (26:00 - 32:00)

TÚ: “El Lead llama al Planner para que diseñe la configuración de Cloud Run.”

[MOSTRAR: Planner diseñando config — memoria, CPU, región, secrets, IAM]

[MOSTRAR: Planner envía su propuesta al Reviewer]

[MOSTRAR: EL DEBATE — Reviewer objeta algo en la config del Planner]

TÚ: “Aquí está. El Reviewer encontró algo.”

[LEER la objeción en voz alta]

[Aquí va la objeción real — probablemente sobre memoria insuficiente para los agentes con más tools, o sobre —no-allow-unauthenticated vs auth, o sobre min-instances]

TÚ: “Y tiene razón. Esto es exactamente para lo que sirve tener un Reviewer. No para frenar el trabajo, sino para que el Builder no gaste 20 minutos deployando algo que iba a fallar.”

[MOSTRAR: El Planner ajusta la config basado en la objeción]

[MOSTRAR: Reviewer aprueba]

TÚ: “Aprobado. El Lead ahora tiene una config validada. Y el Builder puede arrancar.”

Momento 3 — El Builder hace el deploy ×7 (32:00 - 38:00)

TÚ: “El Builder arranca. Su trabajo es hacer gcloud run deploy --source=. siete veces, una por agente.”

[MOSTRAR: Builder ejecutando el primer deploy — platform_architect]

TÚ (narrando mientras corre): “Va a tardar un rato cada uno. Cloud Build está construyendo la imagen, subiéndola a Artifact Registry, y deployando. En vivo. Sin editar.”

[PRIMER DEPLOY COMPLETA — URL aparece en terminal]

TÚ: “Ahí está. Platform Architect: online.”

[CONTINÚA — Infrastructure, Security, CI/CD, Observability, DevEx]

[Si hay un error durante algún deploy, narrarlo en vivo]

TÚ (si hay error): “Mira. Pasó algo. [Leer el error]. Esto es producción real, estas cosas pasan. [El Builder lo resuelve]. Ahí está.”

[SÉPTIMO DEPLOY — Web Portal]

TÚ: “Séptimo. Web Portal.”

[URL APARECE]

TÚ: “Siete de siete.”

Momento 4 — El QA valida la cadena completa (38:00 - 42:00)

TÚ: “Ahora el QA. Su trabajo no es solo hacer ping a los endpoints. Tiene que validar la cadena completa: mandar una tarea A2A al Platform Architect, que ese responda correctamente, y que el orquestador pueda encadenar los siete.”

[MOSTRAR: QA ejecutando orchestrator_a2a.py apuntando a las URLs de Cloud Run]

TÚ: “La tarea: ‘Build IDP for a Python FastAPI application’. La misma del video anterior, pero esta vez los agentes están en producción.”

[MOSTRAR: Logs del A2A — Platform Architect respondiendo desde Cloud Run]

TÚ: “Ahí está. Platform Architect respondió. Desde Cloud Run. Protocolo A2A real.”

[MOSTRAR: La cadena completa — 7/7 respondiendo]

TÚ: “Siete de siete. La cadena completa funciona. Esto no es localhost. Son URLs de producción respondiendo al protocolo A2A.”

MOMENTO WOW — EL IDP DESDE PRODUCCIÓN (42:00 - 46:00) 🌟

TÚ: “Y ahora el momento que quería llegar. Vamos a abrir el Web Portal. El séptimo agente. Pero esta vez no en localhost. En Cloud Run.”

[ABRIR: URL del Web Portal en Cloud Run en el navegador]

[MOSTRAR: El portal cargando desde la URL de Cloud Run]

TÚ: “Este portal fue generado por el séptimo agente ADK. Está corriendo en Google Cloud. Tiene su propia URL. Y si hago una llamada A2A desde el orquestador a la URL de producción…”

[EJECUTAR: llamada A2A directa desde terminal — curl o Python]

curl -X POST https://platform-architect-xxx.run.app/tasks/send \
  -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"tasks/send","params":{"id":"demo","message":{"role":"user","parts":[{"text":"Build IDP for a Go microservices app"}]}}}'

[MOSTRAR: Respuesta JSON del Platform Architect desde Cloud Run]

TÚ: “Este JSON viene de Cloud Run. No de localhost. Un agente ADK corriendo en producción, respondiendo al protocolo A2A, generando una arquitectura para una aplicación Go.”

[PAUSA]

“Esto es lo que no había en los dos videos anteriores. El salto de local a producción.”

LECCIONES Y CIERRE (46:00 - 50:00)

Lecciones clave (46:00 - 48:30)

TÚ: “Tres cosas que aprendí construyendo esto:”

[LECCIÓN 1] “Primero: el filesystem compartido es el enemigo de la escalabilidad. Cuando todo el estado vive en archivos, estás atado a un solo proceso. El protocolo A2A existe exactamente para romper esa dependencia. El contexto viaja en los mensajes, no en el disco.”

[LECCIÓN 2] “Segundo: la diferencia entre teammates y subagentes es más importante de lo que parece. El Planner y el Reviewer son teammates porque necesitaban debatir antes de ejecutar. Si hubiera hecho al Planner un subagente, no habría debate, no habría objeción, y probablemente el deploy hubiera fallado o hubiera quedado mal configurado.”

[LECCIÓN 3] “Tercero: python:3.13-slim y no Alpine. Sé que suena técnico, pero grpcio — que es la dependencia de ADK — no compila en Alpine porque usa musl libc en lugar de glibc. Eso me costó tiempo descubrirlo. Ya no les va a costar a ustedes.”

Cierre (48:30 - 50:00)

TÚ: “Espero que les haya gustado. La pasé bien construyendo esto. Los dos videos anteriores eran desarrollo local — este es el salto a producción real. Con todas sus complicaciones, con el error que vieron en vivo, con el debate del Reviewer que cambió la config.”

“Todo el código está en el repositorio en GitHub, link en la descripción. Los 7 Dockerfiles, el orchestrator A2A, el CLAUDE.md para los agentes. Todo replicable.”

[PAUSA]

“Y una pregunta que me quedó después de esto: ¿qué pasa si los agentes de Claude Code Agent Teams no solo despliegan agentes ADK, sino que los crean desde cero? El Planner diseña la arquitectura, el Builder escribe el código, el Deployer lo manda a producción. Agentes creando otros agentes en producción.”

“Eso sí lo he pensado. Quizás en el próximo video.”

[FADE OUT]

RECURSOS PARA LA GRABACIÓN

Momentos que NO se editan

El debate Planner vs Reviewer (real, tal como salga)
El error del Builder si lo hay (resolverlo en vivo)
Los tiempos reales de cada gcloud run deploy (pueden ser 3-5 min por agente)

Open loops que se cierran

Debate → se cierra en el Momento 2
Error real → se cierra en el Momento 3
QA valida la cadena → se cierra en el Momento 4

B-roll clave

7 URLs de Cloud Run apareciendo en terminal
El debate del Reviewer (mensaje visible en pantalla)
gcloud run deploy completando con URL activa
Llamada curl al endpoint A2A de Cloud Run respondiendo JSON
El portal web cargando desde la URL de producción

Comando de arranque del Lead

Despliega los 7 agentes ADK a Cloud Run como servicios A2A independientes.
El código está en scripts/proyecto-video-idp/agents_adk/.
Cada agente tiene su Dockerfile, pyproject.toml y uv.lock.
Lee el CLAUDE.md del proyecto antes de arrancar.

ESTADO

v1 borrador — ESTE ARCHIVO
Revisión y ajuste
Dry run del deploy completo
Grabación