AWS AgentCore pagos x402 pasó a GA: los agentes ya pueden medir lo que compran, y lo que falta es oferta

Qué lanzó AWS el 18 de agosto de 2026

AgentCore payments estaba en preview desde principios de año, construido junto a Coinbase y Stripe. El 18 de agosto pasó a disponibilidad general. Conviene leer el anuncio de AWS como un documento sobre diseño de pagos, no como una nota de release. El encuadre es que un agente debería poder «descubrir, acceder y pagar APIs, MCPs y contenido» de forma autónoma: descubrimiento, acceso y pago tratados como un solo problema.

La mecánica es la que venimos describiendo hace un año. El agente golpea un recurso pago, recibe un 402 HTTP, y AgentCore resuelve la negociación del protocolo, la autenticación de la wallet, el pago en stablecoin y la entrega del comprobante al endpoint — sin interrumpir el ciclo de razonamiento del agente. Si querés el handshake en detalle, lo desarmamos en cómo funciona una llamada x402 de punta a punta.

Lo interesante es qué cambió entre el preview y el GA:

Todas las filas empujan hacia el mismo lado: volver aburrido que una máquina gaste plata. Eso significa «disponibilidad general» en un hyperscaler — no que la función sea nueva, sino que ya es un default que un equipo de plataforma puede adoptar sin tratarlo como caso especial.

El esquema upto es el cambio que más le importa al que vende

Hasta ahora x402 respondía sobre todo una pregunta fija: esta llamada cuesta tres centavos, pagala. Funciona perfecto para endpoints deterministas — una geocodificación, una consulta, una validación. No funciona para la categoría más grande de cosas que los agentes realmente compran, porque nadie sabe el precio antes de hacer el trabajo. Una completion cuesta lo que terminen siendo los tokens. Una query cuesta lo que termine escaneando. Una descarga cuesta lo que terminen siendo los bytes.

El esquema upto de la especificación de la x402 Foundation lo resuelve con un movimiento elegante: el campo amount significa cosas distintas en fases distintas. Al verificar es el máximo que el cliente autoriza. Al liquidar es el monto real a liquidar, que debe ser menor o igual a ese máximo. El vendedor hace el trabajo, lo mide, y liquida la cifra verdadera.

Los resguardos de la especificación son la razón por la que esto se le puede dar a un proceso autónomo: cada autorización se liquida como máximo una vez y no se puede reutilizar; está acotada en el tiempo con marcas explícitas validAfter y deadline; y la dirección del destinatario queda ligada criptográficamente, así que una autorización no puede redirigirse a otra wallet. Los casos de uso que nombra son los esperables: generación de tokens de un LLM, transferencia de datos por byte, cómputo con precio dinámico.

Leído en clave comercial y no técnica, esto destraba un modelo de negocio. Un protocolo de precio fijo obliga a cada vendedor a cotizar el peor caso o a comerse la cola. Un protocolo medido le permite cobrar como el software siempre quiso cobrar, y al comprador comprometer un presupuesto sin comprometer una cantidad. Es la primera vez que los pagos de máquina tienen el vocabulario de precios que un contrato SaaS humano da por sentado.

Dos protocolos, una wallet — y qué dice eso sobre el riesgo de estándar

El segundo cambio del GA es más silencioso y fácil de subestimar. AgentCore ahora soporta MPP junto a x402, y el encuadre de AWS es que un desarrollador puede pagar cualquier servicio compatible con MPP «sin una línea de código adicional».

La lectura instintiva es fragmentación: un segundo estándar significa guerra de estándares. Para quien vende, creemos que es más bien lo contrario. La elección de protocolo quedó abstraída en la capa de wallet del comprador. El ingeniero de un agente ya no elige un estándar de pago cuando elige un proveedor: el runtime negocia lo que hable el endpoint.

Eso le saca casi todo el riesgo a la decisión que viene paralizando a los proveedores de API todo el año: ¿qué protocolo implemento y qué pasa si elijo mal? Si el lado comprador es plural, publicar un precio x402 deja de ser una apuesta. Es una puerta. Además x402 está bajo gobernanza abierta y neutral de la x402 Foundation en la Linux Foundation, algo que cubrimos cuando la fundación se formalizó: no estás adoptando el protocolo de un vendor, y no estás obligado a adoptar uno solo.

Los topes de gasto bajaron por debajo del modelo

El tercer cambio es el que debería tranquilizar a cualquier área de finanzas nerviosa con los presupuestos de agentes. Los pagos de AgentCore corren dentro de una sesión de pago: un contexto acotado a una sola interacción del agente, con dos límites configurables — un monto máximo de gasto en una moneda determinada, y un vencimiento. AWS es explícito sobre el porqué: los agentes no son deterministas, así que pueden interpretar una respuesta como autorización para gastar, o repetir un pago ante un reintento inesperado.

La solución es dejar de pedirle al modelo que sea prudente. Las solicitudes se validan contra el presupuesto de la sesión en la capa de infraestructura, de forma determinista, antes de autorizar cualquier pago, con observabilidad de punta a punta sobre lo gastado.

Es el mismo argumento estructural que planteamos en la brecha de confianza del comercio agéntico, llegando desde el otro lado. El checkout agéntico de consumo necesita un marco de confianza elaborado porque los rails de tarjeta son credenciales reversibles: alguien tiene que probar, meses después, que una persona autorizó el pago. El gasto máquina-a-máquina sobre un rail de stablecoins lo reemplaza por dos cosas que una computadora puede hacer cumplir: un techo que no se puede superar, y una liquidación que es su propio comprobante. AWS acaba de entregar el techo como infraestructura.

La señal está en la capa de descubrimiento

Enterrada en el mismo anuncio está la frase que reencuadra todo lo anterior. AgentCore expone endpoints x402 de pago por uso como servidor MCP vía AgentCore Gateway — y en el GA esa experiencia de descubrimiento pasó a ser una lista curada, seleccionada por «prueba social, riqueza de metadatos, calidad de la descripción y disponibilidad».

Nadie cura un mercado abundante. Se cura cuando el inventario es escaso y desparejo, y hay que proteger la primera experiencia del comprador. Que un hyperscaler elija a mano qué endpoints pagos vale la pena mostrarle a millones de agentes no es señal de que el lado oferta esté saturado. Es señal de que no lo está.

Los números públicos dicen lo mismo. A fines de agosto de 2026, el panel de x402.org reportaba, para los últimos 30 días:

• 75,41 M de transacciones
• 24,24 M USD de volumen
• 94,06 mil compradores
• 22 mil vendedores

De ahí salen dos cuentas. Primero: el ticket promedio ronda los 32 centavos, un precio que directamente no existe en rails de tarjeta, donde el costo fijo por autorización se come la venta. (Otros trackers, con metodologías distintas y ventanas más cortas, reportan promedios menores; cubrimos una de esas semanas en la semana récord de x402. Tomá cualquier número como una medición, no como una ley.)

Segundo, y más útil: los compradores superan a los vendedores más de cuatro a uno, y ese ratio se midió antes de que un hyperscaler convirtiera las wallets de agente en un default de disponibilidad general. Todos los anuncios de 2026 fueron del lado comprador: nubes que emiten wallets, plataformas de gestión de gasto que emiten wallets, proveedores de modelos que documentan cómo paga un agente. Cada uno suma máquinas fondeadas buscando qué comprar. Ninguno suma un endpoint que conteste con un precio.

Para un agente con presupuesto y a mitad de una tarea, un formulario de registro es un callejón sin salida. No va a crear una cuenta, ni esperar una API key, ni leer tu página de precios. Se va a otro lado, o vuelve con su usuario sin el dato.

Qué significa esto si vendés una API — y qué hace exactamente Payzum

Acá la precisión importa, porque los roles en x402 se confunden todo el tiempo. Payzum es el middleware/proxy que se para delante de tu API existente. Payzum no es el facilitator. La liquidación on-chain la maneja un facilitator externo — hoy el de Coinbase. Lo que Payzum saca de tu roadmap es la ingeniería: implementar el handshake 402, verificar el pago, protegerse de replay y reenviar la llamada pagada a tu servicio real con tus propias credenciales.

Vos configurás el endpoint que ya corrés, la API key o bearer token que ya espera, y un precio por llamada. Payzum publica una URL x402, le responde al agente con el 402 y las condiciones de pago, espera la liquidación y hace de proxy hacia tu endpoint real, devolviendo la respuesta dentro del mismo ciclo de request. Sin SDK, sin implementar protocolo, sin redeploy de tu servicio.

Siendo francos sobre el modelo de precio: lo que configurás hoy es un precio por llamada — la forma de precio fijo. El esquema medido upto descrito arriba es una capacidad a nivel protocolo que el ecosistema está desplegando, y para la mayoría de los proveedores un precio plano por llamada es igual el producto correcto para empezar: es lo más fácil de evaluar para un agente contra su presupuesto restante, y lo más fácil de razonar para vos. Si tu unidad real es por token o por byte, eso es una buena conversación para una llamada, no una afirmación para un post.

La liquidación es no-custodial: USDC en Base cae directo en una wallet que vos controlás, con confirmaciones de unos dos segundos. Payzum nunca retiene, agrupa ni enruta tu dinero — la liquidación es el pago. Eso también implica que el pago es final cuando servís la llamada: sin contracargos, sin ventana de reversa, sin plata parada uno a tres días en el balance de un procesador. El precio es por uso: alrededor de 1.000 transacciones por mes gratis, luego ~$0,001 por transacción más gas. Si querés la mecánica de liquidación en profundidad, la escribimos en por qué USDC en Base encaja con el precio por request.

Cómo funciona, paso a paso

1. Conectá el endpoint que ya tenés. En el panel de Payzum pegás la URL de tu API y la key o bearer token que espera. Tu servicio conserva su autenticación, sus rate limits y su pipeline de deploy — de tu lado no cambia nada.
2. Definí precio y wallet de destino. Elegís cuánto cuesta una llamada en USDC y la wallet de Base donde deben caer los fondos. Como la liquidación es no-custodial, esa wallet es tuya desde el primer pago: no hay un saldo Payzum en el medio.
3. Payzum publica la URL x402. El agente que la golpea recibe un 402 HTTP con el precio y las condiciones — una oferta legible por máquina que puede evaluar contra el presupuesto de su sesión, sin humano en el medio — y paga en USDC. La liquidación se verifica a través de un facilitator externo.
4. La llamada pagada llega a vos por proxy. Payzum reenvía el request a tu endpoint real con tu key y devuelve la respuesta en el mismo ciclo. Webhooks firmados, audit log completo, 2FA y secretos encriptados cubren cada llamada, y podés ver caer la primera desde el integration playground y la API REST.

Quién está del otro lado hoy

El propio post de GA de AWS nombra un cliente que vuelve concreta la forma: Travala integró pagos en sus servidores MCP, con 2,2 millones de propiedades a nivel global. Un agente que reserva viajes no completa un formulario: encuentra una herramienta, obtiene un precio y paga. Tres formas más, todas B2B y todas alcanzables esta semana:

• Un proveedor de datos con una cola larga que no puede vender. Licencia su feed a empresas y rechaza a todo el que no llega al mínimo de contrato. Publica la misma consulta a tres centavos por llamada vía x402. Agentes de research, bots de pricing y scripts sueltos pagan por query. Nadie negocia, nadie firma, y el segmento que era antieconómico de facturar pasa a ser el que paga al instante.
• Una herramienta MCP que el agente descubre a mitad de tarea. Un servicio de geocodificación, enriquecimiento o parseo de documentos expuesto a runtimes de agentes. Cuando un agente lo necesita, se encuentra un precio en vez de una pantalla de registro, paga del presupuesto de su sesión y obtiene la respuesta en el mismo ciclo. Es exactamente el inventario que le falta a una lista curada — y escribimos el recorrido completo en cómo monetizar un servidor MCP con x402.
• Un proveedor de API en LATAM sin cuenta de cobro internacional. Un equipo en Buenos Aires, Bogotá o Ciudad de México factura en dólares pero no puede abrir con facilidad una cuenta de comercio en EE. UU., y arrastra la fricción de siempre: intermediarios que descuentan, giros que tardan y llegan cortos, y controles cambiarios que convierten un cobro chico en un trámite. Los agentes, estén donde estén, pagan USDC en Base directo a la wallet del equipo — sin adquirente, sin comisiones de tarjeta cross-border, sin reserva rodante y sin un payout que congelar, porque no hay saldo retenido en ningún lado.

Vender a agentes por rails de tarjeta vs una URL x402 con Payzum

Objeciones que vale la pena tomar en serio

«Si además existe MPP, ¿publicar un precio x402 no es apostar al estándar equivocado?»

Era una preocupación razonable hace un año y hoy es mucho más débil, justamente por lo que cambió el GA. El runtime del comprador resuelve la negociación de protocolo: la posición declarada de AWS es que un servicio compatible con MPP se paga «sin una línea de código adicional» del lado del agente, en paralelo a x402. La exposición del vendedor también es chica: con Payzum la URL x402 es una configuración delante de un endpoint que ya corrés, no una reescritura de tu servicio. Si el panorama se mueve, lo que cambiás es un ajuste, no una arquitectura.

«Ya tenemos API keys, planes y facturación. ¿Para qué otra puerta?»

Quedátelas todas. x402 es aditivo, no una migración: tus clientes actuales conservan sus keys, contratos y facturas intactos. Lo que suma una URL x402 es una segunda puerta para un comprador que no puede entrar por la primera: un proceso autónomo, a mitad de tarea, con presupuesto de sesión y sin capacidad de completar un alta, cargar una tarjeta o esperar a compras. Hoy ese comprador ve una pantalla de login y se va. El cambio no es en tu modelo de facturación; es en tu mercado direccionable. Los comparamos lado a lado en x402 vs facturación con API key.

«¿No es riesgoso que la liquidación sea final si algo sale mal en una llamada?»

La finalidad corta para los dos lados y conviene decirlo derecho. No podés revertir un pago, y el comprador tampoco — por eso el precio por llamada le calza a este rail: la unidad en riesgo de cada lado son centavos, no un contrato mensual. Si necesitás dejar bien a un comprador, devolvés como un pago que iniciás vos, en tus términos. Lo que la finalidad elimina es esa ventana de reversa de meses que hace que un procesador convencional retenga reservas contra tu facturación.

«¿Tengo que estar en AWS para algo de esto?»

No. AgentCore es un runtime comprador entre varios, y lo significativo de su GA es lo que dice sobre la demanda, no sobre dónde tenés que hospedarte. x402 es un estándar HTTP abierto bajo gobernanza de la Linux Foundation; un endpoint publicado con Payzum le responde a cualquier cliente que lo hable, sea cual sea la nube, el framework o el runtime de agentes que esté corriendo.