VIDEO · ~43m
ADK · A2A · Cloud Run · GCP
7 agentes ADK en producción con Cloud Run
Cada agente es un servicio independiente con su propia URL, su propio contenedor, y escala a cero. Se comunican por HTTP usando el protocolo A2A.
ADK · A2A · Cloud Run · GCP
Cada agente es un servicio independiente con su propia URL, su propio contenedor, y escala a cero. Se comunican por HTTP usando el protocolo A2A.
El problema
En Docker, los 7 agentes comparten /app/outputs/. El agente 1 escribe, el agente 2 lee. Funciona porque es un solo host con un solo disco.
En Cloud Run cada contenedor es aislado — no hay disco compartido, no hay memoria compartida, no hay proceso compartido. La carpeta /app/outputs/ existe, pero solo la ve el contenedor que la creó.
Docker (local):
Agent 1 ──write──▶ /app/outputs/platform.json
Agent 2 ──read───▶ /app/outputs/platform.json ✅
Cloud Run (producción):
Container 1 ──write──▶ /app/outputs/platform.json
Container 2 ──read───▶ /app/outputs/platform.json ❌ (no existe)
Cada contenedor tiene su propio filesystem efímero.El protocolo A2A permite enviar contexto acumulado en cada request. El estado viaja en los mensajes, no en el disco.
Orquestador
│
├──▶ Agent 1 (Platform Architect)
│ "Diseña el stack para este proyecto"
│ ◀── respuesta: { stack: "FastAPI + PostgreSQL + Redis" }
│
├──▶ Agent 2 (Infrastructure)
│ "Genera Dockerfile. Contexto anterior: { stack: FastAPI... }"
│ ◀── respuesta: { dockerfile: "...", compose: "..." }
│
├──▶ Agent 3 (Security)
│ "Aplica seguridad. Contexto: { stack: ..., dockerfile: ... }"
│ ◀── respuesta: { policies: "...", tls: "..." }
│
└──▶ ... (el contexto crece en cada paso)Cada agente recibe el contexto acumulado de los agentes anteriores como parte del mensaje A2A. No necesita leer archivos del filesystem. El orquestador es el que acumula y reenvía.
Cada agente es un servicio Cloud Run independiente con su propia URL y su propio contenedor.
Analiza la tarea y decide el stack tecnológico
Genera Dockerfile y docker-compose
Políticas, RBAC y TLS
Pipelines de build, test y deploy
Monitoreo con Prometheus y dashboards Grafana
CLI tool con comandos del proyecto
Dashboard web completo
Para pasar de local a Cloud Run, cada agente necesita su propio Dockerfile, su agent.json y tools que acepten contexto.
Dockerfile propio
Python 3.13-slim + uv + el flag --a2a que levanta el servidor A2A.
FROM python:3.13-slim
COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN uv sync --frozen --no-dev
COPY . .
CMD ["uv", "run", "adk", "api_server", "--a2a", \
"--host", "0.0.0.0", "--port", "8080"]agent.json — tarjeta A2A
El archivo que le dice al mundo qué hace este agente y cómo llamarlo.
{
"name": "Platform Architect",
"description": "Analiza la tarea y decide el stack",
"url": "https://platform-architect-xxxxx.run.app",
"version": "1.0.0",
"capabilities": {
"streaming": false,
"pushNotifications": false
},
"skills": [{
"id": "platform-design",
"name": "Platform Design"
}]
}Tools que aceptan contexto
El refactor clave: cada tool recibe el contexto de los agentes anteriores como parámetro.
Antes (lee del disco)
def get_platform_config():
with open("/app/outputs/
platform.json") as f:
return json.load(f)Después (recibe contexto)
def get_platform_config(
context_json: str = ""
):
return json.loads(
context_json)Un comando por agente. Cloud Run detecta el Dockerfile y hace el build en la nube.
gcloud run deploy platform-architect \
--source agents/platform_architect/ \
--region us-central1 \
--no-allow-unauthenticated \
--min-instances=0 \
--set-secrets=GOOGLE_API_KEY=gemini-api-key:latest \
--cpu-throttling--sourceApunta a la carpeta del agente. Cloud Run detecta el Dockerfile y hace el build con Cloud Build.
--no-allow-unauthenticatedSolo requests con identity token válido. El orquestador se autentica con IAM.
--min-instances=0Escala a cero. No pagas cuando nadie llama al agente.
--set-secretsMonta la API key desde Secret Manager como variable de entorno. Nunca en el código.
--cpu-throttlingCPU solo cuando hay requests activos. Reduce costos en workloads intermitentes.
4 pasos para tener el proyecto listo antes del primer deploy.
1. Autenticación
gcloud auth login
gcloud config set project TU_PROYECTO2. Habilitar APIs
gcloud services enable \
run.googleapis.com \
cloudbuild.googleapis.com \
secretmanager.googleapis.com \
artifactregistry.googleapis.com3. Permisos del service account
# El service account default de Cloud Run necesita:
# - roles/secretmanager.secretAccessor (leer secrets)
# - roles/run.invoker (llamar a otros servicios)
SA="NUMERO-compute@developer.gserviceaccount.com"
gcloud projects add-iam-policy-binding TU_PROYECTO \
--member="serviceAccount:$SA" \
--role="roles/secretmanager.secretAccessor"
gcloud projects add-iam-policy-binding TU_PROYECTO \
--member="serviceAccount:$SA" \
--role="roles/run.invoker"4. API Key en Secret Manager
echo -n "TU_API_KEY" | gcloud secrets create gemini-api-key \
--data-file=- \
--replication-policy="automatic"Lo que descubrí en vivo
Con 7 agentes llamando a Gemini en paralelo, el free tier devuelve 503. La solución: migrar a Vertex AI. No requiere rebuild — solo actualizar variables de entorno.
# 1. Habilitar la API de Vertex AI
gcloud services enable aiplatform.googleapis.com
# 2. Dar el rol al service account
gcloud projects add-iam-policy-binding TU_PROYECTO \
--member="serviceAccount:$SA" \
--role="roles/aiplatform.user"
# 3. Actualizar variables (sin rebuild)
gcloud run services update platform-architect \
--set-env-vars="GOOGLE_GENAI_USE_VERTEXAI=TRUE" \
--set-env-vars="GOOGLE_CLOUD_PROJECT=TU_PROYECTO" \
--set-env-vars="GOOGLE_CLOUD_LOCATION=us-central1"Vertex AI usa las credenciales del service account de Cloud Run directamente. No necesitas API key — la autenticación es via IAM.
Lo más habitual al desplegar agentes ADK en Cloud Run.
Protocolo abierto bajo la Linux Foundation (originalmente de Google) para comunicación entre agentes via HTTP. Cada agente expone endpoints que otros agentes pueden descubrir y llamar.
Cloud Run permite montar GCS FUSE o Filestore NFS, pero Google no los recomienda para comunicación entre servicios. El patrón correcto es que el estado viaje en los mensajes — de centralizado a distribuido.
adk deploy genera un Dockerfile temporal con Python 3.11 y pip sin lock file. No tienes control del build. Para producción, arma tu propio Dockerfile con uv y lock file determinístico.
Sí, con --min-instances=0 y --cpu-throttling. No pagas en idle. Cuando llega un request, Cloud Run levanta un contenedor en segundos.
Cada servicio usa --no-allow-unauthenticated. El orquestador obtiene un identity token via gcloud auth print-identity-token y lo envía en el header Authorization.
Sí. Habilitas la API de Vertex AI, le das el rol aiplatform.user al service account, y seteas 3 variables de entorno. No necesitas rebuild — solo gcloud run services update.
ADK soporta cualquier modelo compatible. Este sistema usa Gemini 2.5 Flash pero puedes cambiarlo en la configuración del agente.
Todo lo que necesitas para empezar.
Canal YouTube
@NicolasNeiraGarcia
ADK · A2A · Claude Code · Automatización · Infraestructura