Building Agentic Commerce #6: Protocolo A2A — Cuando los Agentes Hablan Entre Si

MCP permite a los agentes llamar herramientas en tu tienda. ACP gestiona flujos de consentimiento. x402 liquida pagos en stablecoins. Pero que pasa cuando un agente en nombre de un comprador necesita mantener una conversacion de multiples turnos con un agente merchant — negociando, haciendo preguntas, rastreando pedidos? Ahi es donde entra A2A (Agent-to-Agent). El protocolo A2A de Google da a los agentes una forma estandarizada de enviar mensajes, crear tasks con estado, transmitir actualizaciones en tiempo real y recibir push notifications — todo sobre JSON-RPC 2.0. Este post cubre la implementacion completa de A2A en AgenticMCPStores: 12 endpoints, 8 estados de task, modos de entrega dual (sync + SSE), e integracion de pagos con x402 y procesadores fiat.

MCP esta orientado a herramientas: un agente llama a search_products, obtiene un resultado, listo. Cada llamada es stateless. A2A esta orientado a conversaciones: un agente envia un mensaje, el agente merchant responde, y el intercambio puede abarcar multiples turnos con contexto completo preservado. MCP mapea a request-response HTTP. A2A mapea a un protocolo de mensajeria con tasks que rastrean estado en el tiempo. En la practica, necesitas ambos: MCP para llamadas estructuradas a herramientas (busqueda, carrito, checkout) y A2A para interacciones abiertas (negociacion, seguimiento de pedidos, consultas complejas que requieren ida y vuelta).

Antes de enviar mensajes, los agentes descubren lo que un merchant puede hacer via el agent card. GET /.well-known/agent-card.json devuelve la card publica (cacheada 1 hora) con: nombre, descripcion, protocolos soportados, capacidades de mensajeria y skills disponibles. GET /.well-known/a2a/agent-card/extended devuelve la card autenticada (requiere header X-Agent-Api-Key) con capacidades adicionales basadas en el tier y scopes del agente.

Los mensajes A2A usan JSON-RPC 2.0 con el metodo a2a.SendMessage. Cada mensaje contiene parts — un array de bloques de contenido tipado: partes de texto (texto plano o markdown), partes de datos (JSON estructurado — datos de producto, metadata de pago), y partes de archivo (referencias URI con tipo de media). Los mensajes tambien llevan un rol (user o agent), contextId opcional para conversaciones multi-turno, taskId opcional para continuar un task existente, y metadata para datos de extension. Esta estructura multi-parte permite a los agentes mezclar lenguaje natural con datos estructurados en un solo mensaje — algo que las llamadas a herramientas MCP no pueden hacer.

Cuando un agente autenticado envia un mensaje, A2A crea un task con estado. El task se mueve a traves de 8 estados: UNKNOWN (creado, aun no procesado), WORKING (en progreso), INPUT_REQUIRED (esperando input del usuario — ej: confirmacion de pago), AUTH_REQUIRED (esperando autenticacion), COMPLETED (terminado exitosamente), FAILED (error), CANCELED (cancelado por el agente), REJECTED (fallo de validacion). Las transiciones validas se aplican server-side via maquina de estados. Los estados terminales son COMPLETED, FAILED y CANCELED. Los estados cancelables son WORKING, INPUT_REQUIRED y AUTH_REQUIRED. Cada tipo de task tiene un TTL: tasks de SEARCH y COMPARE expiran en 5 minutos, tasks de PURCHASE y TRACK en 30 minutos.

A2A soporta dos modos de entrega. Sincrono: POST /a2a/messages envia un mensaje y espera la respuesta completa. Bueno para consultas simples. Streaming: POST /a2a/messages/stream envia un mensaje y devuelve un stream SSE. El servidor emite multiples eventos conforme el task progresa — eventos de mensaje, eventos de actualizacion de task, y eventos de error. El stream se cierra cuando el task alcanza un estado terminal. Suscripcion a task: GET /a2a/tasks/{taskId}/subscribe abre un stream SSE persistente que emite eventos task_update cuando el estado cambia. Maximo 50 suscriptores concurrentes por task para prevenir ataques de amplificacion.

Para agentes que prefieren webhooks sobre polling SSE, A2A soporta configs de push notification. Registra un webhook via POST /a2a/tasks/{taskId}/pushNotificationConfigs con webhookUrl, info de auth (bearer token o header personalizado), y tipos de evento (status_update, artifact_update). La info de auth se almacena encriptada y nunca se devuelve en respuestas de API. Cuando el estado de un task cambia o se anade un artifact, la plataforma dispara un webhook asincrono a la URL registrada.

A2A eleva los pagos del nivel de herramienta (MCP complete_checkout) al nivel de mensaje. Cuando el router de mensajes clasifica un intent de PURCHASE, el handler de pagos se activa. Para x402 (USDC on-chain): el handler detecta intent de compra, crea un requerimiento de pago x402 (soporta Base, Polygon, Ethereum, Solana, Arbitrum), devuelve el task en estado INPUT_REQUIRED con metadata de pago, el cliente envia el payload de pago x402, el servidor verifica la firma EIP-712 y liquida on-chain. Para KYApay (fiat): flujo similar con procesador de pagos fiat. La metadata de pago se rastrea via claves de metadata del task: x402.payment.status, x402.payment.required, x402.payment.receipt.

Las conversaciones multi-turno necesitan proteccion de concurrencia. A2A usa advisory locks de PostgreSQL en context IDs (pg_try_advisory_xact_lock con hashtext). Si dos agentes intentan escribir al mismo contexto simultaneamente, el segundo obtiene un error 409 CONTEXT_CONFLICT. Esto previene condiciones de carrera en flujos de checkout. Asociacion de carrito: cuando un task crea un carrito, TaskManagerService.linkCart(taskId, cartId) los vincula. Si el task se cancela, el carrito vinculado se expira automaticamente.

MCP: usar para llamadas estructuradas a herramientas — search_products, create_cart, complete_checkout. Stateless, una peticion una respuesta. Mejor para agentes que saben exactamente lo que quieren. ACP: usar para flujos de checkout basados en consentimiento. El agente presenta su intencion, el merchant confirma, el pago se ejecuta con consentimiento explicito en cada paso. A2A: usar para conversaciones abiertas — preguntas de producto, negociacion, seguimiento de pedidos. Stateful, multi-turno, streaming. En AgenticMCPStores, los tres trabajan juntos: un agente puede descubrir una tienda via MCP, hacer preguntas via A2A, y completar checkout via ACP. La plataforma auto-detecta que protocolo usa cada peticion.

A2A esta disponible en tier Growth y superiores. Configuracion clave: 12 endpoints registrados en server.ts, rate limiting por agent key (basado en tier), header X-Initiated-By en todas las respuestas (cumplimiento EU AI Act), logging estructurado con pino. Codigos de error siguen la especificacion A2A: INVALID_REQUEST (400), CONTEXT_CONFLICT (409), UNSUPPORTED_OPERATION (403), TASK_NOT_FOUND (404). La implementacion tiene 128 tests cubriendo descubrimiento, mensajeria, ciclo de vida de tasks, streaming, push notifications e integracion de pagos.