A2A x402: la extensión que deja a los agentes cobrarse entre sí

A2A transporta el mensaje. AP2 le da forma. x402 mueve el dinero. La extensión A2A x402 es el pequeño trozo de spec que une los tres — y convierte a cualquier agente en un servicio capaz de cobrarle a otro agente.

Escribimos sobre cada una de estas capas por separado. A2A deja que los agentes se descubran y se deleguen tareas. AP2 define el mandate — la autorización firmada que dice que un usuario (o un agente que delega) aprobó una compra. x402 liquida un pago onchain sobre HTTP plano. Lo que faltaba era siempre la costura: cómo hace un task de A2A en ejecución para detenerse, pedir dinero, tomar una autorización firmada, liquidarla y devolver un recibo — sin romper el modelo de conversación sobre el que A2A está construido.

La respuesta es una extensión formal de A2A. Google la publicó como a2a-x402, co-desarrollada con Coinbase, la Ethereum Foundation y MetaMask, junto al lanzamiento de AP2 en septiembre de 2025. Es pequeña a propósito. No agrega ningún transporte nuevo, ninguna superficie de RPC nueva, ningún esquema de firma nuevo. Agrega una máquina de estados de pago y un puñado de metadata keys que viajan sobre el Task de A2A que ya tienes. Este post lee la spec v0.1.

Dónde encaja: tres protocolos, una costura

Mantén las responsabilidades separadas y el diseño deja de ser confuso:

• A2A es el transporte y la conversación. Mueve objetos Message y Task entre un client agent y un server agent.
• AP2 es la forma de la autorización — el mandate que ata una intención a un pagador, agnóstico a si el rail es una tarjeta o una stablecoin.
• x402 es el primitivo de liquidación: un objeto PaymentRequirements, un PaymentPayload firmado, y un facilitator que corre /verify y /settle contra una cadena.

La extensión es el tejido conectivo. Dice: cuando un task de A2A necesita pago, expresa el PaymentRequirements de x402 dentro de la metadata de A2A, pausa el task, y reanúdalo cuando llegue un PaymentPayload válido. Los mandates de AP2 se propagan, así que el pago cripto liquidado hereda el mismo audit trail que tendría un pago con tarjeta. Esa última parte importa — es la razón por la que esto es una extensión de AP2 y no solo un wrapper de x402.

Encenderla: el Agent Card y el header

Las extensiones en A2A son opt-in y se anuncian. Un merchant agent declara soporte en su Agent Card bajo capabilities.extensions, con clave en un URI que sirve también como identificador de versión:

{
  "capabilities": {
    "extensions": [
      {
        "uri": "https://github.com/google-a2a/a2a-x402/v0.1",
        "description": "Supports payments using the x402 protocol for on-chain settlement.",
        "required": true
      }
    ]
  }
}

Un cliente que quiere usarla activa la extensión por request con un header HTTP:

X-A2A-Extensions: https://github.com/google-a2a/a2a-x402/v0.1

El servidor devuelve el mismo URI en su response header para confirmar que la extensión está activa para ese intercambio. Nada del pago ocurre hasta que ambos lados han reconocido el URI. Ese handshake es toda la superficie de activación — deliberadamente aburrido, porque la parte interesante es la máquina de estados.

La máquina de estados

La extensión define una progresión lineal cargada en un solo campo, x402.payment.status, en la metadata del mensaje de A2A. El happy path son cuatro estados; dos más cubren el fallo:

// happy path
payment-required   // merchant: necesito pago para continuar
payment-submitted  // client: aquí va una autorización firmada
payment-verified   // merchant: la firma y los términos cuadran
payment-completed  // merchant: liquidado onchain, aquí está el recibo

// ramas de fallo
payment-rejected   // merchant rechazó el pago enviado
payment-failed     // la liquidación falló tras un envío válido

La elegancia está en que estos estados se mapean sobre el ciclo de vida del Task de A2A en lugar de inventar uno paralelo. Cuando un merchant necesita dinero, no lanza un error. Mueve el task al propio estado input-required de A2A y adjunta x402.payment.status: "payment-required" más un objeto x402.payment.required. Desde la perspectiva del cliente esto es el mismo patrón que cualquier task que necesita más input — solo que el input resulta ser una firma sobre dinero.

Las estructuras de datos

Cuatro objetos hacen el trabajo. Están tomados directamente de la spec v2 de x402, lo que mantiene honesta a la extensión — un facilitator no necesita aprender A2A para liquidar esto.

El merchant anuncia qué aceptará con x402PaymentRequiredResponse, que es solo una versión y una lista de términos aceptables:

// x402PaymentRequiredResponse
{
  "x402Version": 1,
  "accepts": [ /* PaymentRequirements[] */ ]
}

// PaymentRequirements — una forma aceptable de pagar
{
  "scheme":            "exact",
  "network":           "base",
  "asset":             "0x833589...USDC",
  "payTo":             "0xMerchant...",
  "maxAmountRequired": "1000000",   // 1.00 USDC, 6 decimales
  "resource":          "https://api.merchant/report",
  "description":       "Reporte de riesgo Q3",
  "maxTimeoutSeconds": 120
}

El cliente firma y responde con un PaymentPayload. El campo payload es opaco para A2A — su contenido depende del scheme y la network. Para el scheme exact en una cadena EVM lleva una firma transferWithAuthorization de EIP-3009, el mismo primitivo gasless que desarmamos antes:

// PaymentPayload
{
  "x402Version": 1,
  "network":     "base",
  "scheme":      "exact",
  "payload":     { /* autorización EIP-3009 firmada */ }
}

Tras la liquidación el merchant devuelve un x402SettleResponse — flag de éxito, el hash de la transacción onchain, el pagador, y una razón de error si falló:

// x402SettleResponse
{
  "success":     true,
  "transaction": "0xabc...tx",
  "network":     "base",
  "payer":       "0xClient..."
}

Metadata keys: todo el protocolo sobre el Task

La extensión nunca toca el body de un mensaje de A2A. Todo vive en la metadata, que es por lo que compone limpiamente con cualquier agente A2A. Cinco keys llevan el flujo:

• x402.payment.status — el estado actual (los seis valores de arriba).
• x402.payment.required — el x402PaymentRequiredResponse, puesto por el merchant en el mensaje payment-required.
• x402.payment.payload — el PaymentPayload firmado, puesto por el cliente en el mensaje payment-submitted, correlacionado con el request por el taskId original.
• x402.payment.receipts — un array de cada x402SettleResponse producido durante el task. Es append-only: nunca se reemplaza, siempre crece.
• x402.payment.error — un código corto y legible por máquina en caso de fallo, como insufficient_funds.

La regla de recibos append-only es la historia de auditoría. La spec exige que todos los recibos creados durante la vida de un task aparezcan en el TaskStatus.message final. Un solo task podría involucrar varios pagos — un research agent que le paga a tres proveedores de datos antes de responder — y cada liquidación se preserva, en orden, sobre el objeto que cierra el task. Ese es el audit trail de AP2 expresado en términos de x402: no un log que tienes que reconstruir, sino estado que viaja con el trabajo.

Seguridad: el modelo nunca sostiene la llave

La spec es tajante sobre la regla que importa para agentes autónomos: las llaves privadas nunca deben ser manejadas por el LLM. La firma ocurre en un signing service de confianza, y el modelo solo ve la solicitud de firma y el PaymentPayload resultante. Es la misma separación que argumentamos en el threat model de agentes — la capa de razonamiento propone, un firmante acotado dispone. Un prompt injection que llega al modelo no puede exfiltrar una llave que nunca le fue dada.

El resto de la superficie de seguridad se hereda en lugar de reinventarse. La protección contra replay es obligatoria y viene del nonce tracking; en cadenas EVM el contrato de EIP-3009 impone unicidad de nonce a nivel del token, así que una autorización capturada no puede liquidarse dos veces. Las autorizaciones llevan ventanas de tiempo explícitas vía maxTimeoutSeconds. Y como el merchant corre la verificación antes de la liquidación, un payload malformado o sin fondos se rechaza en payment-rejected sin llegar a tocar la cadena.

Functional core, imperative shell

La implementación de referencia — Python, como x402_a2a — se divide en dos capas que la spec llama functional core e imperative shell. El core protocol es puro: funciones que construyen PaymentRequirements, verifican una firma y arman una settle response, sin I/O. Los executors son middleware que envuelven un agente A2A existente y manejan la máquina de estados automáticamente — interceptan el task saliente, inyectan payment-required, esperan payment-submitted, llaman al facilitator, agregan el recibo. Puedes adoptar el executor para una integración hands-off, o llamar las funciones del core directamente si necesitas lógica de pago a medida. Es una forma limpia, y vale la pena copiarla sin importar el rail de pago.

Qué significa para LLM4Agents

LLM4Agents ya habla x402 en el gateway: un agente paga por llamada de inferencia en stablecoins sin factura, sin tarjeta, sin cuenta. La extensión A2A x402 extiende ese mismo modelo económico hacia afuera — del agente que nos paga a nosotros, al agente que le paga a otros agentes a los que delega. Esa es la mitad que falta de una economía de agentes real. Un agente que gana respondiendo preguntas debería también poder gastar, a mitad de task, en los datos y el cómputo que necesita, sobre el mismo rail exacto.

En concreto, la extensión encaja naturalmente encima de nuestro stack. La regla del signing service se mapea con cómo ya pensamos las wallets de agentes y la autoridad delegada — el modelo razona, un firmante acotado liquida. Los recibos append-only se mapean con los internals de facturación que describimos en reserve, proxy, settle: cada liquidación es un registro durable, no un log reconstruido. Y como la extensión reusa los tipos v2 de x402 tal cual, un agente que le paga a un endpoint de LLM4Agents y un agente que le paga a un par sobre A2A firman la misma forma de autorización. Una wallet, un primitivo de liquidación, dos direcciones de pago.

La amenaza es el espejo de la oportunidad. Si A2A x402 se vuelve la forma por defecto en que los agentes se cobran entre sí, un gateway que solo acepta pago pero no puede ayudar a un agente a hacer pagos salientes es medio plataforma. El grafo económico es bidireccional; la infraestructura tiene que serlo también.

Cómo mantenerse en la frontera

Pasos concretos, en orden.

Primero, soportar la extensión como merchant. Cualquier endpoint hospedado en LLM4Agents que otro agente pueda llamar debería poder anunciar x402.payment.required y liquidar una autorización payment-submitted. Los tipos v2 ya coinciden con lo que aceptamos en el gateway, así que esto es cableado, no rediseño.

Segundo, lanzar un signer saliente. Darle a los agentes un signing service acotado que pueda producir un PaymentPayload para el PaymentRequirements de un par sin exponer nunca la llave al modelo. Esta es la pieza que le permite a un agente gastar, no solo ganar, y reusa el trabajo de wallet e identidad ya en marcha.

Tercero, hacer los recibos first-class. Persistir el array append-only x402.payment.receipts como parte del historial de facturación de un agente, para que un agente que delega pueda probar qué pagó aguas abajo. Combinado con el contexto del mandate de AP2, eso es un audit trail completo y portable a lo largo de toda la cadena de delegación.

Cuarto, seguir el directorio de schemes. v0.1 trae exact; la spec deja lugar para upto y schemes diferidos redactados por partners. El pricing por token y por segundo es exactamente el modelo medido que quiere la inferencia. Cuando un scheme medido se estabilice, un gateway OpenAI-compatible que ya cobra por token es el lugar más natural para liquidarlo.

Las capas dejaron de ser protocolos separados en el momento en que esta extensión salió. A2A descubre, AP2 autoriza, x402 liquida — y la costura entre ellos ahora está escrita. Las plataformas que internalicen la costura completa, en ambas direcciones, son las que los agentes usarán para transaccionar de verdad.