Demo ADK + A2A: ejecución automática e interactiva del IDP

Los mismos 7 agentes, dos formas de verlos en acción.

Modo automático — pipeline end-to-end

./start-demo-nicolasneira.sh "Build IDP for Python FastAPI apps"

Los 7 agentes corren en secuencia. Esto es lo que sucede en cada paso:

Agente 1 — Platform Architect (~12s)

Recibe la descripción de la tarea y toma las decisiones de stack:

▶ Platform Architect
  Analizando: "Build IDP for Python FastAPI apps"

  Decisiones tomadas:
  ✓ Runtime:     Python 3.11
  ✓ Framework:   FastAPI
  ✓ Base de datos: PostgreSQL 15
  ✓ Cache:       Redis
  ✓ CI/CD:       Jenkins + scripts Bash
  ✓ Monitoreo:   Prometheus + Grafana
  ✓ Seguridad:   Trivy
  ✓ Deploy:      Docker Compose (modo local)

  → Guardando platform-config.yaml
  ✅ Completado

Agente 2 — Infrastructure (~18s)

Lee el platform-config.yaml y genera la infraestructura completa:

▶ Infrastructure Agent
  Leyendo platform-config.yaml...
  Stack detectado: Python + FastAPI + PostgreSQL + Redis

  Generando docker-compose/app-stack.yml:
  ✓ Servicio app (FastAPI) con healthcheck en /health
  ✓ PostgreSQL 15 con volumen persistente y healthcheck
  ✓ Redis Alpine — imagen mínima
  ✓ Prometheus — scrape config para FastAPI
  ✓ Grafana — con datasource pre-configurado

  → Guardando docker-compose/app-stack.yml
  ✅ Completado

Agente 3 — Security (~14s)

Escanea la infraestructura generada con Trivy:

▶ Security Agent
  Leyendo docker-compose/app-stack.yml...

  Escaneando imágenes con Trivy:
  postgres:15        → 0 CRITICAL, 0 HIGH, 2 MEDIUM
  redis:alpine       → 0 CRITICAL, 0 HIGH, 0 MEDIUM
  prom/prometheus    → 0 CRITICAL, 0 HIGH, 1 MEDIUM
  grafana/grafana    → 0 CRITICAL, 0 HIGH, 1 MEDIUM

  Verificando secrets hardcodeados... ninguno detectado
  Verificando puertos expuestos... configuración correcta

  → Guardando security-report.json
  ✅ APPROVED — pipeline puede continuar

Agente 4 — CI/CD (~16s)

Genera los scripts de automatización adaptados al stack:

▶ CI/CD Agent
  Leyendo platform-config.yaml...
  Stack detectado: Docker + Pytest + Jenkins

  Generando:
  ✓ cicd/build.sh     — docker build con tagging semántico
  ✓ cicd/test.sh      — pytest en contenedor aislado
  ✓ cicd/deploy.sh    — docker-compose up con health checks
  ✓ Jenkinsfile       — pipeline: build → test → scan → deploy

  ✅ Completado

Agente 5 — Observability (~19s)

Configura Prometheus y genera los dashboards Grafana:

▶ Observability Agent
  Leyendo configuración de infraestructura...

  Generando:
  ✓ prometheus.yml
    — scrape config para FastAPI en :8000/metrics
    — intervalo: 15s

  ✓ grafana-dashboards/app-metrics.json
    — API Latency (p50, p95, p99)
    — Error Rate por endpoint
    — Request Throughput

  ✓ grafana-dashboards/system-metrics.json
    — CPU usage
    — Memory usage
    — Disk I/O
    — Network in/out

  ✅ Completado

Agente 6 — DevEx (~15s)

Genera la CLI tool del proyecto con comandos adaptados al stack:

▶ DevEx Agent
  Leyendo stack completo...

  Generando cli-tool/idp:
  ✓ idp init     — inicializar nuevo proyecto desde template
  ✓ idp build    — docker build con el tag correcto
  ✓ idp test     — pytest en contenedor
  ✓ idp deploy   — docker-compose up -d
  ✓ idp status   — docker-compose ps con health indicators
  ✓ idp logs     — docker-compose logs -f con filtros

  ✅ Completado

Agente 7 — Web Portal (~45s)

Construye el portal web completo — el artefacto más complejo:

▶ Web Portal Agent
  Leyendo toda la configuración del IDP...

  Generando portal/ (FastAPI + Jinja2 + HTMX + TailwindCSS):
  ✓ main.py
  ✓ routes/dashboard.py         — estado servicios (Docker API)
  ✓ routes/catalog.py           — catálogo de templates
  ✓ routes/services.py          — CRUD servicios
  ✓ templates/base.html         — layout con TailwindCSS
  ✓ templates/dashboard.html    — dashboard principal
  ✓ templates/catalog.html      — templates disponibles
  ✓ templates/create_service.html
  ✓ services/docker_manager.py  — cliente Docker API
  ✓ services/template_manager.py
  ✓ Dockerfile

  ✅ Completado

Resumen final del Orchestrator

═══════════════════════════════════════════════════
  ✅ IDP generado exitosamente

  Agentes ejecutados:  7/7
  Archivos generados:  21
  Tiempo total:        ~4.5 min

  → orchestration-report.json guardado
═══════════════════════════════════════════════════

  Para levantar el IDP generado:

  cd test-outputs/idp-adk-sequential
  docker-compose -f docker-compose/app-stack.yml up -d

  Portal:   http://localhost:8001
  Grafana:  http://localhost:3000
  Jenkins:  http://localhost:8080
═══════════════════════════════════════════════════

También disponible con otros prompts:

./start-demo-nicolasneira.sh "Build IDP for Go microservices with PostgreSQL"
./start-demo-nicolasneira.sh "Build IDP for Node.js apps, deploy to Google Cloud"

Modo interactivo — interfaz web en localhost:8000

./start-interactive-nicolasneira.sh
# Abre http://localhost:8000

Desde la interfaz seleccionas el agente y conversas en lenguaje natural. Estos son los escenarios más reveladores:

Escenario 1 — El Arquitecto que adapta en tiempo real

El Platform Architect no tiene un stack hardcodeado — razona en base a lo que le pides. Puedes cambiar el contexto durante la conversación y el agente adapta sus recomendaciones justificando cada cambio:

> "Diseña la arquitectura para un IDP de microservicios Python"

Platform Architect:
  Recomiendo stack local con Docker Compose, PostgreSQL, Jenkins
  y Trivy para escaneo. Justificación: desarrollo local, control
  total, sin costos de cloud.

> "En realidad vamos a desplegarlo en Google Cloud"

Platform Architect:
  Cambio de recomendación para Google Cloud:
  — Cloud Run en lugar de Docker Compose
  — Cloud SQL en lugar de PostgreSQL local
  — Secret Manager para gestión de secrets
  — Cloud Build para CI/CD
  La arquitectura anterior ya no aplica en este contexto.

> "El equipo prefiere AWS y usa GitLab CI"

Platform Architect:
  Ajustando a AWS + GitLab:
  — ECS Fargate para containers
  — RDS PostgreSQL
  — GitLab CI en lugar de Cloud Build
  — AWS Secrets Manager
  Cada decisión está justificada por el constraint que especificaste.

Tres stacks completamente distintos en la misma sesión. El agente razona, no rellena un template.

Escenario 2 — El Security Agent que no puede continuar

Este escenario muestra A2A en acción: los agentes conocen el estado del sistema a través de los artefactos disponibles.

> [Seleccionas Security Agent directamente en la interfaz]
> "Analiza la seguridad de la infraestructura actual"

Security Agent:
  He intentado leer las decisiones del agente de infraestructura,
  pero el archivo docker-compose/app-stack.yml no fue encontrado.

  El agente de Infrastructure debe ejecutarse primero para que
  pueda analizar la infraestructura generada.

  No puedo continuar sin ese contexto.

El agente no inventó una respuesta. No improvisó con datos ficticios. Buscó activamente el artefacto que necesitaba y, al no encontrarlo, bloqueó su propia ejecución. Esta es la separación de responsabilidades de A2A funcionando en tiempo real.

Escenario 3 — Stack diferente en cada ejecución

La misma tarea produce resultados distintos porque el modelo razona en cada ejecución:

# Primera ejecución
./start-demo-nicolasneira.sh "Build IDP for Python microservices"
# → Runtime: Python 3.11, DB: PostgreSQL, Cache: Redis,
#   Scanner: Trivy, CI: Jenkins

# Segunda ejecución — mismo prompt
./start-demo-nicolasneira.sh "Build IDP for Python microservices"
# → Runtime: Python 3.11, DB: SQLite (más simple para local),
#   Sin cache, Scanner: Bandit, CI: Jenkins

# Tercera ejecución — prompt diferente
./start-demo-nicolasneira.sh "Build IDP for Go microservices"
# → Runtime: Go 1.21, Framework: Gin, DB: PostgreSQL,
#   CI: GitHub Actions, Scanner: Trivy

IA real: el modelo toma decisiones. No es un switch-case disfrazado de agente.