No dejaba de volver a un detalle de Kite Passport: un servicio puede solicitar el pago antes de devolver una respuesta.
El proceso parece sencillo. Un agente solicita un servicio, recibe las condiciones de pago, paga y obtiene el resultado. Pero la pregunta más interesante surge antes de la transacción: ¿quién autorizó al agente a gastar y cuánta autoridad tiene realmente?
Un usuario puede cargar fondos en la billetera de un agente y aprobar una sesión de gasto con límites definidos, incluidos un presupuesto, un límite por transacción y un plazo de vencimiento. Luego, el agente puede pagar por servicios compatibles dentro de esos límites, sin pedir una nueva aprobación humana para cada solicitud.
Eso resuelve un problema. No resuelve el siguiente.
Imagina un agente que investiga un mercado. Compra un conjunto de datos, paga a otro servicio para que lo procese y envía el resultado a un agente especializado. Cada proveedor cobra por su contribución, y el agente que inicia el proceso combina los resultados para crear algo útil.
Este es el tipo de flujo de trabajo que podría hacer viable una economía de agentes: software que compra servicios de otro software, con pagos asociados a tareas individuales, en lugar de que cada interacción dependa de un proceso de pago gestionado por una persona.
La separación que hace Kite entre las identidades del usuario, del agente y de la sesión ayuda a definir quién tiene autoridad en cada nivel. El usuario sigue siendo la autoridad principal, el agente recibe permisos delegados y una sesión utiliza una autoridad limitada para una operación concreta. Estos límites restringen lo que un agente tiene permitido hacer; no garantizan que sus decisiones sean acertadas.
La mecánica de los pagos también importa. El enfoque de Kite para los canales de micropagos permite realizar múltiples actualizaciones de pago firmadas fuera de la cadena entre las transacciones en la cadena que abren y cierran el canal. Esto puede hacer que los pagos repetidos de bajo valor sean más prácticos que liquidar cada actualización por separado en la cadena. No elimina todos los costos ni garantiza que todos los servicios sean económicamente convenientes.
Ahora considera qué ocurre después de la tarea de investigación de mercado.
El agente paga a un proveedor de datos y recibe una respuesta. El pago fue autorizado. El proveedor entregó los datos solicitados. Sin embargo, resulta que el conjunto de datos está demasiado desactualizado para respaldar la decisión.
La transacción se completó. La tarea, no.
Aquí es donde creo que la economía de agentes tiene un problema más profundo que la infraestructura de pagos por sí sola no puede resolver.
Si un agente compra servicios repetidamente, necesita alguna forma de distinguir a los proveedores que simplemente entregan respuestas de los que ofrecen resultados útiles de manera sistemática. Un historial de resultados satisfactorios podría influir en futuras decisiones de compra. Los fracasos repetidos podrían llevar a un agente a evitar a un proveedor, incluso cuando este siga siendo técnicamente accesible y sus pagos funcionen a la perfección.
Esto plantea una nueva cuestión económica: ¿cómo debería influir la calidad del servicio en lo que un agente está dispuesto a pagar?
Un proveedor barato con resultados inconsistentes puede acabar costando más si sus fallos obligan al agente a repetir el trabajo. Puede ser preferible un proveedor más caro si sus resultados permiten completar la tarea de forma fiable. Para medir esa diferencia se necesitan pruebas sobre los resultados, no solo registros de pagos.
Kite puede proporcionar infraestructura para la identidad, la autoridad delegada y los pagos entre máquinas. Estos mecanismos ayudan a los agentes a realizar transacciones dentro de límites definidos. La reputación fiable, la resolución justa de disputas y las garantías de servicio significativas siguen siendo problemas distintos que la economía de agentes en general debe abordar.
La distinción a la que siempre vuelvo es sencilla: un registro de pagos le indica a un agente qué ocurrió desde el punto de vista financiero. No necesariamente le dice si valió la pena repetir la transacción.
Cuando los agentes se conviertan tanto en compradores como en vendedores, ¿deberían sus precios futuros y sus decisiones de compra depender de entregas verificadas, del éxito medible de las tareas o de un historial más prolongado de resultados fiables? ¿Y quién debería decidir qué cuenta como éxito cuando tanto el comprador como el vendedor son sistemas autónomos?
