Semana agentic: la capa de pagos estrena freno

Cinco cambios llegaron esta semana a la capa de pagos de agentes. Cuatro son limites. La capa dejo de optimizar como pagar y empezo a optimizar como no gastar de mas.

La semana del 14 al 21 de agosto no produjo ningun protocolo de pago nuevo, ninguna cadena nueva, ningun scheme nuevo. Produjo un tope de gasto por defecto en los SDKs cliente de x402, un estado de settlement no terminal, un limite de pago en la capa de infraestructura en un lanzamiento GA de AWS y una propuesta de regla contable para el activo que todo esto mueve.

Es un cambio de fase reconocible. Un rail de pagos agrega capacidades mientras se adopta y agrega restricciones cuando se opera. Esta semana fue casi enteramente del segundo tipo.

1. Los clientes x402 ahora se niegan a firmar mas de un dolar

El cambio mas grande de la semana es un valor por defecto. El PR #3124, mergeado el 13 de agosto, agrego spendControls declarativos al x402Client de TypeScript. El port a Python y el port a Go se mergearon el 18 de agosto, con once minutos de diferencia. Entre los tres tocaron 321 archivos.

El comportamiento merece leerse dos veces. Un cliente construido con fromConfig aplica ahora un tope por defecto de un dolar sobre los activos peggeados que reconoce, y lo aplica dentro de la seleccion del accept: antes de que corra cualquier politica del usuario y antes de firmar nada. Los activos que no son default directamente no son pagables salvo que los listes. No hay forma de heredar por accidente una configuracion permisiva, porque la configuracion permisiva hay que escribirla.

const client = x402Client.fromConfig({
  schemes: [{ network: "eip155:*", client: new ExactEvmScheme(signer) }],
  spendControls: {
    maxAmountPerPayment: "$1",        // tope USD sobre activos peggeados reconocidos
    allowedAssets: [
      // activo no-default opt-in, con tope en unidades atomicas
      { network: "eip155:*", asset: "0xCustomToken", maxAmountPerPayment: "2000000" },
      // override del tope USD para un activo default, por ticker
      { network: "eip155:*", asset: "USDC", maxAmountPerPayment: "1000000" },
    ],
  },
  // spendControls: false  -> cualquier activo, sin topes
});

Dos decisiones de diseno lo vuelven mas que un wrapper de conveniencia. Primero, los topes se expresan en USD (para activos que el SDK reconoce como peggeados) o en unidades atomicas por activo, lo que significa que el cliente no necesita confiar en un price feed para imponer un limite sobre un token que no reconoce. Segundo, cada paquete de mecanismo declara ahora su propia tabla DEFAULT_ASSETS, asi que "reconocido" es una propiedad del build del SDK y no del discovery en runtime.

Las releases que lo llevan son @x402/core 2.23.0 en npm y x402 2.20.0 en PyPI, ambas publicadas el 18 de agosto. Para dimensionar cuanta superficie cubre ahora ese default: solo @x402/core registro 871.818 descargas en npm en los treinta dias hasta el 19 de agosto.

2. settlement_pending: el estado entre pagado y fallido

El 17 de agosto, el PR #3083 agrego una constante EVM compartida entre los flujos exact, upto y batch-settlement:

// ErrSettlementPending: el broadcast funciono; la espera del receipt fallo
// (RPC/timeout). No terminal - devolver con el tx hash para que quien llama
// reconcilie onchain antes de reintentar.
ErrSettlementPending = "settlement_pending"

La falla que resuelve es mundana y cara. Un facilitator hace broadcast de una transaccion, recibe un hash valido y despues no logra recuperar el receipt porque un endpoint RPC dio timeout o error. Antes de este cambio, esa falla salia como un error terminal del tipo invalid_exact_evm_failed_to_get_receipt. Quien lee un error terminal hace lo razonable: reintentar. Si la transaccion original confirmo, el comprador pago dos veces.

La regla que fija el PR es deliberadamente conservadora: tratar toda excepcion de espera de receipt posterior a un hash de broadcast valido como settlement_pending, porque el tipo de excepcion no puede probar que la transaccion no vaya a confirmar. Los strings de error viejos se conservaron y quedaron anotados como valores de wire reservados que no deben reasignarse, que es el manejo correcto en un protocolo donde facilitators y clientes de distintas generaciones de SDK se hablan entre si.

Es el tipo de cambio que solo aparece cuando algo corre en produccion. El API del facilitator se especifico como verify y settle, exito o fracaso. El settlement real tiene un tercer resultado — broadcasteado, desconocido — y ahora tiene nombre.

3. AgentCore payments GA: dos protocolos detras de una integracion

AWS puso AgentCore payments en disponibilidad general el 18 de agosto, despues de un preview que arranco con soporte x402. El alcance del GA es mas amplio que el del preview en un punto concreto: ahora es agnostico de protocolo en la superficie del API, soportando tanto x402 como el Machine Payments Protocol co-escrito por Stripe y Tempo. El desarrollador integra una vez; AgentCore negocia el protocolo que hable el merchant.

La feature de x402 que AWS eligio destacar en el GA es el scheme upto — autorizar un techo y liquidar el consumo real — que presenta como el habilitador del pay-per-inference y del pricing dinamico. Es un respaldo notable. De los cuatro schemes de x402, upto es el construido exactamente para la forma de una llamada de inferencia, donde el precio se desconoce hasta contar los tokens.

El resto del GA sigue el tema de la semana. Los limites de pago se aplican en la capa de infraestructura y no en el codigo del agente, las sesiones llevan topes de gasto y expiracion, y la credencial del wallet queda estructuralmente separada del agente para que este pueda iniciar pagos autorizados sin acceso irrestricto al wallet. Tambien hay un MCP server curado del Coinbase Bazaar con endpoints x402 de pago por uso expuesto a traves de AgentCore Gateway, y Quick Create para provisionar credenciales de Coinbase desde la consola.

4. MCP: un SDK de Rust en Tier 1 y siete canales colapsados en uno

MCP tuvo una semana de governance mas que de protocolo. El 21 de agosto el SDK de Rust fue promovido de Tier 2 a Tier 1 tanto para la revision 2026-07-28 como para el draft. La promocion es notable por como se justifico: re-verificacion independiente con la suite oficial de conformance contra los sets de requisitos congelados 2025-11-25 y 2026-07-28, con 67/67 en conformance de servidor, 50/50 en conformance de cliente y 12/12 en labels, mas documentos publicados de versionado, politica de dependencias y roadmap, y seguimiento de la spec el mismo dia. El tier es ahora un reclamo con evidencia, no de popularidad.

El crate de fondo no es un proyecto lateral. rmcp supero los 21,3 millones de descargas historicas en crates.io, con la 3.1.4 publicada el 20 de agosto.

El dia anterior, el Authorization Interest Group fue re-chartereado en un solo lugar. Seis canales de Discord #auth-wg-* mas #enterprise-managed-auth-ig quedaron archivados, y cada tema vivo — DPoP, workload identity federation, SEP-2643 y autorizacion fine-grained, tool scopes, e interop de enterprise-managed authorization — continua como un thread en un unico canal. El charter dice ahora que la salida del grupo son drafts y demos, que aceptar SEPs sigue el camino normal de sponsor mas core maintainer, y que una agenda floja cancela la reunion.

Consolidar despues de que sale una especificacion es senal sana. La reescritura 2026-07-28 genero muchos foros paralelos de autorizacion; un mes despues de la spec final, el proyecto elige una sala en lugar de siete.

5. La FASB propone una regla para tener el dinero

El 18 de agosto el Financial Accounting Standards Board publico una propuesta de Accounting Standards Update titulada Statement of Cash Flows (Topic 230): Cash Equivalents — Disclosure Enhancement and Evaluation of Certain Digital Assets. No cambia la definicion de cash equivalent. Agrega ejemplos ilustrativos que aclaran cuando un activo digital ya la cumple.

Se exigen tres caracteristicas: un derecho contractual de redencion en efectivo a demanda, un derecho de redencion directa con el emisor por montos conocidos de efectivo, y reservas segregadas que el emisor mantiene al menos uno a uno en activos de corto plazo y alta liquidez. Las entidades que presenten cash equivalents tendrian ademas que revelar anualmente sus componentes significativos — letras del Tesoro, papel comercial, money market funds, stablecoins — sean o no digitales. Los comentarios cierran el 19 de noviembre de 2026.

Para un operador que corre agentes con un balance de trabajo, esto es la diferencia entre un float en stablecoin sentado en una linea contable que nadie quiere explicar y uno sentado al lado de las letras del Tesoro. Es una historia de tesoreria, no de protocolo, pero elimina una objecion real a fondear un agente autonomo desde el balance de una empresa.

Tambien esta semana

El README de los contratos ERC-8004 sumo una seccion de Robinhood Chain mainnet el 15 de agosto, con las mismas direcciones vanity canonicas que se usan en todas partes: 0x8004A169… para identidad, 0x8004BAa1… para reputacion. El proxy de identidad resuelve a la misma implementacion IdentityRegistryUpgradeable que encontramos en Ethereum durante nuestra auditoria on-chain, fue creado el 17 de julio y acumulaba 16 transacciones en total cuando consultamos el explorer el 21 de agosto. El despliegue es real; el uso todavia no esta.

Fireblocks fue agregado a la lista de facilitators de x402 el 20 de agosto, ofreciendo settlement respaldado por vault donde las llaves privadas nunca salen de Fireblocks — la decimocuarta entrada de esa tabla. Y el 21 de agosto se mergeo un perfil SVM de batch-settlement de 1.530 lineas, que especifica payment channels de larga vida en Solana con vouchers acumulativos y un request_close firmado por el pagador como via de reembolso interoperable, finalizado por el facilitator despues de un periodo de gracia configurable de 15 minutos a 30 dias. Es la contraparte en Solana del scheme batch-settlement que cubrimos en julio.

A2A, en contraste, no lanzo nada estructural: los unicos commits del repositorio en la ventana fueron actualizaciones de roster de governance y un arreglo de build para la generacion del JSON schema.

Que significa para LLM4Agents

El default de spend controls cambia lo que el comprador espera de nosotros. Un cliente que se autolimita a un dolar por pago va a chocar contra ese techo frente a pricing de inferencia por llamada apenas el request sea grande o el modelo caro. De ahi salen dos consecuencias. Los precios cotizados detras de un 402 tienen que quedar comodamente dentro de un sobre razonable por pago, y el scheme upto se vuelve mas atractivo que exact para inferencia, porque un techo que fija el comprador es exactamente la forma que un cliente con tope quiere firmar.

settlement_pending es mas urgente de lo que parece. Cualquier gateway que otorgue acceso ante un settle exitoso y lo niegue ante un settle fallido tiene ahora una tercera rama que escribir. Tratar un settlement pendiente como falla significa o cobrarle dos veces al comprador que reintenta, o negarle el servicio al que ya pago. El manejo correcto es guardar el hash de la transaccion, servir o encolar el request, y reconciliar on-chain — lo que exige un camino de reconciliacion que la mayoria del codigo de billing hoy no tiene.

Que AWS eligiera upto para pay-per-inference es validacion y presion a la vez. Confirma la tesis de settlement medido sobre la que esta construido el gateway, y a la vez significa que el mayor proveedor cloud ya esta lanzando una capa de abstraccion sobre x402 y MPP. Ser alcanzable a traves de esa capa importa mas que ser alcanzable directo: un agente construido sobre AgentCore no elige nuestro protocolo, elige nuestro inventario.

La propuesta de la FASB, por ultimo, elimina un bloqueador silencioso del lado de la demanda. Como senalamos en el roundup de la semana pasada, la restriccion de los pagos entre maquinas hoy es el inventario comprable, no los rails. Pero la segunda restriccion es un equipo de finanzas que no puede clasificar el float. Esa objecion tiene, desde esta semana, una respuesta propuesta.

Como mantenerse en la frontera

Uno — manejar settlement_pending de forma explicita. Agregar la tercera rama al camino de settle: ante settlement_pending, persistir el hash de la transaccion, no volver a cobrar, y reconciliar contra la cadena antes de cualquier reintento. Enviarlo antes de que la version del SDK que lo emite sea la comun.

Dos — cotizar dentro del sobre por defecto. Publicar precios por llamada que un cliente con tope de un dolar pueda pagar sin cambiar su configuracion, y documentar exactamente que requests pueden excederlo. Un comprador que tiene que editar spendControls para usar el gateway es un comprador que no usa el gateway.

Tres — liderar con upto para inferencia. El pricing exacto le queda bien a un recurso fijo. La inferencia no lo es. Cotizar un techo al momento del request, liquidar los tokens realmente consumidos y hacer visible en el recibo la diferencia entre autorizado y liquidado.

Cuatro — meter el inventario en las capas de abstraccion. AgentCore ya rutea entre protocolos y expone endpoints x402 curados a traves de su Gateway. Superficies de discovery de ese tipo se estan volviendo el canal de adquisicion. Estar listado donde el agente que transacciona ya mira le gana a ser alcanzable por quien lea nuestra documentacion.

Cinco — publicar la historia de tesoreria junto con la tecnica. Si un equipo de finanzas ahora puede argumentar que el float operativo es un cash equivalent, darle los artefactos que ese argumento necesita: que stablecoin, que emisor, que derecho de redencion y un rastro de recibos por llamada que reconcilie con eso.