Protocolo A2A: Comunicación y Federación Inter-Agente

1. La Frontera East-West: Hacia la Malla Multi-Agente Federada

En la arquitectura de sistemas autónomos basados en modelos fundacionales, el aislamiento de un único agente ("monolito cognitivo") ha tocado techo. Ningún modelo, por amplio que sea su contexto o especializada que sea su parametrización, puede abarcar simultáneamente la orquestación empresarial, la auditoría legal, el diagnóstico de firmware IoT de bajo nivel y la gestión de infraestructura de nube sin sufrir alucinaciones de rol o saturación cognitiva.

La ingeniería agéntica moderna se articula en torno a la especialización y federación de múltiples agentes. Si el Protocolo MCP resuelve la conexión vertical hacia abajo (Southbound: Agente ↔ Herramientas) y el Protocolo AG-UI resuelve la conexión vertical hacia arriba (Northbound: Agente ↔ Interfaz de Usuario), el Protocolo A2A (Agent2Agent) ocupa el eje horizontal: la frontera East-West (Este-Oeste) que permite la interacción, subcontratación y entrega de tareas entre agentes autónomos independientes.

Lanzado inicialmente bajo el liderazgo de Google con el respaldo de una amplia coalición de la industria (AWS, Microsoft, IBM, Salesforce, SAP, LangChain, CrewAI y ServiceNow) y gestionado como especificación abierta bajo la Linux Foundation (organización a2aproject), A2A funciona como el protocolo HTTP para agentes de IA: una capa estandarizada para que cualquier agente pueda descubrir qué sabe hacer otro agente, encargarle una tarea compleja y recibir el resultado verificado.

Ver en alta resolución (SVG vectorial)

Especificación Topológica en Texto (Esquema RFC / ASCII para Agentes & Docs)

┌────────────────────────────────────────────────────────────────────────┐
│               1. CAPA DE INTERFAZ & EXPERIENCIA DE USUARIO             │
│   Web / React  •  Mobile App  •  IDE Sidecar  •  Generative UI         │
└───────────────────────────────────┬────────────────────────────────────┘
                                    ▲  [NORTHBOUND]
                                    │  PROTOCOLO AG-UI (SSE / JSON Patch)
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│              2. AGENTE ORQUESTADOR / GENERALISTA (Cliente A2A)         │
│   Descubrimiento de Agent Cards • Enrutamiento Semántico • Validación  │
└───────────────────┬────────────────────────────────┬───────────────────┘
    [EAST-WEST]     │                                │  [SOUTHBOUND]
    PROTOCOLO A2A   │ (JSON-RPC 2.0 / gRPC / REST)   │  PROTOCOLO MCP
                    ▼                                ▼  (JSON-RPC 2.0)
┌───────────────────────────────────────┐   ┌────────────────────────────┐
│  3A. AGENTE ESPECIALISTA REMOTO (A2A) │   │  3B. HERRAMIENTAS LOCALES  │
│  • /.well-known/agent-card.json       │   │  • Bases de Datos SQL/Vec  │
│  • Task State: submitted ➔ working    │   │  • Telemetría IoT & Logs   │
│    ➔ input-required ➔ completed       │   └────────────────────────────┘
│  • Southbound Privado: MCP + Sandbox  │
└───────────────────────────────────────┘

2. El Problema: Los Silos Multi-Agente y la Necesidad de Opacidad

Antes del advenimiento de A2A, cuando dos equipos de ingeniería querían coordinar agentes construidos en diferentes tecnologías, se enfrentaban a barreras insalvables:

• Incompatibilidad de Runtimes: Un agente implementado con LangGraph en Python no podía colaborar de forma nativa con un agente desarrollado en Semantic Kernel (.NET) o CrewAI sin desplegar adaptadores ad-hoc y wrappers frágiles.
• Violación del Principio de Caja Negra (Falta de Opacidad): Los enfoques primitivos de multi-agente forzaban a compartir el historial completo de mensajes (*chat history*), los *system prompts* propietarios, la memoria de largo plazo o incluso las claves de API de las herramientas. Esto es inaceptable en entornos corporativos donde un agente contable de un cliente interactúa con el agente logístico de un proveedor externo.
• Fragilidad ante Tareas Asíncronas y Lentas: Delegar una tarea a otro agente no es una llamada RPC instantánea. Puede requerir minutes de razonamiento, consultas a sensores o pausas de validación. Sin un ciclo de vida estandarizado, las peticiones HTTP sufrían constantes timeouts.

A2A soluciona esta fragmentación garantizando la opacidad absoluta: el agente remoto se comporta como un servicio autónomo delimitado. El agente cliente no necesita saber qué modelo de lenguaje ejecuta el especialista ni qué herramientas internas utiliza; solo necesita consultar su tarjeta de presentación pública, enviar un mensaje con parámetros estructurados y supervisar el ciclo de vida de la tarea.

3. Descubrimiento Dinámico: La Tarjeta de Presentación (Agent Card)

El primer pilar fundamental del protocolo A2A es el mecanismo de auto-descubrimiento. Todo agente compatible con A2A expone un documento JSON público accesible mediante una ruta canónica estándar:

https://<base-url>/.well-known/agent-card.json  (o agent.json)

Este archivo, denominado Agent Card, es la "tarjeta de visita digital" del agente. Permite a orquestadores u otros agentes inspeccionar programáticamente qué problemas sabe resolver, qué formatos de entrada y salida acepta, qué esquemas de autenticación exige y qué capacidades de transporte soporta.

{
  "name": "AuditAgent Pro",
  "description": "Agente autónomo especializado en auditoría forense de contratos inteligentes y análisis de cumplimiento regulatorio NIS2.",
  "url": "https://audit.quijotech.com/a2a",
  "version": "1.2.0",
  "provider": {
    "name": "Quijotech Agentic Research Lab",
    "url": "https://quijotech.com"
  },
  "documentationUrl": "https://quijotech.com/tutoriales/protocolo-a2a.html",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "securitySchemes": [
    {
      "type": "oauth2",
      "description": "Requiere delegación Zero-Trust compatible con RFC 8693 / IETF WIMSE AIMS.",
      "tokenUrl": "https://auth.quijotech.com/token"
    }
  ],
  "defaultInputModes": [
    "application/json",
    "text/plain"
  ],
  "defaultOutputModes": [
    "application/json",
    "text/markdown"
  ],
  "skills": [
    {
      "id": "audit_smart_contract",
      "name": "Auditoría de Smart Contracts",
      "description": "Examina código fuente Solidity o Rust en busca de vulnerabilidades de reentrancia, desbordamiento y control de acceso.",
      "tags": ["blockchain", "security", "audit"],
      "inputModes": ["application/json"],
      "outputModes": ["application/json", "text/markdown"],
      "examples": [
        {
          "description": "Analizar contrato de bóveda de liquidez",
          "input": {
            "sourceCode": "contract Vault { ... }",
            "evmTarget": "cancun"
          }
        }
      ]
    }
  ]
}

Gracias a esta tarjeta, un agente orquestador no necesita estar cableado estáticamente: puede consultar un catálogo o registro distribuido de agentes, descargar sus Agent Cards, seleccionar al especialista más capacitado mediante un algoritmo de licitación o *routing semántico*, y negociar la tarea al instante.

4. El Ciclo de Vida de una Tarea: Máquina de Estados de A2A

En el protocolo A2A, cualquier asignación de trabajo delegada a un agente remoto se modela como una Tarea (Task) con estado. La especificación define un modelo formal de ciclo de vida con estados atómicos:

El objeto Task devuelto por el servidor A2A no es un simple mensaje de texto; encapsula una estructura integral:

// Contrato del Objeto Task (a2a.proto / JSON schema)
interface Task {
  id: string;                     // Identificador global de la tarea
  sessionId?: string;             // Sesión lógica para correlacionar tareas múltiples
  status: {
    state: "submitted" | "working" | "input-required" | "completed" | "failed" | "canceled";
    message?: Message;            // Mensaje o pensamiento explicativo del cambio de estado
    timestamp: string;            // Marca temporal ISO 8601
  };
  artifacts?: Artifact[];         // Documentos, código, tablas o binarios generados
  history?: Message[];            // Registro cronológico de interacción
  metadata?: Record<string, any>; // Metadatos libres de auditoría y telemetría
}

5. Mecanismos de Transporte y Operaciones del Protocolo

A2A ofrece un diseño tri-modal para adaptarse tanto a microservicios en la nube de baja latencia como a APIs públicas a través de Internet:

1. JSON-RPC 2.0 sobre HTTP: Formato universal basado en llamadas a procedimientos remotos enviando objetos JSON estructurados con method y params.
2. RESTful HTTP / JSON: Mapeo estándar con métodos GET y POST sobre endpoints limpios (ej. GET /v1/tasks/{id}, POST /v1/message:send).
3. gRPC (Protocol Buffers): Transporte binario multiplexado sobre HTTP/2 para mallas internas de alta eficiencia (microservicios de agentes en clústeres Kubernetes).

// Petición JSON-RPC 2.0: Host -> A2A Server
{
  "jsonrpc": "2.0",
  "id": "req-98741",
  "method": "message/send",
  "params": {
    "configuration": {
      "acceptedOutputModes": ["application/json", "text/markdown"],
      "historyLength": 10
    },
    "message": {
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Audita este fragmento de contrato y evalúa riesgo de reentrancia."
        },
        {
          "kind": "data",
          "data": {
            "solidity": "function withdraw() public { msg.sender.call{value: bal}(''); balances[msg.sender] = 0; }"
          }
        }
      ],
      "messageId": "msg-client-001"
    }
  }
}

// Respuesta JSON-RPC 2.0: A2A Server -> Host
{
  "jsonrpc": "2.0",
  "id": "req-98741",
  "result": {
    "taskId": "task-sec-4402",
    "status": {
      "state": "working",
      "message": {
        "role": "agent",
        "parts": [{"kind": "text", "text": "Compilando AST y verificando flujos de llamadas externas..."}]
      },
      "timestamp": "2026-10-23T12:05:00Z"
    }
  }
}

Tres Métodos para Recibir Actualizaciones de la Tarea

Dependiendo de las capacidades declaradas en la Agent Card del especialista, el cliente puede optar por tres vías:

• Streaming en Tiempo Real (message/stream o tasks/subscribe): El servidor abre un canal Server-Sent Events (SSE) transmitiendo eventos incrementales (TaskStatusUpdateEvent, TaskArtifactUpdateEvent).
• Notificaciones Push (Webhooks): El cliente registra una URL de retorno en POST /v1/tasks/{id}/pushNotificationConfigs y el agente remoto envía una notificación HTTP cuando la tarea cambia de estado.
• Sondeo (Polling): El cliente realiza peticiones GET /v1/tasks/{id} periódicamente hasta alcanzar un estado terminal.

6. Implementación Práctica: Servidor A2A y Cliente Federado en Python

A continuación se presenta una implementación concisa y funcional de un microservicio que expone una Agent Card oficial y gestiona tareas A2A con FastAPI, junto con un cliente que consume sus servicios.

A. Servidor A2A Especialista (FastAPI)

# a2a_specialist_server.py
import uuid
from typing import Any, Dict, List, Optional
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI(title="Quijotech Code Review A2A Specialist")

# Almacén de tareas en memoria
tasks_db: Dict[str, dict] = {}

# 1. Endpoint Canónico de Descubrimiento (Agent Card)
@app.get("/.well-known/agent-card.json")
async def get_agent_card():
    return {
        "name": "StaticReviewAgent",
        "description": "Especialista en revisión de código estático y detección de fugas de memoria para sistemas distribuidos.",
        "url": "http://localhost:8000",
        "version": "1.0.0",
        "provider": {"name": "Quijotech", "url": "https://quijotech.com"},
        "capabilities": {
            "streaming": False,
            "pushNotifications": False,
            "stateTransitionHistory": True
        },
        "defaultInputModes": ["application/json", "text/plain"],
        "defaultOutputModes": ["application/json"],
        "skills": [
            {
                "id": "review_python_ast",
                "name": "Python AST Security Review",
                "description": "Detecta usos peligrosos de eval, exec o subprocesos no saneados.",
                "tags": ["security", "ast", "python"]
            }
        ]
    }

# Modelos para la creación de tareas
class MessagePart(BaseModel):
    kind: str
    text: Optional[str] = None
    data: Optional[Dict[str, Any]] = None

class Message(BaseModel):
    role: str
    parts: List[MessagePart]

class SendMessagePayload(BaseModel):
    message: Message
    configuration: Optional[Dict[str, Any]] = None

# 2. Endpoint de Recepción y Procesamiento de Tareas (REST /v1/message:send)
@app.post("/v1/message:send")
async def send_message(payload: SendMessagePayload):
    task_id = f"task_{uuid.uuid4().hex[:8]}"
    
    # Extraer código suministrado por el agente cliente
    code_text = ""
    for part in payload.message.parts:
        if part.kind == "text" and part.text:
            code_text += part.text

    # Simulación de análisis cognitivo
    has_vulnerability = "eval(" in code_text or "os.system(" in code_text
    
    task_record = {
        "id": task_id,
        "status": {
            "state": "completed",
            "message": {"role": "agent", "parts": [{"kind": "text", "text": "Revisión de seguridad concluida."}]},
            "timestamp": "2026-10-23T12:15:00Z"
        },
        "artifacts": [
            {
                "name": "security_report.json",
                "mimeType": "application/json",
                "data": {
                    "vulnerable": has_vulnerability,
                    "findings": ["Uso crítico de ejecución insegura detectado"] if has_vulnerability else [],
                    "score": 2.5 if has_vulnerability else 10.0
                }
            }
        ]
    }
    tasks_db[task_id] = task_record
    return {"taskId": task_id, "task": task_record}

# 3. Endpoint de Inspección de Estado (GET /v1/tasks/{id})
@app.get("/v1/tasks/{task_id}")
async def get_task(task_id: str):
    if task_id not in tasks_db:
        raise HTTPException(status_code=404, detail="Tarea no encontrada")
    return tasks_db[task_id]

B. Agente Orquestador Cliente (Python httpx)

El orquestador descubre al agente, verifica sus capacidades, le asigna la tarea y extrae los artefactos producidos:

# a2a_orchestrator_client.py
import httpx
import asyncio

async def delegate_code_review(target_agent_base_url: str, code_snippet: str):
    async with httpx.AsyncClient() as client:
        # 1. Paso de Descubrimiento: Obtener y validar la Agent Card
        card_res = await client.get(f"{target_agent_base_url}/.well-known/agent-card.json")
        card_res.raise_for_status()
        agent_card = card_res.json()
        print(f"[Orquestador] Agente especialista descubierto: {agent_card['name']} v{agent_card['version']}")

        # 2. Paso de Delegación: Enviar tarea formateada en protocolo A2A
        payload = {
            "message": {
                "role": "user",
                "parts": [
                    {"kind": "text", "text": code_snippet}
                ]
            }
        }
        send_res = await client.post(f"{target_agent_base_url}/v1/message:send", json=payload)
        send_res.raise_for_status()
        task_data = send_res.json()["task"]

        # 3. Evaluar estado y procesar entregables
        if task_data["status"]["state"] == "completed":
            artifact = task_data["artifacts"][0]
            print(f"[Orquestador] Tarea finalizada con éxito. Artefacto recibido: {artifact['name']}")
            print(f"[Orquestador] Hallazgos: {artifact['data']}")
            return artifact["data"]

# Ejecución de prueba
if __name__ == "__main__":
    snippet = "import os\ndef run_cmd(user_input): os.system(user_input)"
    asyncio.run(delegate_code_review("http://localhost:8000", snippet))

7. Sinergia Total: La Danza Armónica de MCP, A2A y AG-UI

La verdadera potencia de la ingeniería agéntica se manifiesta cuando los tres protocolos operan en una coreografía integrada:

En este flujo integral, ningún protocolo compite con otro: cada uno opera en su estrato natural, proporcionando modularidad, seguridad y observabilidad extrema.

8. Matriz Comparativa de la Tríada: MCP vs. A2A vs. AG-UI

La siguiente tabla sintetiza las diferencias técnicas cardinales entre los tres grandes estándares abiertos: