A2A Protocol en Google ADK: implementación real en un IDP

Dos implementaciones del mismo protocolo

A2A Protocol define cómo los agentes se comunican. El protocolo en sí es un estándar abierto de la Linux Foundation — agnóstico de framework y de modelo. Pero hay diferentes formas de implementarlo según el caso de uso.

	Este sistema (IDP)	Agent Skills
Comunicación	Artefactos en sistema de archivos	HTTP via `RemoteA2aAgent`
Descubrimiento	No aplica — secuencia fija	`agent.json` (AgentCard)
Coordinación	`SequentialAgent` (determinista)	Orquestador con `RemoteA2aAgent`
Acoplamiento	Bajo — cada agente busca lo que necesita	Bajo — cada agente es un servidor HTTP
Ideal para	Pipelines secuenciales con outputs en disco	Sistemas distribuidos con descubrimiento dinámico

Cómo funciona aquí: artefactos compartidos

En este sistema, los agentes no se llaman entre sí — se comunican a través de archivos que escriben y leen en un directorio compartido.

Agente 1 (Platform Architect)
    │
    └── escribe → platform-config.yaml
                         │
                         ▼
             Agente 2 (Infrastructure)
                 │   busca y lee → platform-config.yaml
                 └── escribe → docker-compose/app-stack.yml
                                        │
                                        ▼
                            Agente 3 (Security)
                                │   busca y lee → docker-compose/app-stack.yml
                                └── escribe → security-report.json
                                                      │
                                                      ▼
                                              [... y así sucesivamente]

Nadie le pasa datos a nadie. Cada agente es responsable de buscar lo que necesita.

Las tools que implementan A2A

Cada agente tiene dos tipos de tools Python — una para escribir su output, otra para leer el output del agente anterior:

# Tool de escritura — el agente deja su artefacto
def save_platform_config(stack_summary: str) -> dict:
    """
    Guarda las decisiones de arquitectura como artefacto compartido.

    Args:
        stack_summary: "Runtime: Python 3.11 | Framework: FastAPI | DB: PostgreSQL..."
    """
    # parsea el string y escribe platform-config.yaml
    return {"status": "success", "path": "platform-config.yaml"}


# Tool de lectura — el agente siguiente busca el artefacto anterior
def get_platform_config() -> dict:
    """Lee platform-config.yaml del agente anterior."""
    # lee y parsea platform-config.yaml
    return {"runtime": "python", "framework": "fastapi", "database": "postgresql"}

Qué pasa cuando el artefacto no existe

Cuando un agente intenta leer un artefacto que no fue generado aún — por ejemplo, si llamas al Security Agent antes que al Infrastructure Agent — el agente reconoce la situación y detiene su propia ejecución:

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."

Esto es A2A en acción: el agente conoce el estado del sistema a través de los artefactos disponibles, no por información que alguien le pasó. No hay datos ficticios, no hay improvisación.

Formato de confirmación entre agentes

Cada agente escribe un reporte estructurado de su ejecución. El Orchestrator los agrega en orchestration-report.json:

{
  "agent_id": "infrastructure-agent",
  "timestamp": "2026-01-29T10:30:15Z",
  "status": "success",
  "result": {
    "files_generated": [
      "docker-compose/app-stack.yml"
    ],
    "decisions": {
      "database": "PostgreSQL 15 — robusto y compatible con FastAPI",
      "cache": "Redis Alpine — imagen mínima para el scope local"
    }
  }
}

Por qué artefactos en disco y no HTTP

En el repo Agent Skills, los agentes corren como servidores HTTP separados y se descubren dinámicamente via agent.json. Aquí usamos artefactos en disco porque:

Es un pipeline secuencial — el orden es fijo, no hay descubrimiento dinámico necesario
Los outputs son archivos — Docker Compose, YAML, JSON, scripts Bash. Tiene sentido que la comunicación también sea por archivos
Debugging más simple — puedes inspeccionar el estado del sistema en cualquier punto leyendo los archivos generados
Sin infraestructura de red — no necesitas servidores HTTP corriendo para comunicación local

Ventajas del patrón

Debugging localizado — si el CI/CD Agent falla, los artefactos de Architect, Infrastructure y Security ya están en disco. Relanzas solo ese agente.
Independencia real — puedes correr el Security Agent de forma aislada contra cualquier docker-compose.yml, no solo el generado por este sistema.
Trazabilidad completa — cada decisión de cada agente queda registrada en un archivo legible por humanos.
Sin acoplamiento temporal — los agentes no necesitan estar corriendo al mismo tiempo. Escribes el artefacto, el siguiente lo lee cuando le toca.