Demo: orquestador HTTP y cadena completa

Nota

Antes de correr la demo, completa el deploy de los 7 servicios: Deploy — 7 servicios en Cloud Run.

El orquestador

orchestrator_a2a.py es el script que encadena los 7 agentes via HTTP. Para cada agente:

1. Crea una sesión via la ADK REST API (/apps/{agent}/users/{user}/sessions)
2. Envía un mensaje con la tarea y el contexto acumulado (/run)
3. Extrae la respuesta del agente
4. Acumula el contexto para el siguiente agente

La función clave es build_message, que construye el mensaje con todo el contexto previo:

def build_message(task: str, accumulated_context: list[dict]) -> dict:
    """Construye el mensaje para un agente con contexto acumulado."""
    context_text = ""
    if accumulated_context:
        context_text = "\n\n--- CONTEXTO DE AGENTES ANTERIORES ---\n"
        for entry in accumulated_context:
            context_text += f"\n### {entry['agent']}:\n{entry['response']}\n"

    return {
        "app_name": agent_name,
        "user_id": "orchestrator",
        "session_id": session_id,
        "new_message": {
            "role": "user",
            "parts": [{"text": task + context_text}]
        }
    }

Probar agentes individualmente

Antes de correr la cadena completa, puedes probar un agente individual con curl. Primero crea una sesión:

# Obtener URL y token
URL=$(gcloud run services describe platform-architect --region=us-central1 --format='value(status.url)')
TOKEN=$(gcloud auth print-identity-token --audiences=$URL)

# Crear sesión
curl -X POST "$URL/apps/platform_architect/users/test/sessions" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"state": {}}'

Luego envía una tarea:

# Enviar tarea (usar el session_id de la respuesta anterior)
curl -X POST "$URL/run" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "app_name": "platform_architect",
    "user_id": "test",
    "session_id": "SESSION_ID_AQUI",
    "new_message": {
      "role": "user",
      "parts": [{"text": "Build IDP for Python FastAPI apps"}]
    }
  }'

Exportar URLs

El script set-urls.sh exporta las URLs de los 7 servicios como variables de entorno:

source set-urls.sh

Esto configura variables como PLATFORM_ARCHITECT_URL, INFRASTRUCTURE_URL, etc. que el orquestador usa para saber a dónde enviar cada tarea.

Cadena completa

Con las URLs exportadas, ejecuta la cadena de los 7 agentes:

python orchestrator_a2a.py "Build IDP for Python FastAPI apps"

Output esperado:

▶ [1/7] Platform Architect (https://platform-architect-XXXXX-uc.a.run.app)
  ✓ Completado en 14.2s — stack: Python 3.11, FastAPI, PostgreSQL, Redis

▶ [2/7] Infrastructure (https://infrastructure-XXXXX-uc.a.run.app)
  ✓ Completado en 18.7s — Docker Compose con 4 servicios

▶ [3/7] Security (https://security-XXXXX-uc.a.run.app)
  ✓ Completado en 12.1s — 0 vulnerabilidades críticas

▶ [4/7] CI/CD (https://cicd-XXXXX-uc.a.run.app)
  ✓ Completado en 15.3s — Jenkinsfile + 3 scripts

▶ [5/7] Observability (https://observability-XXXXX-uc.a.run.app)
  ✓ Completado en 16.8s — Prometheus + 2 dashboards Grafana

▶ [6/7] DevEx (https://devex-XXXXX-uc.a.run.app)
  ✓ Completado en 11.4s — CLI tool con 6 comandos

▶ [7/7] Web Portal (https://web-portal-XXXXX-uc.a.run.app)
  ✓ Completado en 22.5s — Portal FastAPI + HTMX

═══════════════════════════════════════
  Cadena completa: 7/7 agentes OK
  Tiempo total: 1m 51s
═══════════════════════════════════════

Logs en tiempo real

Para ver los logs de todos los servicios simultáneamente:

./logs-all.sh

El script abre paneles de tmux con gcloud run logs tail para cada servicio. Útil para debug cuando un agente falla en la cadena.

Para ver logs de un servicio específico sin tmux:

gcloud run logs read platform-architect --region=us-central1 --limit=50

Migración a Vertex AI

Si encuentras errores 503 por rate limits del free tier de Gemini (aistudio.google.com), puedes migrar a Vertex AI sin reconstruir los contenedores.

Paso 1 — Habilitar la API de Vertex AI:

gcloud services enable aiplatform.googleapis.com

Paso 2 — Otorgar el rol de Vertex AI al service account:

PROJECT_NUMBER=$(gcloud projects describe $(gcloud config get-value project) --format='value(projectNumber)')

gcloud projects add-iam-policy-binding $(gcloud config get-value project) \
  --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
  --role="roles/aiplatform.user"

Paso 3 — Actualizar las variables de entorno en cada servicio:

SERVICES="platform-architect infrastructure security cicd observability devex web-portal"

for SERVICE in $SERVICES; do
  gcloud run services update $SERVICE \
    --region=us-central1 \
    --update-env-vars="GOOGLE_GENAI_USE_VERTEXAI=TRUE,GOOGLE_CLOUD_PROJECT=$(gcloud config get-value project),GOOGLE_CLOUD_LOCATION=us-central1"
done

No necesitas rebuild ni redeploy. Cloud Run reinicia los contenedores con las nuevas variables y los agentes usan Vertex AI automáticamente.

Tests con diferentes stacks

El orquestador acepta cualquier descripción de tarea. Prueba con diferentes stacks:

# Python + FastAPI (default)
python orchestrator_a2a.py "Build IDP for Python FastAPI apps"

# Node.js + NestJS
python orchestrator_a2a.py "Build IDP for Node.js NestJS microservices"

# Java + Spring Boot
python orchestrator_a2a.py "Build IDP for Java Spring Boot enterprise apps"

Cada stack produce decisiones diferentes del Platform Architect, que propagan a través de toda la cadena — Docker Compose distinto, CI/CD adaptado, dashboards con métricas diferentes, CLI con comandos del framework elegido.