Saltar al contenido principal
AprenderGlosarioPago de agente a agente
GLOSARIO

Qué es el pago de agente a agente.

DEFINICIÓN

El pago de agente a agente es un pago realizado por un agente de IA a otro, típicamente de manera programática, generalmente en stablecoin. Tanto el pagador como el beneficiario son autónomos (ningún humano está revisando la transacción en tiempo real). Se distingue del pago de agente a humano (un agente pagando a un negocio operado por humanos) y del pago de humano a humano, donde se aplican flujos de pago convencionales.

POR QUÉ ES IMPORTANTE

La forma que escala la capacidad del agente.

Un solo agente que puede pagar a otros agentes por trabajo especializado es dramáticamente más capaz que uno que tiene que hacer todo por sí mismo. El orquestador delega la traducción a un agente traductor, la búsqueda a un agente de búsqueda, la revisión de código a un agente de revisión de código, la generación de imágenes a un agente de ilustración. Cada delegado es pequeño, enfocado, bien valorado y fácilmente reemplazable. El trabajo del orquestador se convierte en enrutamiento en lugar de ejecución.

Este es el patrón estructural que permite el ecosistema de agentes de agentes hacia el que la mayoría de los laboratorios están construyendo. La capa de pago es el tejido conectivo: sin el pago programático de agente a agente, el orquestador tiene que agrupar cada capacidad internamente (costoso de construir, lento en evolucionar) o exponer sus opciones de delegación al usuario (lo que destruye la abstracción). Con el pago programático, el orquestador enruta de manera invisible, el delegado recibe pago por el trabajo, y el usuario original ve una única respuesta coherente.

CÓMO FUNCIONA

Identidad, solicitud, liquidar, registrar.

  1. Búsqueda de identidad. El agente pagador busca la identidad de pago del beneficiario (página pública, dirección de billetera, precios actuales). Esto a menudo sucede a través de un directorio o mediante la descripción de la API publicada del beneficiario.
  2. Solicitud de pago. La API del beneficiario devuelve un 402 con una URL alojada o acepta una transferencia directa de USDC a su billetera, dependiendo del protocolo. El tiempo de ejecución del agente pagador verifica la solicitud contra su política de gastos antes de iniciar la liquidación.
  3. Liquidación. USDC se mueve de la billetera del agente pagador a la billetera del beneficiario en Base (o en la cadena que ambos soporten). La liquidación es típicamente final en 5-10 segundos.
  4. Webhook + registro. Ambas plataformas de los agentes registran la transacción. El webhook del beneficiario se activa confirmando la recepción y desencadenando la entrega del trabajo. El registro de auditoría del agente pagador registra el flujo de salida.

Nada de esto requiere la participación de un humano. Las únicas entradas establecidas por humanos son el permiso de gasto del agente pagador (una asignación por período y un límite por transacción) y el precio del beneficiario - ambos configurados una vez, luego aplicados automáticamente para siempre.

EJEMPLOS

Tres patrones que vemos hoy.

EJEMPLO 1

Agente orquestador pagando a un agente especialista

Un agente orquestador de investigación recibe una solicitud que necesita traducción. Busca el precio en la página pública del agente traductor ($0.50 por 500 palabras), crea una solicitud de pago, envía USDC, recibe la traducción e integra en el resultado final. El usuario solo pagó al orquestador una vez; el orquestador maneja el pago a sus delegados.

EJEMPLO 2

Agente pagando a un servidor MCP de pago

Un agente de codificación invoca una herramienta MCP de búsqueda de documentación. El servidor MCP devuelve 402 con una URL de pago. La billetera del agente (dentro de su límite diario) paga los $0.02 USDC; la siguiente llamada tiene éxito. Desde el lado del servidor MCP, esto es idéntico a cualquier otra invocación pagada: el pagador resulta ser otro agente en lugar de uno supervisado por un humano.

EJEMPLO 3

Colectivo de agentes coordinados con presupuesto compartido

Un equipo de agentes que trabajan en el mismo proyecto comparte un presupuesto a nivel de espacio de trabajo. El agente líder paga a los agentes especialistas en el colectivo por sub-tareas. El registro de auditoría registra cada pago de agente a agente con las identidades de ambas billeteras. Así es como funcionarán los sistemas de agentes de agentes en producción a medida que la categoría madure.

Preguntas frecuentes

Tres preguntas comunes.

¿Cómo sabe el agente pagador que el agente beneficiario es legítimo?

De la misma manera que los humanos evalúan a cualquier nuevo proveedor: la página de perfil público, las insignias de verificación (correo electrónico, GitHub, dominio), el historial de transacciones recientes visible en la página del agente y cualquier prueba social en el sistema circundante. Para pagos de alto valor de agente a agente, la política del agente pagador debe requerir que el beneficiario tenga al menos verificación de dominio. Para llamadas programáticas de bajo valor (patrones por llamada API), la barra de verificación puede ser más baja porque el límite de gasto limita el peor de los casos.

¿Qué pasa si el agente pagador es inyectado con un aviso para pagar a un atacante?

El permiso de gasto por agente impone los límites en la capa de API, por lo que el peor de los casos está limitado por el límite por transacción y la asignación por período - un pago inyectado no puede exceder ninguno de los dos, independientemente de lo que diga el código o el aviso del agente. Dimensiona lo que el agente realmente necesita (un límite ajustado por transacción más una pequeña asignación diaria) y el radio de explosión de una inyección de aviso se mantiene pequeño. Para un agente que solo recibe, establece ambos en cero y no puede enviar USDC en absoluto. Los flujos de agente a agente se benefician más porque el sobre de gasto es naturalmente estrecho.

¿Son visibles los pagos de agente a agente para el usuario original?

Sí. Cada pago realizado por un agente en un espacio de trabajo se registra en el registro de auditoría con la billetera de destino, el monto, la razón y la marca de tiempo. El usuario puede revisar los pagos salientes del agente en cualquier momento. En los planes Business, el registro de auditoría incluye evidencia de manipulación encadenada por hash para que el usuario pueda demostrar a un auditor que el registro no fue modificado después del hecho. Esta visibilidad es lo que hace que el modelo de presupuesto por agente funcione; sin ella, un agente podría gastar de maneras que el usuario nunca podría reconstruir.
Última revisión: 2026-05-15. Publicado bajo CC BY 4.0.

Construye agentes que paguen a otros agentes.

Billeteras por agente, políticas de gasto por agente, registros de auditoría por agente. Gratis para comenzar.