x402, y por qué le importa a un agente

HTTP reservó el código 402 —“Payment Required”— en 1997 y lo dejó sin definir durante veinticinco años. x402 es la especificación que finalmente lo usa: un servidor responde 402 con cuánto cuesta el recurso, en qué red y con qué activo se paga, y qué entrada acepta; el cliente firma una autorización de pago y repite la llamada con esa autorización adentro.

La parte importante no es el cobro, es de dónde sale la información. El precio y el esquema viajan en la respuesta, así que un cliente que nunca vio ese servidor puede decidir si le sirve sin haber leído documentación escrita para humanos y sin que nadie le haya dado credenciales.

Un agente sabe llamar una API. Lo que no sabe hacer es darse de alta: completar un formulario, confirmar un correo, entrar a una consola y generar una clave. Ese trámite está diseñado para una persona con tarjeta y paciencia, y es el motivo real por el que un agente no puede incorporar una fuente de datos nueva en mitad de una tarea.

x402 saca a la persona del camino. No porque el pago sea más barato, sino porque el alta desaparece: no hay cuenta que crear ni secreto que guardar. El agente descubre, decide, paga y sigue, en el mismo bucle en el que estaba trabajando.

De ahí sale la consecuencia interesante: un servicio deja de tener que convencer a un desarrollador de integrarlo. Le alcanza con ser encontrable y con describirse bien.

Son dos viajes. En el primero el cliente pide sin credenciales y el servidor contesta 402 con el desafío. En el segundo el cliente repite la llamada con la autorización firmada, y el servidor verifica, liquida y responde con el resultado y el recibo.

El desafío viaja en la cabecera PAYMENT-REQUIRED, codificado en base64, que es donde lo busca un cliente estándar. El cuerpo va vacío a propósito: duplicarlo ahí serían los mismos kilobytes mandados dos veces en la respuesta más frecuente que da el servicio.

Precio por llamada y no por plan. Un servicio puede cobrar por el tamaño real de lo que procesó en vez de estimarlo en escalones mensuales, y quien lo usa una vez paga una vez.

Composición entre agentes. Si pagar es una llamada HTTP más, un agente puede subcontratar parte de su trabajo a otro agente sin que ninguno de los dos tenga cuenta en el otro.

Descubrimiento sin catálogo central. El manifiesto lo publica cada servicio en su propio dominio, así que no hace falta un mercado que apruebe altas, ni que se quede con una comisión por estar en el medio.

Fallar barato. Como no hay alta, probar un servicio nuevo cuesta lo que cuesta una llamada. Descartarlo no deja atrás una cuenta abierta ni una credencial dando vueltas.

Conviene decirlo porque el entusiasmo alrededor del estándar suele omitirlo. x402 no dice nada sobre la calidad de lo que compraste: pagar verifica que hubo un pago, no que la respuesta sea correcta. La reputación de un servicio sigue siendo un problema abierto.

Tampoco resuelve el reembolso. Si el servicio responde algo inservible, la liquidación ya ocurrió. Por eso los servicios seriamente diseñados no liquidan cuando el resultado falla, pero eso es una decisión de cada implementación y no una garantía del estándar.

Y sigue habiendo una cadena y un activo abajo, con su latencia y su costo de liquidación. Para importes muy chicos eso importa, y es la razón por la que estos servicios liquidan en una red de bajo costo.

En la práctica no se implementa el protocolo a mano: un cliente que hable x402 intercepta el 402, firma y reintenta, y el código de arriba llama al endpoint una sola vez. El pago queda abajo del todo, como queda TLS.

Lo que sí conviene hacer a mano es el descubrimiento. Leer el manifiesto una vez y generar de ahí las definiciones de herramientas del agente es lo que convierte a un catálogo en capacidades, y es la parte donde el esquema de entrada publicado deja de ser documentación y pasa a ser código.