Fuente original: Waterdrop Capital

Resumen

Los modelos grandes evolucionan de herramientas que responden preguntas a agentes inteligentes capaces de planificar, invocar herramientas y entregar resultados. Al mismo tiempo, la liquidación con stablecoins, los protocolos de pago nativos para HTTP (HTTP 402) y las billeteras inteligentes comienzan a integrarse en una infraestructura de pagos diseñada para máquinas. Un programa puede recibir una cotización en tiempo de ejecución, firmar una autorización y completar un micropago: algo que hace pocos años era solo un concepto, pero que hoy es un camino tecnológico viable.

Sin embargo, «las máquinas pueden pagar» no equivale a «las máquinas pueden completar transacciones». Cuando un agente inteligente necesita adquirir servicios como búsqueda, datos, potencia computacional, generación de contenido o análisis profesional, sigue enfrentando desafíos como descubrir endpoints, comparar cotizaciones, realizar pagos entre protocolos, controlar presupuestos, verificar la entrega y unificar la conciliación. Las vías de pago resuelven cómo se traslada el valor, pero no resuelven automáticamente cómo la demanda encuentra la oferta ni si el servicio correcto se recibió tras el pago.

Esto significa que, en la próxima fase del «pago por agentes», el foco competitivo ya no será únicamente el rendimiento del protocolo, la velocidad de liquidación o la cantidad de cadenas compatibles, sino si se puede construir una infraestructura real de compradores automáticos. Este artículo analiza por qué el «pago por agentes» se convertirá en una vía independiente —desde la estructura de la demanda, la evolución de los protocolos, los cuellos de botella reales y la división del trabajo en el mercado— y qué vínculos clave siguen faltando para su adopción a escala.

Introducción: los agentes inteligentes obtienen un «presupuesto discrecional» limitado

En los últimos dos años, las capacidades de los agentes inteligentes han evolucionado muy rápido. Inicialmente, los grandes modelos se centraban en la generación de información: los usuarios hacían preguntas y los modelos producían texto. Luego, la invocación de herramientas permitió a los modelos buscar páginas web, consultar bases de datos, ejecutar código y operar software. Más adelante, los agentes inteligentes comenzaron a descomponer objetivos, formular planes y ajustar acciones según resultados externos en múltiples rondas de ejecución.

Cuando los objetivos de ejecución se limitaban a herramientas gratuitas o sistemas empresariales internos, los permisos de invocación podían configurarse previamente por los desarrolladores. Pero las capacidades de alta calidad en mercados abiertos suelen requerir pago: los datos financieros en tiempo real tienen precio por llamada, el web scraping consume créditos, la potencia de inferencia y GPU se factura por uso, y la generación de video y las bases de datos profesionales tienen precios claros. Para que un agente inteligente complete una tarea de forma autónoma, inevitablemente debe actuar como comprador durante la ejecución.

El modelo tradicional de negocio de API no fue diseñado para este tipo de comprador. Requiere que una persona visite primero un sitio web, registre una cuenta, vincule una tarjeta bancaria, seleccione un plan, proteja una clave API y luego inserte esa clave en el entorno del programa. La decisión de compra y la invocación real están separadas en dos momentos: los humanos realizan la compra antes de la tarea, y el software solo consume la cuota ya adquirida.

Un agente quizá no sepa qué necesita hasta llegar a cierto paso de la ejecución. No puede predecir con antelación qué fuente de datos llamará finalmente, ni debería exigirse al usuario crear cuentas para cada posible servicio. Su proceso de adquisición es instantáneo, de bajo valor, multi-mercado, de alta frecuencia y orientado a resultados. Para él, la experiencia más natural no es «suscribirse primero, luego llamar», sino «descubrir el servicio, obtener una cotización, autorizar el pago, recibir el resultado».

El «pago por agentes» no consiste simplemente en añadir un botón de pago a un chatbot. Significa que el software comienza a tener autoridad limitada para gastar y desarrolla un proceso de adquisición propio de las máquinas. Los humanos establecen objetivos, presupuestos y límites de riesgo, y los agentes asignan fondos dentro de esos límites. Así, el pago deja de ser una acción de liquidación para convertirse en parte del sistema de toma de decisiones del agente.

1. Por qué el «pago por agentes» se convertirá en una vía independiente

1.1 De la invocación de herramientas a la acción económica

La diferencia entre agentes y scripts de automatización comunes no radica solo en su capacidad de razonamiento. Los scripts ejecutan procesos predeterminados, y los recursos y proveedores necesarios suelen estar ya codificados; los agentes eligen rutas según el entorno. En la misma tarea de investigación, podría primero comprar resultados de búsqueda, luego decidir, según esos resultados, si necesita una base de datos sectorial y, finalmente, invocar otro modelo para validación cruzada. Cada paso de adquisición modifica las decisiones posteriores.

Este modelo de «ejecutar mientras se adquiere» incorpora la elección económica al tiempo de ejecución del software. Un agente no solo debe evaluar si una herramienta está disponible, sino también si vale la pena comprarla: si el precio supera el presupuesto, si la velocidad de respuesta cumple los requisitos de la tarea, si su historial de cumplimiento es confiable y si otro servicio alternativo es más adecuado. El enrutamiento tradicional de herramientas se enfoca en la coincidencia de capacidades, mientras que la adquisición por máquinas debe gestionar simultáneamente precio y riesgo de contraparte. En tales transacciones, quien asume el riesgo es el propio agente: el pago puede realizarse con éxito, pero el servicio podría no entregarse.

Por lo tanto, la necesidad central del «pago por agentes» no es el pago automático incondicional, sino delegar de forma controlada el poder de compra al software. Los usuarios no entregarán fácilmente toda su billetera a un agente, pero sí aceptarán asignarle unos dólares para una tarea clara y permitirle realizar varias compras de centavos. Las autorizaciones grandes aún requerirán construcción progresiva de confianza, pero las pequeñas ya generan valor real.

1.2 Micropagos, alta frecuencia y múltiples comerciantes transforman la economía de los pagos

La infraestructura de pagos de internet humano está optimizada para transacciones de menor frecuencia y mayor valor. Las redes de tarjetas de crédito, las pasarelas de pago y los sistemas de suscripción tienen costos fijos, por lo que los comerciantes suelen agrupar muchas solicitudes en paquetes mensuales. Para solicitudes de API que valen apenas unos céntimos, las comisiones, el riesgo de devoluciones y los costos de mantenimiento de cuentas pueden superar el valor mismo de los bienes.

El consumo por máquinas es exactamente lo opuesto. Un agente puede iniciar múltiples compras con múltiples comerciantes en minutos para completar un único entregable. El monto por transacción es muy bajo, pero la frecuencia de llamadas es alta y el número total de transacciones puede superar ampliamente al de los consumidores humanos. Las monedas estables y la liquidación programable en cadena ofrecen una nueva base económica para estos escenarios: los fondos fluyen las 24 horas, las autorizaciones de pago pueden firmarse mediante software y los servicios pueden cotizarse directamente por llamada.

Más importante aún, la adquisición multi-comerciante cambiará la forma en que funciona la competencia en el mercado de APIs. Los modelos de suscripción incentivan a los usuarios a permanecer vinculados a un solo proveedor a largo plazo, mientras que el pago por uso permite a los agentes tomar decisiones dinámicas para cada tarea. Los proveedores ya no compiten únicamente por contratos anuales, sino también por necesidades puntuales. El precio, el rendimiento y los registros de cumplimiento pueden influir en tiempo real en los resultados de enrutamiento.

1.3 Las monedas estables evolucionan de medio de intercambio a infraestructura de liquidación

En los primeros mercados cripto, la demanda de monedas estables provenía principalmente del trading y de la huida de capitales hacia activos seguros. A medida que maduran gradualmente la emisión, custodia, cumplimiento normativo y la infraestructura multi-cadena, las monedas estables comienzan a ingresar a la liquidación transfronteriza, la gestión de tesorería corporativa y los pagos nativos de internet. Para los pagos entre máquinas, las monedas estables tienen otra ventaja especial: son tanto moneda como activo digital que puede operarse directamente mediante programas.

Los pagos con tarjeta de crédito dependen de la identidad del titular, cuentas bancarias y redes geográficas. Los agentes, por sí mismos, carecen de identidad de persona física y no pueden realizar procesos tradicionales de apertura de cuentas de forma independiente. Sin embargo, una billetera restringida por políticas puede convertirse en la interfaz financiera del agente: el operador deposita un saldo limitado, establece límites por transacción y por sesión, y conserva permisos para congelar o revocar; el agente solo firma pagos dentro del alcance autorizado.

Esto no significa que los pagos en cadena sean intrínsecamente superiores a todos los pagos tradicionales. La protección al consumidor, los mecanismos de reembolso, la privacidad, la gestión de claves y la responsabilidad regulatoria siguen requiriendo atención. Pero en pagos máquina-máquina, de bajo valor y por uso, y en la adquisición global de servicios, las monedas estables programables ofrecen una clara compatibilidad. Por primera vez, permiten comprimir «llamar a una interfaz» y «pagar una interfaz» en una única interacción de red.

2. Ya existen vías de pago: x402, MPP y transacciones nativas HTTP

2.1 Convertir el código de estado 402 en una interfaz comercial

HTTP reservó hace mucho tiempo el código de estado 402 (Pago requerido), pero durante casi 30 años no se consolidó en un flujo de trabajo generalizado. Los protocolos de pagos entre máquinas han reactivado esta semántica: el cliente solicita un extremo de pago, el servidor responde con 402 y términos de pago legibles por máquina; el cliente selecciona una opción aceptable, completa la firma o el pago, y luego reintenta la solicitud con las credenciales correspondientes.

La importancia de este proceso radica en que elimina la página de registro humana. El descubrimiento de precios, los requisitos de pago y la entrega de contenido ocurren todos a nivel de protocolo, comprensible por programas. Para los desarrolladores, las APIs de pago ya no necesitan construir un portal SaaS completo entorno a cuentas, planes y claves; para los agentes, los servicios pueden descubrirse como páginas web comunes y comprarse cuando realmente se necesitan.

x402 es uno de los protocolos abiertos más observados en este camino. Organiza desafíos y credenciales de pago en torno al código HTTP 402, permitiendo a los proveedores cobrar por cada solicitud. MPP, por su parte, parte de un ecosistema distinto y explora métodos de pago orientados a máquinas, como cargos y sesiones. Sus diseños específicos difieren, pero juntos validan una dirección: los pagos entre máquinas pueden integrarse en el protocolo de aplicación, sin requerir un proceso de liquidación manual externo.

2.2 Naturaleza duradera de la diversificación de vías de pago

La industria suele esperar que, con el tiempo, solo quede un protocolo estándar, una red de liquidación y un esquema de pago. Pero desde la perspectiva del comerciante, la diversificación tiene una lógica a largo plazo. Las consultas puntuales de datos se adaptan mejor al pago por llamada, mientras que los servicios continuos de inferencia o streaming pueden convenir más a facturación por sesión; los servicios de alto valor exigen garantías y mecanismos de resolución más robustos, mientras que las llamadas de bajo valor priorizan velocidad y costo; distintas regiones y empresas también elegirán redes de cumplimiento y liquidación diferentes.

La capa de protocolo seguirá innovando. Los comerciantes podrían adoptar débito directo, autorización previa, depósitos en garantía, pagos en streaming o liquidación por lotes; las redes podrían hacer distintos equilibrios entre costo, finalidad, liquidez y herramientas del ecosistema. Para los vendedores, esto representa libertad de elección. Para los compradores, cada nueva combinación añade otra superficie de integración.

La matriz de configuración en la figura inferior es una instantánea de esta diversificación: los protocolos/esquemas de pago forman las columnas, las cadenas las filas, y cada opción es una configuración de pago que requiere integración independiente; además, esta tabla sigue ampliándose.

Figura 1: Matriz de configuración de vías de pago bajo fragmentación

Así pues, la fragmentación no desaparecerá necesariamente de forma natural al madurar el mercado. El mercado de tarjetas bancarias no terminó con una sola organización de tarjetas tras décadas de desarrollo, ni la computación en la nube convergió en un único proveedor. Los mercados maduros normalmente no eliminan las diferencias, sino que construyen capas de agregación, enrutamiento y compensación sobre ellas. Es muy probable que los pagos entre agentes sigan esta misma trayectoria evolutiva. Esta división ya es medible. Datos de dos exploradores públicos (x402scan y mppscan) de los últimos 30 días (hasta el 3 de septiembre de 2026) muestran: el protocolo MPP tiene 65 591 billeteras activas de compradores en la cadena Tempo, x402 tiene 19 472 en la cadena Base, y solo 365 billeteras aparecen en ambas vías, menos del 0,6 % de los compradores de MPP y el 2 % de los compradores de Base de x402; de ellos, solo 112 realizaron más de diez transacciones en cada vía, y una parte considerable corresponde a agregadores de doble vía que pagan en nombre de usuarios con la misma clave, no a compradores que adopten voluntariamente una segunda vía de pago. Los compradores no migran entre vías; cada vía acumula su propia base independiente de compradores.

2.3 La incorporación del vendedor es solo la mitad de la transacción

Los protocolos de pago reducen primero la barrera para que los comerciantes acepten pagos. Una vez que un punto final puede publicar cotizaciones, verificar credenciales y devolver servicios, cumple las condiciones básicas para el comercio orientado a máquinas. Así, una creciente cantidad de herramientas para desarrolladores, servicios de datos e interfaces de contenido se vuelven comprables por máquinas.

Sin embargo, que la oferta sea pagable no implica que la demanda siga automáticamente. Los comerciantes resuelven «¿cómo cobro pagos de máquinas?», pero los agentes aún deben responder «¿de quién compro?, ¿qué método de pago uso? y ¿cómo confirmo la entrega tras el pago?». Si cada comprador debe integrar por separado cada protocolo, preparar fondos en distintas redes y mantener libros contables independientes, los pagos automáticos repetirán la complejidad de las primeras integraciones API: solo intercambiando claves API por billeteras y adaptadores de protocolo.

La adopción real depende de la fricción total de la transacción, no solo de la fricción en el paso de liquidación.

3. El verdadero cuello de botella del sector: las transacciones carecen de bucle cerrado

Figura 2: Proceso completo de una adquisición automática

3.1 Primer obstáculo: descubrir servicios comprables

Los agentes necesitan directorios de servicios legibles por máquina. Un directorio eficaz no puede contener solo nombres y URLs; también debe describir capacidades del punto final, entradas y salidas, unidades de precios, protocolos disponibles, latencia, restricciones geográficas y estado de actualización. También se requiere una correspondencia entre la intención en lenguaje natural y los parámetros de la API; de lo contrario, un agente sabe que «necesita datos macroeconómicos», pero no puede determinar qué punto final satisface la tarea.

Los directorios en mercados abiertos también enfrentan duplicación, caducidad y afirmaciones falsas. Cualquier comerciante puede afirmar ofrecer datos de alta calidad, pero los agentes no pueden dedicar días a verificaciones como el personal humano de compras. La capa de descubrimiento debe verificar continuamente si los puntos finales son invocables, si las cotizaciones son reales y si las descripciones coinciden con el contenido devuelto.

Esto hace que el descubrimiento de servicios difiera de la búsqueda tradicional. Los motores de búsqueda optimizan la relevancia informativa, mientras que los directorios para adquisiciones automáticas deben optimizar también la negociabilidad: si las capacidades coinciden, si los precios son aceptables, si los pagos son compatibles y si los comerciantes pueden entregar.

3.2 Segundo obstáculo: comprender y comparar cotizaciones

Superficialmente, APIs similares pueden tener todos un precio por llamada, pero en realidad las cotizaciones son débilmente comparables. Una cobra por solicitud, otra por ítem resultante; una incluye la inferencia del modelo en el precio, otra exige un pago adicional; otros servicios facturan dinámicamente según longitud de entrada, tiempo de ejecución o resultados exitosos.

Un agente no puede simplemente elegir el punto final con el precio nominal más bajo. Debe considerar el costo total, la probabilidad de entrega, la latencia y la calidad del resultado. Si una interfaz barata falla repetidamente, los costos de reintento y los retrasos en la tarea pueden elevar su precio efectivo. Por tanto, las cotizaciones deben evaluarse junto con el nivel de servicio, el rendimiento histórico y el contexto de la tarea.

Las cotizaciones legibles por máquina también deben especificar periodos de validez y montos finales. En un entorno de precios dinámicos, lo que firma el agente debe ser un compromiso firme, no un rango vago. Los operadores también necesitan conocer la composición de las tarifas —tarifas de servicio, costos de red y tarifas de enrutamiento— para establecer presupuestos creíbles.

3.3 Tercer obstáculo: distribución de fondos y liquidez multiplataforma

Si un agente necesita adquirir servicios simultáneamente en múltiples cadenas y protocolos, el enfoque más directo es prefinanciar saldos en cada red. Pero esto fragmenta un pequeño monto de capital en muchas partes. Los fondos permanecen inactivos en redes no utilizadas, mientras que las redes populares pueden quedarse sin saldo; recargar implica puentes, intercambios, gas y operaciones de seguridad.

Para un usuario individual, ya es engorroso. Para una empresa que gestiona muchos agentes, el problema se amplifica: ¿qué saldo debe mantener cada agente?, ¿quién se encarga de recargar?, ¿cómo evitar gastos indebidos? y ¿cómo consolidar activos y tarifas entre distintas redes? Sin una capa unificada de financiación, más vías de pago equivalen a mayor complejidad financiera.

Idealmente, lo que ve un agente es un único presupuesto disponible, no múltiples saldos de red. El sistema subyacente gestiona las rutas de liquidación, la liquidez y ofrece cotizaciones transparentes. El principio es similar al de un viajero que usa una sola tarjeta en distintos países: el usuario se centra en el límite de crédito total y el tipo de cambio, sin necesidad de abrir cuentas locales en cada destino.

3.4 Cuarto obstáculo: autorización basada en políticas

La preocupación más fácil de activar por los pagos autónomos es si un agente gastará sin control. La solución no es simplemente elegir entre «prohibición total» y «autorización total», sino establecer políticas multinivel.

Límites por transacción limitan las pérdidas por un error aislado; presupuestos por sesión acotan el gasto total de una tarea; listas blancas o negras de comerciantes controlan contrapartes; reglas por categoría restringen lo que se puede comprar; y límites de tasa evitan llamadas anómalas en corto plazo. Las transacciones de alto riesgo o alto valor también pueden requerir confirmación manual. Las políticas deben definirlas los operadores, y los agentes solo pueden actuar dentro de esos límites: no pueden elevarlos por sí mismos.

Una billetera no debe limitarse únicamente a la firma. Debe integrarse con tareas, identidad y registros de auditoría para responder: «¿qué agente aprobó este pago, para qué tarea y bajo qué política?». De lo contrario, la empresa obtendrá solo una cadena de hashes de transacciones en cadena, insuficiente para cumplir con los controles internos y los requisitos de asignación de costos.

3.5 Etapa cinco: la liquidación exitosa no equivale a la prestación del servicio

La blockchain destaca al demostrar que los fondos se han transferido de una dirección a otra, pero no puede probar intrínsecamente que una API devolvió el contenido correcto. Una transacción puede completar su liquidación, aunque el servidor falle por tiempo de espera, devuelva un estado de error o entregue datos distintos a los anunciados. Para los agentes, esto no es un caso marginal: es el núcleo del riesgo de adquisición.

El comercio electrónico tradicional vincula pago y entrega mediante logística, reseñas y reembolsos; los servicios máquinas carecen de logística física —la entrega puede ser tan solo una respuesta HTTP efímera. Si los sistemas de pago solo registran la trayectoria de los fondos y los comerciantes solo anotan sus propias respuestas, el mercado carece de una visión unificada de cumplimiento que abarque comerciantes y protocolos.

Lo que exige precaución es que registrar una respuesta no equivale a probar su calidad. Pero correlacionar el pago con la respuesta permite, al menos, distinguir estados básicos como «pagado y resultado recibido», «pagado pero servicio fallido» y «no liquidado». Este es el primer nivel de hecho para construir credibilidad en las transacciones máquinas.

3.6 Etapa seis: conciliación unificada y definición de responsabilidades

Una sola tarea puede incluir docenas de microcompras. Si cada transacción está dispersa entre distintas billeteras, protocolos y backends de comerciantes, resulta difícil para los usuarios comprender por qué el producto final tuvo ese costo. Las empresas también deben asignar los gastos a proyectos, equipos, clientes y centros de costos, además de conservar evidencia auditables.

Un libro mayor unificado debe registrar simultáneamente la intención de adquisición, los comerciantes, las cotizaciones, las políticas de autorización, los resultados de liquidación, el estado de la respuesta y las causas de fallo. No sirve solo para finanzas, sino también para optimizar agentes. El sistema puede analizar qué fuentes de datos fallan con frecuencia, qué rutas son más costosas y la mezcla típica de adquisiciones para un tipo específico de tarea.

Cuando el pago se integra en la cadena de razonamiento, el costo se convierte en una señal de retroalimentación para las decisiones del modelo. Sin conciliación unificada, los agentes solo pueden optimizar respuestas, no el proceso económico para obtenerlas. Gran parte del valor a largo plazo del «Pago para Agentes» proviene precisamente de esta observabilidad.

4. Del protocolo de pago a la capa de adquisición para máquinas

4.1 La abstracción central del futuro no es «pagar», sino «comprar»

Pagar es una acción posterior a definir el objeto y el precio, mientras que adquirir abarca todo el proceso desde la demanda hasta la aceptación. Exponer una función pay() a un agente solo le permite transferir fondos a una dirección conocida; exponer una capacidad buy() significa que el sistema puede recibir la demanda, descubrir servicios, comparar opciones, ejecutar el pago y devolver resultados verificables.

Esta distinción define la división del trabajo en la industria. Los protocolos ofrecen mensajes estandarizados de pago, las billeteras gestionan firmas y activos, las redes de liquidación trasladan valor, los directorios agrupan oferta y la capa de adquisición organiza estos componentes en una única tarea. Cualquier componente individual es importante, pero ninguno representa por sí solo una transacción completa.

La capa de adquisición para máquinas debe permanecer abierta. No debe exigir que todos los comerciantes migren al mismo protocolo ni determinar quién puede adquirirse mediante un directorio cerrado. Un modelo más sostenible es ser compatible con múltiples vías de pago, revelar los costos de enrutamiento en las cotizaciones y permitir que los agentes elijan de forma autónoma según su política.

4.2 La agregación de compradores puede ser más importante que la de vendedores

Las plataformas de internet suelen agrupar primero la oferta y luego atraer consumidores. En los mercados máquinas, la oferta ya existe ampliamente en forma de APIs; lo que falta es un comprador estandarizado capaz de realizar compras continuas. Un agente equipado puede convertir una demanda fragmentada y ocasional en un flujo estable de transacciones.

La agregación de compradores también mejora la visibilidad de servicios de nicho. Los desarrolladores humanos suelen usar marcas grandes y conocidas porque el costo temporal de evaluar nuevos proveedores es alto; si los agentes pueden leer capacidades, precios y señales de cumplimiento estandarizados, podrán elegir servicios más adecuados para cada tarea. Esto podría reducir los costos de adquisición de clientes para nuevos comerciantes y forzar a los establecidos a competir por su desempeño real.

No obstante, los puntos de entrada para compradores también pueden generar nuevo poder de plataforma. Quien controle el directorio predeterminado, el ordenamiento y las vías de pago podrá influir en la asignación de tráfico. Por tanto, la industria necesita reglas de clasificación transparentes, tarifas explicables y registros de transacciones portátiles. La agregación reduce fricciones, pero no debe empaquetar protocolos abiertos como canales cerrados.

4.3 Construir reputación basada en datos reales de transacciones

Los compradores máquinas toman decisiones muy rápido y no pueden depender de evaluaciones exhaustivas. Necesitan señales sobre la contraparte al mismo tiempo que aparece la cotización. Las calificaciones tradicionales y reseñas de usuarios pueden servir de referencia, pero son fácilmente manipulables mediante volúmenes ficticios, cuentas síbil y partes relacionadas. Si las reseñas no requieren un pago real, el costo del ataque es especialmente bajo. Investigaciones empíricas recientes sobre ERC-8004 —la primera capa de confianza on-chain permisionless para agentes— confirman esto [6]. La especificación del protocolo afirma textualmente que «los pagos son independientes de este protocolo»: las reseñas, por defecto, no necesitan vincularse a ninguna transacción pagada real, y la prueba de pago es solo un campo opcional. El resultado es que, en Ethereum, BSC y Base (a 13 de mayo de 2026), respectivamente, el 73,5 %, el 59,2 % y el 90,6 % de los reseñadores mostraron comportamiento coordinado de cuentas síbil.

Una base más fiable son los registros de resultados vinculados a llamadas reales pagadas: cuántos acuerdos ha completado un punto final de servicio, cuál es su tasa de éxito en respuestas, cuál es su latencia habitual y qué proporción de llamadas no responde tras el pago. Estas métricas aún no representan plenamente la calidad del contenido, pero están más cerca de hechos verificables que de declaraciones autodeclaradas.

Al acumularse datos, el mercado podría desarrollar una reputación escalonada: el primer nivel sería el estado objetivo de las transacciones, el segundo nivel métricas de servicio reproducibles y el tercero evaluaciones de calidad para tareas específicas. Los agentes podrán elegir la solidez requerida de la evidencia según el monto y el riesgo: unos pocos céntimos para una consulta de datos pueden basarse en señales estadísticas, mientras que adquisiciones de alto valor exigirán garantías, auditorías o resolución de disputas.

4.4 La estrategia presupuestaria se convertirá en una capacidad clave para los agentes

Hoy los agentes se evalúan principalmente por la calidad de las respuestas, la tasa de finalización de tareas y la precisión en llamadas a herramientas. Al ingresar a entornos remunerados, deben incorporarse métricas económicas: cuánto se gasta para lograr la misma calidad, si la tarea se completa dentro del presupuesto, cuándo vale la pena adquirir datos más costosos y cómo equilibrar velocidad, costo y fiabilidad.

Esto generará nuevas direcciones para entrenamiento y evaluación. Los agentes no solo aprenderán «qué herramienta responde la pregunta», sino también «si comprar esta herramienta es rentable dada la importancia de la tarea actual». Podrían usar primero servicios de bajo costo para filtrar y luego adquirir verificaciones de alta calidad para conclusiones clave; también podrían reducir la frecuencia de llamadas al agotarse el presupuesto o solicitar autorización adicional al usuario.

En este sentido, el Pago de Agentes no es un complemento financiero externo a las capacidades del modelo, sino parte de la inteligencia decisional. Un agente verdaderamente maduro no solo debe usar recursos, sino también valorarlos.

5. Posibles trayectorias evolutivas del Pago de Agentes

5.1 Fase uno: herramientas para desarrolladores y servicios digitales lideran el camino

Los primeros escenarios a gran escala seguirán siendo puramente digitales: búsquedas, datos, scraping por proxy, inferencia de modelos, ejecución de código, almacenamiento y generación de contenidos. Estos servicios ya se ofrecen mediante API, tienen bajos costos marginales de entrega, permiten pago y respuesta en la misma sesión de red y no implican logística compleja.

Los montos típicos en esta fase serán muy pequeños y los usuarios priorizarán la facilidad de desarrollo y la tasa de finalización de tareas. El mercado validará rápidamente los protocolos, aunque el volumen de transacciones podría estar muy fragmentado. Muchas llamadas seguirán gestionándose con claves API tradicionales y suscripciones, mientras que los pagos automáticos se usarán más para necesidades temporales, compras cruzadas entre proveedores y servicios de nicho que no puedan habilitarse previamente mediante cuentas.

5.2 Fase dos: presupuestos empresariales y colaboración entre múltiples agentes

Cuando las empresas comiencen a desplegar múltiples agentes, la gestión de fondos pasará de billeteras personales a sistemas contables organizacionales. Las empresas deberán asignar presupuestos a distintos roles, controlar categorías adquiribles, establecer umbrales de aprobación y registrar los gastos en sus sistemas financieros. También podría surgir una liquidación interna entre agentes: agentes de investigación adquieren datos, agentes de análisis compran potencia computacional y agentes de ejecución llaman a servicios externos.

En esta etapa, la seguridad y el cumplimiento cobran mayor importancia que la novedad del pago. A las empresas les interesa la custodia de claves, el aislamiento de permisos, la supervisión de transacciones, la revisión de proveedores y los registros auditables. Solo la infraestructura capaz de integrarse con los procesos financieros existentes podrá pasar de la experimentación a la producción.

5.3 Fase tres: extensión desde servicios digitales hasta la economía real

Billetes aéreos, hoteles, logística, publicidad y servicios profesionales podrían convertirse en objetivos de adquisición para agentes, pero las transacciones del mundo real exigen identificación, reembolsos, impuestos y resolución de disputas más complejos. Las monedas estables solo resuelven parte del problema de liquidación; no sustituyen los derechos del consumidor ni los contratos comerciales.

Por tanto, la industria no debe interpretar erróneamente el «pago autónomo» como la eliminación de todos los intermediarios. Por el contrario, al aumentar el valor de las transacciones, reaparecerán garantías, seguros, crédito y arbitraje —simplemente deben transformarse en servicios invocables por máquinas. La futura pila de Pago de Agentes podría incluir simultáneamente protocolos de pago abiertos y conectividad financiera tradicional, sin que un camino reemplace al otro.

5.4 Fase cuatro: desde el encaminamiento entre protocolos hasta la ejecución entre mercados

A largo plazo, lo que los agentes adquieren no es solo una respuesta de API, sino un resultado. Un usuario podría solicitar «generar un informe sectorial creíble», y el sistema combinaría de forma autónoma búsquedas, bases de datos, traducción, modelos y servicios de verificación. Ocurren múltiples transacciones en la capa inferior, mientras el usuario solo ve el presupuesto total, las fuentes de evidencia y la entrega final.

Esto elevará el encaminamiento de pagos a ejecución de mercado. El sistema deberá descomponer objetivos complejos en carteras de adquisición, sustituir dinámicamente proveedores fallidos y optimizar entre costo total y calidad. La compatibilidad de protocolos es solo la base; la ventaja competitiva real proviene de la comprensión de la demanda, los datos transaccionales y los comentarios de ejecución.

6. Riesgos y preguntas abiertas

Los pagos mediante agentes tienen un enorme potencial imaginativo, pero no se pueden ignorar las limitaciones del mundo real. La primera es la seguridad. Las inyecciones de indicaciones podrían inducir a los agentes a adquirir servicios maliciosos; los ataques a la cadena de suministro podrían sustituir las direcciones de recepción, y unas políticas defectuosas podrían provocar pagos duplicados masivos. Las acciones de pago deben aislarse del contenido no fiable y dotarse de límites, simulación, revocación y detección de anomalías.

La segunda es la privacidad. Los registros de adquisiciones revelan qué tareas está realizando un agente, y los datos públicos en cadena podrían vincular la identidad del usuario con su intención comercial. Los sistemas deben minimizar la filtración de metadatos sensibles y lograr un equilibrio entre los requisitos de auditoría y la privacidad.

La tercera es la responsabilidad. Cuando un agente realiza una compra errónea, un comerciante no entrega el producto o falla una conversión de protocolo, ¿quién debe asumir la pérdida? Las transacciones de bajo valor pueden aceptar riesgos automatizados, pero las de alto valor exigen límites claros de responsabilidad. Una red de pagos sin mecanismo de resolución de disputas tendrá dificultades para ingresar directamente al comercio de alto valor.

La cuarta es la regulación. La emisión de stablecoins, el control de billeteras, las transferencias transfronterizas y los pagos a comerciantes están sujetos a normativas distintas según la jurisdicción. Las máquinas son ejecutoras, no sujetos de responsabilidad legal. La infraestructura debe poder rastrear cada transacción autónoma hasta un operador claro, una política de autorización y un origen de fondos.

La quinta es la sostenibilidad comercial. Los ingresos por micropagos se erosionan fácilmente por costos de red, liquidez y tarifas de control de riesgo. Si las plataformas subvencionan la experiencia mediante recargos ocultos, socavan la confianza de los compradores. Las tarifas deben ser transparentes y un modelo de negocio sólido debe construirse mediante escala, eficiencia de enrutamiento y servicios de valor añadido.

Estos problemas no invalidan el sector, sino que muestran que los pagos mediante agentes no se completarán mediante un único protocolo. Finalmente, se convertirán en una infraestructura compuesta para pagos, identidad, permisos, descubrimiento, reputación y conciliación.

7. SELAT: Dotando al lado de la compra para el comercio nativo de máquinas

«SELAT» proviene de la palabra malaya para «estrecho», como el estrecho de Malaca (Selat Melaka). Durante siglos, independientemente del puerto de origen de las mercancías o del mercado de destino, la corriente principal del comercio este-oeste pasó por esta vía acuática. SELAT aspira a convertirse en ese estrecho en el comercio nativo de máquinas: sin importar en qué vía se conecte un comerciante, la demanda de los agentes puede fluir aquí.

SELAT es una empresa nativa de IA que decide entrar en los pagos mediante máquinas desde el lado de la compra. SELAT es la capa del lado de la compra para el comercio nativo de máquinas. Su objetivo central no es crear otra vía de pagos que obligue a los comerciantes a migrar, sino permitir que los agentes realicen adquisiciones a través de las vías existentes. Se centra en dos problemas clave: primero, la fragmentación de las configuraciones de pago, donde difieren las vías, protocolos, cadenas y credenciales, lo que requiere una nueva integración para cada comerciante; segundo, la falta de medición del riesgo de contraparte, ya que una liquidación exitosa no implica necesariamente la entrega del servicio.

Figura 3: Diagrama esquemático de la capa de compra SELAT

Para abordar la fragmentación, la CLI de SELAT mantiene las diferencias de protocolos, esquemas de pago y redes de liquidación en la capa de infraestructura, permitiendo que los agentes realicen adquisiciones transversales con un solo comando. El descubrimiento, cotización, autorización, pago, registro del estado de entrega y conciliación se integran en un mismo proceso de adquisición, y cada llamada también se registra en el mismo libro contable.

• Una tesorería, usando N vías de pago

Los agentes mantienen un saldo de USDC en custodia propia, sin necesidad de prefinanciar por cadena ni gestionar distintos clientes para distintos protocolos.

• Catálogo agregado de puntos finales

La CLI de SELAT integra cuatro registros de servicios de terceros —Circle, MPP, Apify y pay.sh— junto con su propio catálogo, permitiendo a los agentes descubrir y comparar más de 4.000 puntos finales de servicio según la intención en tiempo real.

• Límites estrictos de gasto

Los operadores pueden establecer límites por transacción y presupuestos por sesión, y congelar los permisos de gasto en cualquier momento; los agentes no pueden elevar dichos límites por sí mismos.

• Sin migración requerida para comerciantes

Los comerciantes pueden conservar sus vías de pago preferidas y ser descubiertos y adquiridos por agentes sin necesidad de volver a registrarse en SELAT.

En el lado del financiamiento, SELAT trabaja con cualquier billetera de agente, incluidas las billeteras de agentes de Circle y MetaMask. SELAT enruta cada compra a través de vías de pago como x402 y MPP, según cotizaciones en tiempo real.

7.1 ERC-8004: Primitivas correctas, señales cuestionables

ERC-8004 define tres tipos de registros —identidad, reputación y validación— y permite a los compradores enviar reseñas a los vendedores. La dirección es acertada, pero separa explícitamente el pago de la reputación: los comentarios no requieren provenir de transacciones reales y adjuntar una prueba de pago es opcional.

Investigaciones empíricas en el ecosistema desplegado muestran que, en Base, el 93,8 % de los revisores nunca realizó un pago x402, pero aportó el 94,9 % de los comentarios; gran parte de estos también exhibe comportamiento coordinado de sybil [6]. Los registros almacenan afirmaciones, pero lo que los compradores realmente necesitan son resultados.

7.2 La reputación vinculada a datos reales de transacción es lo que necesitan los compradores

Las infraestructuras de pago pueden confirmar si los fondos se liquidaron, pero no ven qué servicio se entregó; los comerciantes ven sus propias respuestas, pero no el mercado completo; los registros listan puntos finales, pero no prueban que las reseñas provengan de compras reales.

La capa de compradores que ejecuta las adquisiciones está mejor posicionada para conectar ambos extremos de una transacción: cada compra realizada mediante SELAT registra qué punto final se pagó, cuánto se liquidó y metadatos sobre el estado de entrega posterior al pago (2xx, 4xx, 5xx). Estos registros se acumulan continuamente por comerciante y por infraestructura de pago, formando la base de datos del «Grafo Liquidación–Entrega».

Se requiere una distinción precisa: los registros que vinculan pago y estado de entrega no equivalen a una prueba independiente de calidad de entrega o exactitud de cotizaciones. Pero sí proporcionan la base que carece la reputación basada en registros: datos de resultados vinculados a invocaciones reales pagadas.

7.3 Obtención de credibilidad de la contraparte antes de las transacciones

Mientras en X se debatía cómo diseñar un mecanismo de confianza tipo Google PageRank para la cuarta generación de internet, SELAT ya había lanzado el «Índice de Transaccionalidad» sobre su grafo liquidación–entrega, con el objetivo de brindar a los agentes acceso en tiempo de ejecución a datos de credibilidad de la contraparte respaldados por resultados reales de transacciones.

El índice se devuelve junto con las cotizaciones, sin requerir que los agentes interrumpan sus tareas para investigar por separado a los comerciantes. Advierte sobre riesgos sin crear barreras para el mercado: los puntos finales siguen siendo descubribles y adquiribles, y los agentes toman decisiones según su presupuesto, la importancia de la tarea y su tolerancia al riesgo.

Los agentes no tienen tiempo para leer historias de marca. Antes de pagar, necesitan saber: ¿cómo se desempeña este punto final en transacciones reales? En el comercio nativo para máquinas, la credibilidad no debe provenir de afirmaciones, sino de resultados.

Figura 3: Señales de transaccionalidad en la etapa de cotización

Actualmente, la CLI de SELAT se ha adaptado para entornos de tiempo de ejecución de agentes, incluidos Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes y Grok Bot.

8. Resumen: La economía de máquinas necesita más que simples infraestructuras de pago más rápidas

El pago por agentes se encuentra en una fase fácil de sobreestimar y fácil de subestimar. Es fácil de sobreestimar porque completar técnicamente un pago en stablecoin no implica autonomía comercial madura del agente; y es fácil de subestimar porque, una vez que el software puede adquirir capacidades externas bajo restricciones claras, cambiarán los métodos organizativos, los modelos de precios y los límites competitivos de la economía de máquinas.

Los protocolos de pago ya han demostrado que las máquinas pueden recibir cotizaciones y completar liquidaciones. El siguiente paso clave es ampliar un pago aislado a una adquisición completa: permitir que los agentes encuentren servicios adecuados, comprendan los costos reales, paguen mediante distintas infraestructuras dentro de su presupuesto, confirmen la entrega y conviertan cada transacción en un registro auditado y aprovechable para el aprendizaje.

La futura economía de máquinas no tendrá una sola cadena, un solo protocolo ni una sola billetera. El suministro multifuente persistirá a largo plazo, y la infraestructura verdaderamente valiosa ayudará a los compradores a navegar esta complejidad. El pago por agentes debe integrar infraestructuras de pago, oferta, pagos predeterminados y mecanismos de confianza para convertir la capacidad técnica en demanda real.

Cuando el software comienza a actuar como comprador, el pago es solo el primer paso que da. La pregunta más importante siempre ha sido: ¿puede completar una transacción genuinamente útil de forma controlable, transparente y verificable?

Referencias

[1] Circle, «Construyendo la economía abierta de agentes», 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, «Riesgo de contraparte en pagos autónomos: La mitad no medida», 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, «Impulsando el comercio con IA mediante el nuevo Protocolo de Pagos para Agentes (AP2)», 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] Fundación x402, «x402: Un estándar abierto de pagos nativo de Internet». https://github.com/x402-foundation/x402

[5] Protocolo de Pagos para Máquinas, «MPP: Un protocolo de pagos para máquinas basado en HTTP 402». https://mpp.dev/

[6] Xiong et al., «¿Se puede confiar en agentes sin confianza? Un estudio empírico del ecosistema descentralizado de agentes de IA ERC-8004», arXiv, 2026. https://arxiv.org/abs/2606.26028

[7] Sitio web oficial de SELAT: https://www.selat.ai

Este artículo es una contribución externa y no representa las opiniones de BlockBeats.