Phase 13 - Lesson 19

A2A — Protocolo Agente a Agente

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

MCP es agente-a-herramienta. A2A (Agent2Agent) es agente-a-agente — un protocolo abierto para permitir colaborar a agentes opacos construidos en diferentes frameworks. Lanzado por Google en abril de 2025, donado a la Linux Foundation en junio de 2025, alcanzando la v1.0 en abril de 2026 con más de 150 partidarios, incluidos AWS, Cisco, Microsoft, Salesforce, SAP y ServiceNow. Absorbió el ACP de IBM y agregó la extensión de pagos AP2. Esta lección recorre la Agent Card, el ciclo de vida de la Tarea y las dos vinculaciones de transporte.

Type: Build Languages: Python (stdlib, Agent Card + Task harness) Prerequisites: Phase 13 · 06 (MCP fundamentals), Phase 13 · 08 (MCP client) Time: ~75 minutes

Objetivos de Aprendizaje

• Distinguir los casos de uso de agente a herramienta (MCP) de los de agente a agente (A2A).
• Publicar una Agent Card en /.well-known/agent.json con habilidades y metadados de endpoint.
• Recorrer el ciclo de vida de la Tarea (submitted → working → input-required → completed / failed / canceled / rejected).
• Usar Mensajes con Partes (text, file, data) y Artefactos como salidas.

El Problema

Un agente de servicio al cliente necesita delegar la redacción de informes a un agente redactor especializado. Opciones antes de A2A:

• API REST personalizada. Funciona, pero cada emparejamiento es único (ad-hoc).
• Base de código compartida. Requiere que ambos agentes ejecuten el mismo framework.
• MCP. No encaja: MCP sirve para llamar herramientas, no para que dos agentes colaboren preservando el razonamiento interno opaco de cada agente.

A2A llena este vacío. Modela la interacción como un agente que envía una Tarea a otro, con un ciclo de vida, mensajes y artefactos. El estado interno del agente llamado permanece opaco: el llamador solo ve las transiciones de estado de la tarea y los resultados finales.

A2A es el protocolo para "permitir que agentes de diferentes frameworks hablen entre sí". No reemplaza a MCP; los dos son complementarios.

El Concepto

Agent Card

Cada agente compatible con A2A publica una tarjeta en /.well-known/agent.json:

{
  "schemaVersion": "1.0",
  "name": "research-agent",
  "description": "Summarizes academic papers and drafts citations.",
  "url": "https://research.example.com/a2a",
  "version": "1.2.0",
  "skills": [
    {
      "id": "summarize_paper",
      "name": "Summarize a paper",
      "description": "Read a paper PDF and produce a 3-paragraph summary.",
      "inputModes": ["text", "file"],
      "outputModes": ["text", "artifact"]
    }
  ],
  "capabilities": {"streaming": true, "pushNotifications": true}
}

El descubrimiento se basa en URL: se obtiene la tarjeta, se conoce la URL del endpoint de A2A y se enumeran las habilidades.

Agent Cards Firmados (AP2)

La extensión AP2 (septiembre de 2025) agrega firmas criptográficas a las Agent Cards. Un emisor firma su propia tarjeta con un JWT; los consumidores la verifican. Evita la suplantación de identidad.

Ciclo de vida de la Tarea

submitted -> working -> completed | failed | canceled | rejected
             -> input_required -> working (loop via message)

Los clientes inician con tasks/send. El agente llamado transiciona a través de los estados; los clientes se suscriben a las actualizaciones de estado a través de SSE o realizan consultas (polling).

Mensajes y Partes

Un mensaje contiene una o más Partes:

• text — contenido plano.
• file — blob en base64 con mimeType.
• data — payload JSON con tipo (entrada estructurada para el agente llamado).

Ejemplo:

{
  "role": "user",
  "parts": [
    {"type": "text", "text": "Summarize this paper."},
    {"type": "file", "file": {"name": "paper.pdf", "mimeType": "application/pdf", "bytes": "..."}},
    {"type": "data", "data": {"targetLength": "3 paragraphs"}}
  ]
}

Artefactos

Las salidas son Artefactos, no cadenas de texto sin formato. Un Artefacto es una salida con nombre y tipo:

{
  "name": "summary",
  "parts": [{"type": "text", "text": "..."}],
  "mimeType": "text/markdown"
}

Los artefactos se pueden transmitir en flujo (streaming) como chunks. El llamador los acumula.

Dos vinculaciones de transporte

1. JSON-RPC sobre HTTP. Endpoint /a2a, POST para solicitudes, SSE opcional para streaming. Vinculación predeterminada.
2. gRPC. Para entornos empresariales donde gRPC es nativo.

Ambas vinculaciones tienen el mismo formato lógico de mensaje.

Preservación de la opacidad

Un principio de diseño clave: el estado interno del agente llamado es opaco. El llamador ve el estado de la tarea y los artefactos. La cadena de pensamiento (chain-of-thought) del agente llamado, sus llamadas a herramientas, su delegación a subagentes; todo es invisible. Esto es diferente de MCP, donde las llamadas a herramientas son transparentes.

Justificación: A2A permite a los competidores colaborar sin revelar sus detalles internos. A2A puede ser "llamar a este agente de servicio al cliente" sin que el llamador sepa cómo ese agente implementa el servicio.

Cronología

• 2025-04-09. Google anuncia A2A.
• 2025-06-23. Donado a la Linux Foundation.
• 2025-08. Absorbe el ACP de IBM.
• 2025-09. Se lanza la extensión AP2 (Agent Payments).
• 2026-04. Se lanza la v1.0 con más de 150 organizaciones respaldando.

Relación con MCP

Use MCP cuando desee invocar una herramienta específica. Use A2A cuando desee delegar una tarea completa a otro agente. Muchos sistemas de producción utilizan ambos: un agente utiliza MCP para su capa de herramientas y A2A para su capa de colaboración.

Use It

El archivo code/main.py implementa un arnés A2A mínimo: un agente de investigación publica su tarjeta, un agente redactor recibe un tasks/send con partes que incluyen un PDF y una instrucción de texto, realiza la transición working → input_required → working → completed, y devuelve un artefacto de texto. Todo con la biblioteca estándar (stdlib); utiliza un transporte en memoria para centrarse en los formatos de los mensajes.

Qué observar:

• Formato JSON de la Agent Card.
• Asignación de ID de tarea y transiciones de estado.
• Mensajes con partes de tipos mixtos.
• Bifurcación de entrada requerida (input-required) a mitad de la tarea.
• Devolución del artefacto al finalizar.

Ship It

Esta lección produce el archivo outputs/skill-a2a-agent-spec.md. Dado un nuevo agente que debería ser llamable por otros agentes, la skill produce el JSON de la Agent Card, el esquema de habilidades y el blueprint del endpoint.

Ejercicios

1. Ejecute code/main.py. Rastree el ciclo de vida completo de la Tarea, incluida la pausa de entrada requerida (input-required) donde el agente llamado solicita una aclaración.

2. Agregue una Agent Card firmada. Firme con HMAC sobre el JSON canónico de la tarjeta. Escriba un verificador y confirme que falla en una tarjeta modificada.

3. Implemente la transmisión de tareas (streaming): el agente redator emite tres chunks de artefactos incrementales sobre SSE y el llamador los acumula.

4. Diseñe un agente A2A que envuelva un servidor MCP. Mapee cada herramienta MCP a una habilidad de A2A. Tenga en cuenta las ventajas y desventajas: ¿qué opacidad se pierde?

5. Lea el anuncio de A2A v1.0 e identifique la característica que aún no ha sido implementada por ningún framework a partir de abril de 2026. (Pista: se relaciona con la delegación de tareas en múltiples saltos o multi-hop).

Key Terms

Further Reading

• a2a-protocol.org — especificación canónica de A2A
• a2aproject/A2A — GitHub — implementaciones de referencia y SDKs
• Linux Foundation — A2A launch press release — transferencia de gobernanza en junio de 2025
• Google Cloud — A2A protocol upgrade — hoja de ruta y partners
• Google Dev — A2A 1.0 milestone — notas de lanzamiento de v1.0 y guía de compatibilidad hacia atrás