Durante mucho tiempo, la principal forma en que las personas interactuaban con la IA era a través de conversaciones. Hacíamos preguntas, recibíamos respuestas, generábamos contenido y utilizábamos los resultados para tomar decisiones por nuestra cuenta.
Esa relación está empezando a cambiar con el desarrollo de los agentes de IA.
Los agentes de IA están diseñados para hacer más que responder. Según sus capacidades y las herramientas que tengan a su disposición, pueden planificar tareas, interactuar con servicios externos, utilizar software y realizar acciones con una intervención humana limitada.
Este cambio es importante porque un sistema de IA capaz de actuar en el mundo plantea preguntas distintas a las de uno que simplemente genera texto.
Si un asistente de IA ofrece una recomendación deficiente, la gente puede ignorarla. Si un agente de IA realiza una compra, paga un servicio o ejecuta una transacción en nombre de una persona, las consecuencias ya no se limitan a una conversación.
La economía de agentes se construye en torno a esta transición. Es posible que los agentes se conviertan cada vez más tanto en consumidores como en proveedores de servicios digitales, e interactúen con otros agentes, aplicaciones y sistemas de pago.
Pero la inteligencia por sí sola no basta.
Un agente necesita poder actuar. Las demás partes necesitan formas de determinar qué es, qué puede hacer y si sus acciones son fiables.
Y ahí es donde comienza el verdadero desafío.
El problema no es solo la confianza. Es la autonomía controlada.
En el corazón de la IA autónoma hay una tensión importante.
Si se le da muy poca autoridad a un agente, se convierte en poco más que un asistente que pide permiso una y otra vez. Puede ser capaz de planificar una tarea entera y, aun así, depender de una persona para aprobar cada paso menor.
Si se le da demasiada autoridad, las consecuencias de un error se vuelven más difíciles de contener. Un agente comprometido, una instrucción mal diseñada o una decisión inesperada podrían dar lugar a acciones que el usuario nunca tuvo intención de autorizar.
Ninguno de los dos extremos resulta especialmente útil.
El objetivo no debería ser hacer que los agentes sean completamente independientes ni mantenerlos permanentemente sujetos a la aprobación humana. Debería ser darles suficiente libertad para completar una tarea y mantenerla dentro de límites claramente definidos.
En la economía digital tradicional, una persona suele iniciar un pago o aprobar una transacción. En una economía impulsada por agentes, la persona puede definir el objetivo mientras el agente decide qué acciones son necesarias para alcanzarlo.
Esto crea un nuevo requisito: la autoridad delegada debe ser limitada, comprensible y revocable.
Un agente no debería necesitar acceso ilimitado solo porque tenga que completar una tarea. Sus permisos deberían reflejar lo que el usuario pretende delegar, cuánto puede costar la tarea y durante cuánto tiempo necesita actuar de forma independiente.
Este es el problema que hace que valga la pena examinar la infraestructura para la identidad, la autorización y los pagos de los agentes.
Dónde encaja Kite AI
Kite AI está creando una infraestructura destinada a respaldar una economía en la que los agentes de IA puedan interactuar con servicios y realizar transacciones.
En lugar de tratar a los agentes únicamente como herramientas de software que operan las personas, el enfoque de Kite aborda la infraestructura necesaria para que los agentes participen en transacciones digitales. Esto incluye la identidad de los agentes, los permisos delegados y los mecanismos de pago.
La distinción es importante.
Un agente inteligente puede saber cómo completar una tarea, pero saber qué hacer no le proporciona automáticamente una forma segura o fiable de hacerlo. Aun así, necesita identificarse, obtener la autorización adecuada, interactuar con servicios y realizar pagos cuando sea necesario.
Son problemas distintos, y resolver uno no resuelve automáticamente los demás.
Kite Passport es especialmente pertinente porque, según el diseño documentado, permite que un agente pague servicios compatibles en nombre de un usuario, dentro de los límites de gasto que este apruebe. El flujo de trabajo documentado conecta la configuración de la cuenta, la financiación de la cartera, los permisos de gasto basados en sesiones y los pagos por servicios.
Aquí es donde la visión más amplia de Kite se vuelve tangible. En lugar de dar a un agente acceso financiero sin restricciones, un usuario puede autorizar un período de actividad definido con un presupuesto determinado.
La idea interesante no es simplemente que los agentes puedan realizar pagos. Es que la capacidad de un agente para efectuar transacciones puede vincularse a la autoridad que su usuario le haya concedido explícitamente.
Para entender por qué es importante, vale la pena analizar cómo está diseñado el flujo de trabajo documentado de Kite Passport.
Identidades jerárquicas: vincular los agentes con sus propietarios
Una parte importante de la infraestructura de los agentes no consiste solo en identificar a un agente, sino también en establecer su relación con la entidad que lo autoriza.
La documentación de Kite describe un modelo de identidad de tres capas: una identidad de usuario o raíz, una identidad de agente con autoridad delegada y una identidad de sesión para un período de actividad específico. Una identidad independiente de agente nos indica qué agente está interactuando con un servicio. La jerarquía añade contexto al vincular ese agente con el usuario que lo autorizó y con la sesión más limitada bajo la cual actúa.
Esto puede ser útil cuando una persona o una organización opera varios agentes, cada uno responsable de tareas distintas. En lugar de tratar a cada agente como una identidad completamente separada y con permisos sin relación entre sí, una jerarquía puede representar el vínculo entre el propietario y los agentes que actúan bajo su autoridad. La documentación de Kite también describe direcciones de agente derivadas de la cartera del usuario y claves de sesión diseñadas para tener una vigencia breve. Estos son detalles de diseño de la arquitectura documentada, no una garantía de que cualquier vulneración o error de implementación sea inocuo.
Es como distinguir quién actúa y bajo la autoridad de quién lo hace. Ambas preguntas son importantes cuando el software empieza a tomar decisiones y realizar transacciones de forma independiente.
Por ejemplo, una empresa podría operar agentes distintos para investigación, acceso a datos y compras. Cada agente puede necesitar permisos diferentes, pero su autoridad proviene, en última instancia, de la organización que lo implementó. Una estructura de identidad jerárquica puede ayudar a hacer explícitas esas relaciones, en lugar de dejarlas implícitas en la lógica de la aplicación.
Esta estructura también tiene importantes implicaciones de seguridad. Si un agente individual o una sesión se ven comprometidos, un sistema bien diseñado debería limitar los posibles daños a los permisos y recursos disponibles para ese agente o sesión. El compromiso de un agente no debería conceder automáticamente acceso sin restricciones a la autoridad subyacente del usuario ni a todos los demás agentes que operan en el mismo ecosistema.
A medida que los agentes comienzan a delegar tareas en otros agentes, mantener relaciones de identidad claras y límites en torno a la autoridad delegada se vuelve aún más importante. Sin ellos, una vulneración en un nivel podría tener consecuencias que excedieran la tarea original. El objetivo es que la autoridad sea rastreable y compartimentada, de modo que cada agente reciba solo el acceso que necesita, en lugar de heredar un control irrestricto de la identidad que está por encima de él.
Este es un objetivo de seguridad, no una garantía contra todos los fallos posibles. Su eficacia depende de la implementación, de la seguridad de las claves subyacentes y de que los controles pertinentes se apliquen correctamente.
En última instancia, la identidad jerárquica no consiste solo en organizar varios agentes. Se trata de preservar una relación clara entre el agente que realiza una acción, la autoridad bajo la que actúa y los límites de esa autoridad. A medida que los sistemas autónomos se interconecten más, esa separación podría convertirse en una base importante para que las interacciones impulsadas por agentes sean más seguras y fáciles de gestionar.
Kite Passport: de la configuración a los pagos autónomos
Kite Passport está diseñado para permitir que un agente de IA pague servicios compatibles en nombre de un usuario, sin que este tenga que aprobar manualmente cada transacción. Primero, el usuario configura Passport, añade fondos a su cartera y aprueba una sesión de gasto. Después, el agente puede encontrar servicios, realizar pagos y recibir los resultados dentro de los límites de la sesión.
El flujo de trabajo es importante porque separa tres cosas que a menudo se confunden: dar a un agente acceso a un sistema de pago, proporcionarle fondos y autorizarlo a gastar esos fondos.
No son el mismo permiso.
1. Instalar Passport y conectar un agente
El proceso documentado comienza con la interfaz de línea de comandos de Kite Passport, o CLI, y las habilidades de agente que permiten a un agente de IA compatible interactuar con Passport.
La documentación de Kite abarca tanto agentes de programación que se ejecutan en el ordenador del usuario como agentes en la nube que operan en equipos alojados. El método de instalación varía, pero el proceso de inicio de sesión en la cuenta sigue, en general, el mismo patrón.
En las configuraciones compatibles de agentes de programación, como Claude Desktop o Codex, el proceso documentado consiste en ejecutar el comando de instalación de Passport desde el entorno de desarrollo del agente y seguir las instrucciones de configuración para registrarse en Passport y configurar las habilidades correspondientes.
Para las configuraciones compatibles de agentes en la nube, el usuario sigue las instrucciones de configuración correspondientes para conectar el agente alojado a Passport.
Tras la instalación y el registro, el usuario recibe dos correos electrónicos: un enlace de verificación que abre el panel de Passport y un código de ocho caracteres que debe proporcionarle al agente. El usuario abre el enlace de verificación, crea una clave de acceso con un método compatible, como Touch ID, Face ID, Windows Hello o una clave de seguridad física, y luego proporciona el código para completar el inicio de sesión.
La clave de acceso es una parte importante de este proceso porque se supone que la aprobación de una sesión de gasto no debe ser una decisión sin restricciones que el agente tome en silencio. Antes de que el agente reciba la autoridad de gasto solicitada, el usuario debe aprobarla explícitamente.
También hay una consideración práctica importante al utilizar un agente alojado: conectarlo a Passport le concede acceso a la cuenta Passport del usuario. La documentación de Kite aconseja específicamente revisar los límites de la sesión antes de aprobarla. La comodidad no debería significar confiar ciegamente en los permisos que solicite un agente.
Una vez conectadas la cuenta y el agente, el siguiente requisito es añadir fondos.
2. Añadir fondos a la cartera de Passport
Passport necesita fondos antes de que un agente pueda realizar solicitudes de pago. Según la documentación de Kite, el flujo de pago por servicios utiliza USDC.e en Kite Chain.
El panel ofrece varias formas de añadir fondos, según la situación inicial del usuario.
Comprar con tarjeta: Los usuarios que no tengan criptomonedas pueden comprar USDC en Base desde la sección «Añadir fondos» del panel de Passport. Eligen una cantidad y un método de pago, completan la compra y esperan a que se actualice el saldo una vez liquidada la transacción.
Depositar monedas estables: Los usuarios que ya tengan monedas estables compatibles pueden acceder a la dirección de depósito correspondiente desde la pestaña Crypto. La documentación enumera opciones de depósito compatibles en varias redes y activos, incluidos USDC en Base, Polygon, Avalanche, Tempo, Solana, Arc y otras opciones mencionadas. Los usuarios deben enviar la moneda estable correcta a la dirección asociada con su red. Enviar el activo equivocado o utilizar una red incorrecta puede impedir que los fondos aparezcan como se esperaba.
Usar Kite Bridge: Los usuarios también pueden transferir USDC a Kite Chain mediante Kite Bridge. Conectan la cartera que contiene sus fondos, seleccionan la cadena de origen y el token, eligen Kite como destino e indican la dirección de su cartera Passport como destinatario. Tras confirmar las transacciones y esperar a que finalice el puente, el saldo de Passport debería actualizarse.
Transferir desde una cartera que ya está en Kite: Si el usuario ya tiene USDC.e en Kite Chain, puede enviarlo directamente desde una cartera externa a la dirección de la cartera Passport. La documentación de Kite indica que la cartera externa necesita $KITE tokens para pagar la comisión de gas de esta transferencia.
El usuario puede consultar el saldo resultante en el panel o mediante el comando kpass wallet balance. También puede pedirle al agente que consulte el saldo.
Estas opciones ofrecen distintas formas de preparar la cartera, pero añadir fondos no significa automáticamente que el agente tenga permiso ilimitado para gastar el saldo.
Esta distinción es fundamental para el modelo de Passport. La cartera contiene los fondos; la sesión de gasto define la autoridad que recibe el agente para utilizarlos.
3. Crear una sesión de gasto
Podría decirse que este es el paso más importante de todo el flujo de trabajo.
Una vez que la cartera tiene fondos, el agente puede solicitar una sesión de gasto. En lugar de pedir simplemente acceso general a la cartera, la sesión especifica la tarea y los límites dentro de los cuales el agente puede gastar.
Los parámetros de sesión documentados por Kite incluyen:
Resumen de la tarea: Una descripción de lo que intenta lograr el agente.
Importe máximo por transacción: El límite superior para un pago individual.
Importe total máximo: El presupuesto total disponible durante la sesión.
Tiempo de vida (TTL): Cuánto tiempo permanece válida la sesión.
Activos aprobados: Los activos que puede utilizar la sesión.
Por ejemplo, imaginemos un agente que necesita realizar una única solicitud de pago a una API meteorológica. Un usuario podría autorizar una sesión con un máximo de 2 $ por transacción, un presupuesto total de 10 $ y una vigencia de 24 horas.
El agente solicita la sesión y recibe una URL de aprobación. El usuario abre esa URL en un dispositivo donde esté disponible su clave de acceso y aprueba la solicitud explícitamente.
La sesión solo se activa después de esa aprobación.
La distinción entre el límite por transacción y el presupuesto total es especialmente útil. El máximo por transacción limita el importe de cada pago individual, mientras que el presupuesto total limita el gasto acumulado durante la sesión. El período de vencimiento añade un límite temporal e impide que la sesión siga siendo válida indefinidamente.
Una vez aprobada, la sesión permite que el agente realice pagos admisibles dentro de sus límites sin solicitar una nueva aprobación para cada pago individual. La sesión vence cuando se alcanza su límite de tiempo o se agota su presupuesto.
Este es el equilibrio fundamental que Passport intenta gestionar: el usuario mantiene el control sobre el alcance de la autorización y, al mismo tiempo, el agente obtiene suficiente independencia para llevar a cabo la tarea.
Sin esta separación, la autonomía podría significar conceder a un agente un amplio acceso financiero. Con los permisos basados en sesiones, la intención es otorgar solo la autoridad necesaria para un período de trabajo concreto.
Por supuesto, un sistema de permisos solo es tan útil como su implementación. El usuario debe entender qué está aprobando y el sistema debe aplicar los límites correctamente. Una sesión no garantiza que el agente elija el servicio adecuado ni que tome la decisión correcta. Es una forma de restringir las acciones que está autorizado a realizar.
4. Buscar servicios y realizar pagos
Con la cartera financiada y la sesión de gasto aprobada, el agente puede buscar un servicio de pago adecuado en el catálogo de Kite.
La CLI documentada permite descubrir servicios mediante el comando ksearch. El usuario también puede pedirle a un agente compatible que busque servicios disponibles que se ajusten a una tarea, como encontrar una API meteorológica.
Una vez que identifica un servicio adecuado, el agente puede enviar una solicitud de pago mediante el flujo de pago compatible.
Uno de los mecanismos documentados por Kite es x402, un protocolo de pago basado en la respuesta HTTP 402 Payment Required. La idea básica es que un servicio puede indicar que una solicitud requiere un pago y proporcionar las condiciones necesarias para continuar.
La interacción puede entenderse como una secuencia:
El agente solicita un recurso a un servicio.
Si se requiere un pago, el servicio devuelve un desafío de pago que describe las condiciones.
El agente de Passport obtiene autorización de pago dentro de la sesión de gasto aprobada por el usuario.
El agente vuelve a enviar la solicitud con la información de pago necesaria.
El servicio verifica y liquida el pago mediante la infraestructura de pago compatible.
Una vez confirmado el pago, el servicio devuelve el recurso o la respuesta solicitados.
A continuación, el agente puede utilizar esa respuesta como parte de la tarea más amplia que está realizando.
Esto es importante porque el pago puede convertirse en parte de la propia interacción del software. No necesariamente hace falta que el agente se detenga, envíe al usuario a una página de pago convencional y espere a que este complete manualmente cada pequeña compra.
El servicio define sus requisitos de pago, Passport aplica la autoridad de gasto aprobada por el usuario y el servicio entrega el recurso una vez procesado el pago.
La documentación de Kite para proveedores de servicios también describe la compatibilidad con el Machine Payments Protocol, o MPP, como otra vía para que los servicios acepten pagos de agentes de Passport. Los detalles varían según el protocolo, pero el objetivo general es similar: permitir que los servicios especifiquen requisitos de pago de una forma que los agentes de software puedan gestionar.
Passport también documenta la compatibilidad con transferencias directas de USDC iniciadas por un agente dentro de los límites de la sesión aprobada. Esto es distinto de pagar un servicio mediante una solicitud basada en un protocolo, aunque ambos métodos dependen de los permisos concedidos al agente.
Conviene ser precisos sobre lo que esto significa y lo que no. No todos los sitios web o API pasan automáticamente a ser accesibles para los agentes de Passport. Un servicio debe admitir un flujo de pago compatible y el agente debe interactuar con él correctamente. El sistema proporciona una forma de conectar autorización y pago; no elimina la necesidad de integrar los servicios.
5. Supervisar la actividad y mantener el control
La autonomía no debería significar perder visibilidad.
Una vez que el agente empieza a gastar, los usuarios pueden revisar los pagos completados y la actividad de las sesiones desde el panel de Passport. La CLI también incluye comandos para enumerar las sesiones activas y consultar la actividad reciente.
Esto es importante porque la autoridad delegada debería seguir siendo comprensible después de concederse. Los usuarios deben poder inspeccionar qué han hecho sus agentes, cuánto han gastado y si una sesión sigue activa.
El presupuesto y el vencimiento de una sesión establecen límites por adelantado. Los registros de actividad ofrecen visibilidad después. Ambos son importantes, pero cumplen funciones distintas.
Los límites de gasto restringen lo que puede hacer el agente. El historial de actividad ayuda al usuario a entender lo que hizo realmente.
Ninguno de los dos garantiza que todas las transacciones hayan sido acertadas ni que todos los servicios sean legítimos. La supervisión no sustituye a la seguridad, y el registro de una transacción no demuestra por sí solo que el software subyacente haya funcionado correctamente.
Aun así, esta combinación es más útil que limitarse a darle una cartera al agente y esperar que se comporte como se espera.
El principio general es que la autonomía delegada requiere tanto límites como visibilidad. Los usuarios no deberían tener que elegir entre aprobar cada pequeña acción y renunciar a un control significativo del proceso.
6. Revocación: un control que conviene verificar
Delegar autoridad es solo la mitad de la ecuación. Un modelo de permisos sólido también debería explicar cómo puede un usuario retirar la autoridad si cambian las circunstancias. La tarea puede haberse completado, quizá ya no se necesite al agente o su comportamiento puede darle al usuario motivos para detenerlo.
En la autorización de agentes, revocar significa invalidar la autoridad concedida previamente, en lugar de esperar a que venza de forma natural. Las sesiones limitadas en el tiempo ofrecen un límite automático, pero quizá no sea lo bastante inmediato si el usuario quiere detener una tarea antes de tiempo.
Un límite presupuestario y un mecanismo de revocación resuelven problemas distintos. El presupuesto limita el gasto potencial; la revocación determina si se debería permitir que el agente siguiera actuando. Ambas son cuestiones importantes al evaluar la autonomía delegada.
En última instancia, el control efectivo exige más que establecer límites al principio. Los usuarios necesitan información clara tanto sobre los controles existentes como sobre los que aún deben verificarse.
Es más fácil confiar en la autonomía cuando el alcance de la autoridad delegada está claro, tiene un plazo definido y, cuando sea posible, puede retirarse.
Qué cambia realmente con este flujo de trabajo
En conjunto, el flujo de trabajo de Passport crea un camino definido desde la autorización del usuario hasta el pago gestionado por un agente.
El usuario conecta un agente, añade fondos a una cartera, aprueba una sesión con parámetros de gasto explícitos y deja que el agente interactúe con servicios de pago compatibles. Después, el usuario puede revisar la actividad resultante.
Este es un enfoque más concreto de la autonomía de los agentes que simplemente dar acceso a un método de pago a un sistema de IA.
También deja claro dónde siguen existiendo preguntas difíciles. ¿Qué tan fácil es para los usuarios entender los permisos que están aprobando? ¿Con qué fiabilidad se aplican esos límites? ¿Qué ocurre cuando un agente toma una mala decisión dentro del presupuesto autorizado? ¿Qué tan seguros son el entorno del agente, la cartera y el servicio que recibe el pago?
Passport aborda parte del problema de la autorización y los pagos, pero no puede eliminar todos los riesgos asociados al software autónomo.
Eso no es motivo para descartar el enfoque. Es una razón para evaluarlo en función de lo que realmente ofrece.
La otra mitad: los servicios deben aceptar pagos de agentes
Hay otro aspecto de este sistema que es fácil pasar por alto.
Un agente puede tener una cartera, una identidad y permisos de gasto aprobados, pero sigue necesitando un lugar donde gastar sus fondos. Para que la economía de agentes funcione, los proveedores de servicios deben poder aceptar pagos tanto de agentes como de personas.
Por eso la documentación de Kite para proveedores de servicios es pertinente para el panorama general.
Kite describe dos vías de integración de pagos para los proveedores: x402 y MPP. Con x402, un proveedor puede devolver una respuesta HTTP 402 Payment Required que contiene las condiciones de pago. A continuación, el agente de Passport obtiene la autorización correspondiente de la sesión aprobada por el usuario y vuelve a enviar la solicitud con la información de pago. Antes de prestar el servicio, el proveedor verifica y liquida el pago mediante un facilitador compatible.
MPP sigue un patrón general similar: solicitar un recurso, presentar las condiciones de pago, recibir las credenciales de pago, verificar el pago y entregar el recurso. Sin embargo, admite distintos mecanismos de pago y patrones de interacción.
Lo importante es que el sistema no solo ayuda a los agentes a gastar dinero. También hace que los servicios sean accesibles para ellos mediante flujos de pago diseñados para el software.
Imaginemos a un desarrollador que ofrece acceso a una API especializada. Si un agente puede encontrar el servicio, entender sus requisitos de pago, obtener autorización dentro del presupuesto de su usuario y recibir la respuesta de la API después del pago, el desarrollador dispone de una posible vía para atender a clientes automatizados sin tener que crear una experiencia de pago manual completamente distinta.
Eso no garantiza que haya demanda ni hace que la integración sea sencilla. Los proveedores aún deben implementar el protocolo correspondiente, configurar su infraestructura de pago y asegurarse de que su servicio gestione las solicitudes de forma segura. Los agentes también necesitan una forma fiable de encontrar e interpretar el servicio.
Pero esta estructura bilateral es importante. Un sistema de pago para agentes se vuelve más útil a medida que más servicios pertinentes aceptan pagos, y los servicios tienen más motivos para admitir pagos de agentes cuando hay agentes útiles y clientes dispuestos a utilizarlos.
En otras palabras, la infraestructura debe conectar ambos lados de la transacción.
Por qué son importantes los pagos para la economía de agentes
La autonomía se vuelve más útil cuando los agentes pueden pagar por los recursos que necesitan.
Un agente podría necesitar acceso a una API, una fuente de datos, un servicio de computación o las capacidades de otro agente. Si cada interacción requiere que una persona negocie y complete manualmente el pago, la automatización puede volverse engorrosa rápidamente.
Esta es una de las razones por las que la infraestructura de pagos es pertinente para la emergente economía de agentes.
Las monedas estables son útiles en estos contextos porque están diseñadas para seguir el valor de una moneda de referencia, lo que facilita calcular los importes de las transacciones en comparación con activos cuyos precios fluctúan considerablemente. En el flujo de pago documentado de Kite Passport, el activo requerido para la cartera financiada de Passport es USDC.e en Kite Chain.
La posible ventaja no es que toda interacción de IA necesite un pago. La mayoría no lo necesita. La ventaja es que, cuando un agente realmente necesita comprar un recurso, el pago puede integrarse en su flujo de trabajo en lugar de convertirse en una interrupción manual.
Pero que una transacción funcione técnicamente no significa que sea útil. Las comisiones de red, los precios de los servicios, las solicitudes fallidas, los riesgos de seguridad y la complejidad de la autorización influyen en que los pagos automatizados tengan sentido en la práctica.
La economía de agentes necesita algo más que la capacidad de transferir dinero. Necesita sistemas de pago como Kite Passport, que sean prácticos para el software y lo bastante seguros como para que las personas deleguen en ellos.
Un marco útil para evaluar la infraestructura de agentes
Al analizar proyectos que están creando infraestructura para una economía de agentes, creo que cinco preguntas son más útiles que limitarse a preguntar si un proyecto es compatible con agentes de IA.
1. Pagos nativos de monedas estables
¿Pueden los agentes pagar servicios utilizando activos y mecanismos de pago adecuados para las transacciones digitales? Lo importante es si el flujo de pago resulta útil en la práctica, no simplemente si existe un token o una cartera.
2. Permisos programables
¿Pueden los usuarios definir la autoridad que recibe un agente? Los límites de gasto, las acciones restringidas y los permisos sujetos a un plazo pueden ayudar a garantizar que el acceso delegado sea proporcional a la tarea.
3. Autenticación diseñada primero para agentes
¿Puede un agente identificarse e interactuar con un servicio mediante un proceso diseñado para software, respetando al mismo tiempo la autorización que le concede su propietario?
4. Actividad auditable
¿Pueden los usuarios inspeccionar las acciones y transacciones pertinentes? La visibilidad es importante cuando un agente actúa en nombre de alguien, aunque un historial de transacciones por sí solo no puede demostrar que todas las decisiones fueran correctas ni que todos los procesos subyacentes fueran seguros.
5. Transacciones económicamente viables
¿Puede el sistema admitir transacciones con un coste y una velocidad adecuados para los servicios involucrados? Si los pagos pequeños son demasiado caros o difíciles de ejecutar, muchos casos de uso potenciales podrían seguir siendo poco prácticos.
En conjunto, estas preguntas ofrecen una forma útil de evaluar la infraestructura para agentes autónomos. También ponen de relieve por qué no se debe confundir una sola función con una solución completa.
Una cartera no resuelve la autorización. Un sistema de identidad no garantiza buenas decisiones. Un registro de auditoría no elimina las vulnerabilidades de seguridad. Y un protocolo de pago no crea automáticamente una demanda sostenible.
Los sistemas más sólidos necesitan que estos componentes funcionen en conjunto. Kite presenta su enfoque mediante un marco relacionado llamado SPACE: pagos nativos de monedas estables, restricciones programables, autenticación diseñada primero para agentes, infraestructura preparada para el cumplimiento normativo y micropagos económicamente viables. Este marco expresa de forma útil lo que el proyecto pretende respaldar, pero no debe tomarse como prueba de que ya se ha resuelto cada desafío de estas categorías. La prueba práctica consiste en ver cómo funcionan estos elementos en conjunto en implementaciones reales.
¿Qué podría permitir esto?
Si la identidad, los permisos y los pagos de los agentes llegan a ser lo bastante fiables, varios tipos de interacciones podrían automatizarse con mayor facilidad.
Los agentes podrían comprar acceso a API o datos, pagar recursos de computación y coordinarse con agentes especializados que presten servicios que ellos mismos no pueden realizar. Las empresas también podrían implementar agentes que completen partes de un flujo de trabajo en varios servicios sin necesidad de que una persona apruebe cada interacción individual.
Estas son direcciones plausibles para una economía de agentes, no una prueba de que todos los casos de uso ya funcionen a gran escala.
Su éxito dependerá de algo más que la disponibilidad de infraestructura. Los desarrolladores deben crear servicios útiles, los usuarios necesitan motivos para delegar tareas y las empresas deben confiar en los sistemas que gestionan sus recursos.
La tecnología puede reducir las fricciones, pero no puede generar demanda por sí sola.
El papel del token KITE
Kite también tiene un token nativo, $KITE , que debe considerarse por separado de las monedas estables utilizadas para pagar servicios con Passport. En el flujo de financiación documentado, se usa USDC.e para los pagos de agentes en Kite Chain, mientras que $KITE se necesita para pagar el gas al transferir fondos desde una cartera externa que ya está en Kite Chain.
Ese papel documentado en el pago de gas no debe confundirse con una descripción completa de la utilidad más amplia del token. Cualquier función adicional debe evaluarse según la documentación actual del proyecto, distinguiendo las funciones que ya están activas de las que están previstas. La utilidad del token no debe deducirse únicamente de la visión general.
La verdadera prueba es si podemos delegar de forma segura
La promesa de los agentes de IA es fácil de entender. Podrían hacerse cargo de una mayor parte del trabajo entre decidir qué queremos y lograrlo efectivamente.
Pero cuanto más autoridad les damos, más importante se vuelve decidir dónde termina esa autoridad.
Considero que este es uno de los desafíos centrales de la economía de agentes. Los desarrolladores no solo intentan crear sistemas capaces de actuar de forma independiente. Intentan crear sistemas en los que las personas puedan confiar razonablemente para que actúen en su nombre.
El enfoque de Kite en la identidad de los agentes, los permisos delegados y la infraestructura de pagos aborda algunos aspectos de ese desafío. Passport concreta especialmente esta idea al vincular los límites de gasto de un usuario con las acciones que un agente puede realizar durante una sesión aprobada. Su importancia a largo plazo dependerá de la fiabilidad de estos controles, de la facilidad con que los servicios se integren con los flujos de pago y de si los usuarios consideran la experiencia lo bastante útil como para adoptarla.
Siguen existiendo preguntas sin resolver sobre seguridad, rendición de cuentas, facilidad de uso y adopción. No deberían ignorarse solo porque la tecnología sea prometedora. Precisamente esas cuestiones determinarán si la promesa resulta útil en la práctica.
Un agente capaz de ejecutar una tarea es útil. Un agente que puede ejecutarla dentro de límites claramente definidos es más útil. Y es más fácil confiar en un agente cuyas acciones pueden entenderse, supervisarse y detenerse mediante controles que realmente funcionan. Esa es la dirección general hacia la que trabaja Kite, aunque la verdadera prueba será cómo funcionan estos controles en la práctica.
El futuro de la IA autónoma no debería medirse por cuánta libertad damos a los agentes, sino por la inteligencia con la que definimos la libertad que necesitan.