Google ADK · A2A Protocol · SequentialAgent
Sin intervención humana. Cero clicks. Pura orquestación multiagente. Docker Compose, Jenkins, Grafana, CLI y portal FastAPI generados por agentes especializados con Gemini function calling.
La analogía que lo explica todo
Nadie les pasa variables. Nadie los coordina manualmente. Cada uno busca y lee lo que el anterior dejó escrito. Eso es A2A en el mundo real: comunicación asíncrona a través de artefactos compartidos.
Eso es exactamente lo que hacen estos 7 agentes. Sin intervención humana, cero clicks, cero edición, pura orquestación multiagente.
Primero el resultado, luego la explicación. Esto es lo que encuentras en el directorio de output cuando los 7 agentes terminan.
Output generado — 21 archivos
test-outputs/idp-adk-sequential/
├── platform-config.yaml ← Arquitecto
├── docker-compose/
│ └── app-stack.yml ← Infraestructura
├── security-report.json ← Seguridad
├── cicd/ ← CI/CD
│ ├── build.sh
│ ├── test.sh
│ └── deploy.sh
├── Jenkinsfile ← CI/CD
├── grafana-dashboards/ ← Observabilidad
│ ├── app-metrics.json
│ └── system-metrics.json
├── cli-tool/idp ← DevEx
├── portal/ ← Web Portal
│ ├── main.py
│ ├── templates/index.html
│ └── Dockerfile
└── orchestration-report.json ← Orchestrator
Docker Compose
Servicios con healthchecks, networks y volúmenes
Security Report
Vulnerabilidades detectadas por el agente de seguridad
CI/CD Scripts
build.sh, test.sh, deploy.sh + Jenkinsfile configurado
Grafana Dashboards
App metrics + System metrics, listos para importar
CLI Tool
Ejecutable con comandos adaptados al stack generado
Portal FastAPI
Dashboard web con visualización Docker en tiempo real
Platform Config
Stack decision documentada con justificación de la IA
Cada agente tiene una sola responsabilidad y lee activamente lo que dejaron los anteriores. Ninguno recibe parámetros directos — todos buscan los artefactos compartidos.
Analiza la tarea y decide el stack completo: runtime, framework, base de datos, CI/CD, monitoreo. Justifica cada decisión. Guarda la configuración en un YAML.
Lee el YAML del Arquitecto y genera el Docker Compose completo con todos los servicios, healthchecks, networks y volúmenes.
Lee las decisiones del Arquitecto y la infraestructura generada. Escanea con Trivy: secrets expuestos, puertos abiertos, imágenes con CVEs. Puede bloquear el pipeline si detecta issues críticos. Genera un reporte estructurado.
Lee el stack decidido y genera los scripts de automatización adaptados: build, test y deploy. Configura el Jenkinsfile para el pipeline completo.
Lee la configuración de infraestructura y genera dos dashboards Grafana: métricas de la aplicación y métricas del sistema. Configura Prometheus.
Lee el stack completo y genera una CLI tool ejecutable con comandos adaptados al proyecto: status, logs, deploy, rollback, scale y más.
Lee la configuración completa del IDP y construye un portal web con FastAPI backend, templates HTML y visualización en tiempo real de los servicios Docker.
Total: ~4.5 minutos · 21 archivos · 7/7 agentes
El SequentialAgent ejecuta los 7 agentes en orden. Pero lo que hace que el sistema funcione de verdad es A2A: cada agente escribe sus decisiones en un archivo y el siguiente las lee activamente.
Flujo de comunicación
# El arquitecto escribe
save_platform_config("Runtime: Python...")
→ platform-config.yaml guardado
# Infraestructura busca y lee
get_platform_config()
→ lee el YAML del arquitecto
→ genera Docker Compose
# Seguridad también lo busca
get_infrastructure_config()
→ lee las decisiones de infraestructura
→ identifica vulnerabilidades
Sin A2A — pipeline clásico
Agente 1 → return output → Agente 2
Acoplamiento directo. Si uno falla,
el chain entero se rompe.
Con A2A — artefactos compartidos
Agente 1 → escribe YAML
Agente 2 → lee YAML activamente
Cada agente es independiente.
Debugging localizado. Modular.
Viene built-in en Google ADK. Le pasas la lista de agentes y los ejecuta en orden. El orchestrator no usa LLM — la secuencia es determinista.
from google.adk.agents import SequentialAgent
orchestrator = SequentialAgent(
name="idp_orchestrator",
sub_agents=[
platform_architect, # 1. Define stack
infrastructure, # 2. Lee y genera Docker Compose
security, # 3. Lee y escanea
cicd, # 4. Lee y genera scripts
observability, # 5. Lee y genera dashboards
devex, # 6. Lee y genera CLI
web_portal # 7. Lee todo y genera portal
]
)
Cada agente tiene tools definidas como funciones Python estándar. Sin decoradores obligatorios, sin schemas JSON manuales. ADK las registra y Gemini decide cuándo y cómo llamar cada una.
Así se define un tool en ADK
# Función Python normal
def save_platform_config(
stack_summary: str
) -> dict:
"""
Args:
stack_summary: "Runtime: Python 3.11
| Framework: FastAPI | ..."
"""
# parsea y guarda config
return {"status": "success"}
# Gemini decide cuándo llamarla
# Tú solo la defines y la registras
Con 13+ parámetros por función, Gemini fallaba al hacer function calling. La tasa de éxito era 0%.
❌ 13 parámetros → 0% success rate
save_config(runtime, framework, database, cloud, cicd, cache, monitoring...)
Reducir a 1 parámetro con formato estructurado en el string. La tasa de éxito pasó a ser muy alta.
✓ 1 parámetro → alta confiabilidad
save_config("Runtime: Python | Framework: FastAPI | ...")
El patrón que replicamos en los 7 agentes
Este mismo patrón — 1 parámetro con formato pipe-separated — se aplicó a las tools de todos los agentes. El resultado: 7/7 agentes con alta tasa de éxito en function calling. Es un hallazgo técnico real, descubierto durante el desarrollo.
1 tool, 1 responsabilidad, inputs mínimos — es exactamente el principio Agent Skills aplicado a ADK.
El Platform Architect toma decisiones reales en cada ejecución. La misma tarea puede producir stacks completamente distintos — porque el modelo razona, no rellena un template.
Ejecución 1
"Build IDP for Python microservices"
Ejecución 2
"Build IDP for Python microservices"
Ejecución 3
"Build IDP for Go microservices"
En el modo interactivo del video, el Platform Architect recibe nuevas instrucciones durante la conversación y adapta sus recomendaciones en tiempo real: empieza recomendando un stack local con Trivy, luego cambia a Google Cloud cuando le pides eso, y finalmente ajusta a AWS + GitLab cuando especificas esa combinación. En cada cambio, explica por qué la recomendación anterior ya no aplica.
Hay tres escenas en el video que muestran multi agent orchestration real — no simulada.
Antes de lanzar el modo automático, se muestra en pantalla que el directorio test-outputs/ está completamente vacío.
Al dar enter, cada agente empieza a trabajar en secuencia — y los archivos van apareciendo en tiempo real en el explorador de archivos.
Al terminar: Docker Compose, Jenkinsfile, dashboards Grafana, portal FastAPI, CLI tool. Todo ahí.
En el modo interactivo, el agente de seguridad recibe una solicitud. Antes de hacer nada, lee activamente las decisiones del arquitecto y las del agente de infraestructura. Como infraestructura no ha corrido aún, responde:
Agente Seguridad:
"He intentado leer las decisiones del agente de infraestructura,
pero no fueron encontradas. El agente de infraestructura
debe ejecutarse primero."
# No lo hardcodearon. El agente realmente sabe
# en qué estado está el sistema.
Después de que los agentes terminan, se ejecuta docker-compose up -d con el archivo que generó la IA.
Jenkins arranca con el job de CI/CD ya configurado. Grafana carga con los dashboards generados.
El portal FastAPI responde en localhost:8001 mostrando el estado de todos los servicios en tiempo real.
Nada de esto es una simulación.
Los mismos 7 agentes, dos formas de interactuar con ellos.
Conversas con cada agente por separado desde el navegador. Ideal para explorar qué hace cada uno, cambiar preferencias y ver las decisiones en tiempo real.
# Un comando lanza todo
./start-interactive-nicolasneira.sh
# Abre localhost:8000
# Selecciona el agente
# Conversa en lenguaje natural
Un comando, los 7 agentes corren en secuencia, 21 archivos generados. Ves el progreso por terminal en tiempo real.
# Un comando, ~4.5 minutos
./start-demo-nicolasneira.sh \
"Build IDP for Python microservices"
# ✓ 21 archivos generados
# ✓ Portal en localhost:8001
Quick Start
1. git clone https://github.com/nneira/google-adk-a2a-idp
2. export GEMINI_API_KEY="tu-api-key"
3. docker build -t adk-agents:hybrid .
4. ./start-demo-nicolasneira.sh "Build IDP for Python microservices"
API key de Gemini disponible en aistudio.google.com/app/apikey
Las dudas más comunes sobre Google ADK, Gemini function calling y el sistema multi-agente.
Google ADK (Agent Development Kit) es el framework oficial de Google para construir agentes de IA con modelos Gemini. Permite definir agentes como objetos Python con tools, instrucciones y un modelo asignado, y orquestarlos en sistemas multi-agente usando componentes como SequentialAgent. A diferencia de otros frameworks, ADK está diseñado específicamente para Gemini y ofrece function calling sin configuración adicional de schemas. En este proyecto se usa para coordinar 7 agentes especializados que generan un Internal Developer Platform completo de forma autónoma.
Gemini function calling es la capacidad del modelo Gemini para decidir cuándo y cómo invocar funciones Python que tú defines. En lugar de que tu código llame a la IA y espere texto, el modelo analiza el contexto y ejecuta funciones concretas: guardar un archivo, consultar una API, leer una configuración. En Google ADK defines esas funciones como Python estándar con type hints y docstrings — el framework las registra y Gemini decide cuándo llamarlas. El aprendizaje técnico clave de este proyecto: más de 13 parámetros por función reduce la tasa de éxito a 0%. La solución es consolidar a 1 parámetro con formato estructurado.
A2A (Agent-to-Agent) Protocol es un estándar de comunicación entre agentes de IA, parte de la Linux Foundation, que permite que se coordinen sin que un orquestador central les pase datos directamente. En lugar de llamadas directas entre agentes, cada uno escribe sus decisiones en artefactos compartidos — archivos YAML, JSON, configuraciones — y el siguiente agente los busca y lee activamente cuando los necesita. En este proyecto el agente de Infraestructura no recibe datos del Arquitecto como parámetro: los busca en el sistema de archivos. Eso hace que cada agente sea independiente y el debugging esté localizado.
SequentialAgent es un tipo de agente orquestador built-in en Google ADK que ejecuta una lista de sub-agentes en orden determinista, uno tras otro. No usa LLM para decidir la secuencia — la ejecución es fija y predecible. Lo defines pasando una lista de agentes y ADK se encarga de ejecutarlos en ese orden. En este proyecto coordina los 7 agentes especializados: Platform Architect primero, luego Infrastructure, Security, CI/CD, Observability, DevEx y Web Portal — aproximadamente 4.5 minutos en total.
Flash-Lite tiene tool calling inconsistente con este sistema — los agentes se quedan conversando en lugar de ejecutar las funciones. Gemini 2.5 Flash tiene una tasa de éxito muy alta para este tipo de orquestación. La diferencia en costo es mínima; la diferencia en confiabilidad es enorme.
Sí, Google ADK soporta otros modelos vía LiteLLM — incluyendo Claude y GPT-4. A2A Protocol es model-agnostic por diseño: es un estándar abierto de Linux Foundation, no está atado a ningún proveedor. El repositorio tal como está usa Gemini 2.5 Flash con google-genai SDK, pero puedes adaptar el modelo cambiando la configuración del agente a LiteLLM sin reescribir las tools ni la lógica de orquestación.
Son un excelente punto de partida — el 80% del trabajo está hecho. Antes de llevar a producción debes revisar: contraseñas hardcodeadas, secrets management y las recomendaciones del security-report.json que el propio sistema genera para ti.
Sí. El SequentialAgent acepta N agentes — para agregar uno, defines su función Python y lo añades a la secuencia. Para cambiar el stack, ajusta el prompt al Platform Architect: él toma la decisión en base a lo que le pides.
El sistema tiene reintentos automáticos: hasta 3 intentos con backoff exponencial antes de declarar un fallo. Si el fallo es crítico, el orchestrator hace rollback en orden inverso y limpia los archivos generados. En la práctica: puedes reiniciar desde el agente que falló sin perder el trabajo de los anteriores.
Repositorio completo
github.com/nneira/google-adk-a2a-idp
Video completo — 49 min
youtube.com/@NicolasNeiraGarcia
¿Por qué los agentes de este IDP están bien diseñados? → Agent Skills
Cada agente de este sistema sigue el patrón Agent Skills: acotado, reutilizable y seguro. Si quieres entender la arquitectura conceptual detrás de cómo se diseñaron las tools, la separación de capas y por qué A2A funciona así — esa es la página.