Los agentes de IA onchain son sistemas de software que convierten una instrucción en una acción de blockchain al combinar razonamiento offchain con cuentas, contratos, pagos y recibos onchain. En la mayoría de los diseños, el propio modelo se ejecuta offchain. Lo que hace que el agente sea "onchain" es su capacidad para leer un estado verificable o solicitar un cambio de estado a través de una wallet que opera bajo reglas definidas.

La versión útil no es un chatbot que tenga una clave privada sin restricciones. Los datos tienen marca de tiempo, la transacción propuesta se simula, la política decide si puede avanzar y el recibo se compara con la instrucción original. Esa distinción importa más que la presencia de una moneda de agente de IA en cualquier parte de la pila, porque la pregunta práctica siempre es qué capa puede observar, autorizar y verificar la acción.

¿Qué son los agentes de IA onchain?

Un agente de IA conectado a onchain puede leer el estado de la blockchain, comparar opciones o preparar una transacción sin firmar. Solo se vuelve autónomo cuando puede firmar y enviar una acción específica dentro de los límites que el usuario autorizó por adelantado. Ambos diseños combinan razonamiento, herramientas, una cuenta y monitoreo de resultados, pero preparar calldata es asistencia, mientras que ejercer poder de firma delegado es ejecución autónoma.

Un agente onchain no debe confundirse con cada proyecto del sector más amplio de infraestructura de IA cripto. Las redes de cómputo venden capacidad de procesamiento, las plataformas de agentes coordinan software y las smart accounts hacen cumplir la autoridad. Estas capas pueden combinarse, pero ninguna se vuelve autónoma solo porque exista un token o un contrato. Un bot basado en reglas repite condiciones preestablecidas y puede enviar transacciones, pero no interpreta un objetivo más amplio; un agente de IA onchain autónomo elige herramientas y acciones según el contexto, y luego firma solo dentro de límites delegados. Una smart account no toma decisiones propias: hace cumplir propietarios, límites, módulos, aprobaciones y reglas de recuperación. Una red de pagos x402 transporta y liquida una autorización firmada de pago máquina sin decidir si la compra es útil.

La identidad es distinta del saldo de una wallet o del nombre de un agente. Un sistema de producción debe vincular al agente, al operador, a la versión del software, a la wallet, a los endpoints del servicio y al propietario de revocación. La visión general de Ethereum sobre identidad y validación de agentes muestra cómo los registros apoyan el descubrimiento y la reputación, pero registrarse no prueba que una salida sea correcta. Ese límite importa en sistemas DeFAI, donde una recomendación puede convertirse en un swap, un depósito, un puente o un rebalanceo, por lo que los usuarios necesitan ver qué capa propuso la acción y qué capa permitió mover los fondos.

Cómo funcionan los agentes de IA onchain

Considere una instrucción para comprar 50 USDC de ETH en Base solo cuando el impacto en el precio se mantenga por debajo de 0.5%. Un WebSocket activa el flujo cuando cambia el pool, y el agente lee saldo, cotización, liquidez, gas y tiempo de bloque. La entrada obsoleta o incompleta detiene la ejecución antes de construir una transacción.

El modelo compara rutas sin recibir la autoridad final. La simulación estima cambios de saldo; la política revisa la cadena, los tokens, el contrato, el gasto, el slippage, el plazo y el método. La wallet reserva el siguiente nonce a través de una cola antes de firmar. Después de la liquidación, el monitoreo confirma el gasto, la salida mínima de ETH, el contrato llamado y las aprobaciones restantes. Una ruta cambiada, una llamada revertida o una salida deficiente generan una alerta en lugar de un reintento silencioso.

La secuencia completa es visible para el usuario en lugar de quedar oculta detrás de un solo mensaje de confirmación:

• Leer: Capturar el disparador del WebSocket, la cotización, el saldo, la liquidez y la marca de tiempo del bloque. La entrada faltante o obsoleta detiene la solicitud.
• Decidir: Seleccionar un pool y una salida mínima de ETH. Un impacto de precio esperado superior a 0.5% rechaza la ruta.
• Simular: Decodificar la llamada y proyectar cambios de saldo. Un revert, una aprobación oculta o una ruta cambiada bloquean la firma.
• Aplicar política: Verificar Base, el contrato aprobado, el límite de 50 USDC y la fecha límite frente al mandato original.
• Firmar y liquidar: Reservar el nonce y usar una firma acotada. Un conflicto, una sesión expirada o la negativa del firmante detienen el envío.
• Verificar: Comparar el recibo con la solicitud. El activo, el contrato, el monto o la salida incorrectos generan una alerta.

Qué pueden hacer hoy los agentes de IA onchain

En DeFi, un agente puede vigilar una posición de préstamo, comparar el rendimiento neto después de costos y rebalancear entre mercados aprobados. Los usuarios deben ver el bloque de origen, los contratos, el cambio esperado de saldo, la decisión de política y el recibo.

Para pagos máquina, un agente puede solicitar una API o una tarea de cómputo, recibir términos x402, autorizar USDC limitado y reintentar con prueba de pago. Una autorización debe producir un resultado entregado o un reembolso trazable, nunca un cobro duplicado. Los agentes también pueden descubrir un proveedor, verificar su identidad, comprar una tarea y registrar el resultado devuelto. La identidad y el pago vuelven trazable el intercambio, pero aún se requiere evidencia de finalización y un propietario de recuperación.

Cinco sistemas que otorgan capacidades reales a los agentes onchain

Estos cinco ejemplos no son cinco agentes intercambiables. Cubren descubrimiento, servicios autónomos, herramientas de transacción, control de cuentas y pagos máquina. Leídos en conjunto, muestran por qué las plataformas de agentes deben evaluarse como pilas y no por una sola pantalla de demostración.

Fetch.ai Agentverse: descubrimiento de agentes

La Agentverse de Fetch.ai ayuda a usuarios y agentes a descubrir servicios, enviar solicitudes estructuradas y recibir respuestas. El registro o el pago pueden tocar una cadena mientras la lógica del servicio y los datos permanecen offchain. Una revisión debe registrar qué agente respondió, su origen, el tiempo de respuesta y la evidencia de finalización.

Un tester beta de DeltaV en julio de 2024 pasó entre una y dos horas en cinco prompts y no recibió resultados de cargadores EV cercanos a pesar de reportar unos 15 cargadores. Esa prueba específica de DeltaV es antigua y anecdótica, no una medida de fiabilidad de 2026. Aun así, identifica verificaciones útiles: tiempo de respuesta, finalización de la tarea, dependencia de la fuente y si el servicio resolvió la solicitud.

Olas: coordinación de servicios autónomos

Olas coordina servicios autónomos persistentes mediante componentes registrados, operadores y cuentas Safe. Los revisores deben vincular cada ID de servicio y operador con su Agent Safe y con el propietario, o Master Safe, capaz de recuperar el control.

Un revisor que usó una wallet Pearl siguió sus interacciones de contrato en GnosisScan en lugar de confiar solo en el panel de la aplicación. Ese recorrido de la wallet Pearl, consultado el 19 de agosto de 2026, es una prueba limitada de publicación, no un benchmark de disponibilidad ni de soporte. Aun así, ofrece al operador una verificación reproducible de propiedad: copiar la dirección del Agent Safe desde Pearl, hacer coincidir cada transacción del registro y del servicio en el explorador, e identificar el Master Safe que puede recuperar el control antes de depositar más fondos. Esto importa porque la remediación del registro de Olas en junio de 2026 reforzó específicamente el vínculo entre un servicio y su multisig.

Coinbase AgentKit: acciones de wallet

Coinbase AgentKit ofrece consultas de saldo, transferencias y llamadas a contratos para software conectado a wallets. Conecta llamadas de herramientas con transacciones, pero no decide si una ruta es sensata. Las aplicaciones deben restringir herramientas, alcance de la cuenta, cadena, activo, monto, método y duración de la sesión.

Un desarrollador que conectó AgentKit con x402 descubrió que las bibliotecas que asumían una cuenta de propiedad externa podían fallar en silencio porque AgentKit usaba una smart account. Además, un reintento terminó pagando dos veces antes de que se confirmara la primera transacción. Este informe de integración de dos semanas no es un benchmark de toda la plataforma, pero produce dos verificaciones de lanzamiento: detectar el tipo de cuenta y hacer que los reintentos pagados sean idempotentes.

Safe: permisos de smart account

Safe separa las propuestas del modelo de la autoridad sobre los activos mediante propietarios, umbrales, módulos y guards. Deben revisarse cada propietario, módulo, regla de gasto, ruta de actualización y mecanismo de recuperación, porque un módulo demasiado poderoso o una interfaz ilegible pueden debilitar un umbral sólido.

Un miembro de la comunidad Safe que probó la verificación entre dispositivos encontró que los hashes y los detalles decodificados debían compararse en superficies separadas. Pruebas posteriores mostraron que una interfaz de tiempo de espera que desaparecía podía crear urgencia falsa. Estos experimentos de aprobación de Safe son observaciones individuales, pero respaldan decodificar y confirmar acciones de alto valor en un dispositivo que no creó la propuesta.

x402: pagos máquina

x402 permite que el software solicite un recurso, reciba términos de pago, firme una autorización, reintente y obtenga el recurso después de la liquidación. Cubre solo la capa de pago del panorama más amplio de protocolos de pago para agentes de IA.

Después de seis semanas usando x402 para monetizar un servidor MCP, un operador lo retiró a pesar de considerar elegante el intercambio de pago. El relato de primera mano en producción describe reintentos de pago, precios por herramienta, límites de tasa de wallet, reembolsos tras trabajos fallidos, fallos silenciosos de webhooks y un requisito separado para clientes que pagan en dólares en lugar de USDC. Una sola implementación no puede establecer fiabilidad a nivel de protocolo, pero muestra qué debe cubrir una prueba de lanzamiento: repetir una solicitud después de la liquidación, hacer fallar deliberadamente el trabajo pagado y verificar que una autorización produzca una respuesta entregada o un reembolso trazable, nunca un segundo cobro.

Niveles de permiso de los agentes de IA onchain

La capacidad de investigación y la autoridad financiera deben evaluarse por separado. Pasar de acceso de solo lectura a firma abierta crea nuevas rutas de pérdida y requiere un propietario de control más fuerte. Una revisión de 2026 de 317 estudios relevantes también separó analítica de solo lectura, generación de intención, ejecución delegada, firma autónoma y flujos de trabajo multiagente, comparando custodia, política, observabilidad y recuperación.

El objetivo más seguro para producción suele ser la ejecución acotada. Mantiene exigibles fuera del modelo el activo, el destino, el monto, el método y la expiración. Un prompt puede malinterpretarse; la política de la cuenta puede impedir que la llamada inválida se firme.

Riesgos de seguridad de los agentes de IA onchain

Los fallos suelen ocurrir en los traspasos: los datos quedan obsoletos antes de firmar, el calldata cambia después de la simulación o el pago se liquida mientras se pierde la respuesta de la API. Una wallet también puede hacer cumplir un límite y aun así llamar a un método en allowlist con parámetros no deseados.

• Entrada obsoleta o manipulada puede producir una recomendación segura basada en una cotización antigua. Las marcas de tiempo, las fuentes aprobadas y los límites de frescura deben rechazarla.
• Inyección de prompt o de herramienta puede introducir un nuevo destino o una instrucción oculta. El aislamiento de herramientas y las listas de contratos permitidos mantienen ese cambio fuera de la ruta de firma.
• Desviación de simulación ocurre cuando el calldata ya no coincide con la vista previa. La firma debe seguir vinculada al calldata simulado y a la fecha límite.
• Autoridad de sesión excesiva permite que una acción válida se repita más allá de la intención del usuario. Los límites de monto, frecuencia, activo, método y expiración contienen el daño.
• Reintentos pagados duplicados pueden cobrar otra vez después de un timeout de la API. Una clave de idempotencia debe vincular el reintento con su autorización original.
• Liquidación sin entrega deja un pago confirmado pero sin salida útil del servicio. El recibo necesita una verificación de entrega y una ruta nombrada de reembolso o escalamiento.

Un modelo más fuerte puede mejorar el enrutamiento, pero no puede reemplazar límites deterministas, recuperación, idempotencia ni un recibo que pruebe lo ocurrido.

Recibos de transacción y trazabilidad de auditoría

La instrucción de 50 USDC debe terminar con un único registro que conecte la solicitud con la liquidación. Ni una transcripción de chat ni un hash de transacción por sí solos muestran qué cotización, límite y política produjeron el resultado.

• Mandato y entradas: Comprar ETH en Base, gastar no más de 50 USDC, mantener el impacto en el precio por debajo de 0.5%, y registrar el proveedor de la cotización, la liquidez, el número de bloque y la marca de tiempo.
• Acción propuesta y simulación: Conservar el router, el pool, las direcciones de los tokens, el monto, la salida mínima, el plazo, el hash del calldata, los saldos proyectados, la estimación de gas y los cambios de aprobación.
• Política y autorización: Registrar la versión de la regla, el motivo de aprobación o rechazo, la smart account, el firmante o la sesión, el nonce reservado y la expiración del permiso.
• Liquidación y seguimiento: Adjuntar el hash de la transacción, el bloque, los montos reales, la diferencia entre lo solicitado y lo real, las aprobaciones restantes, la alerta y el propietario de recuperación.

Antes de elevar el límite de la wallet, pruebe una cotización obsoleta, un contrato bloqueado, un monto excesivo, una sesión expirada, un calldata modificado, un nonce conflictivo y un timeout posterior al pago. Cada caso debe detenerse en la capa asignada y permanecer visible en el registro.

Conclusión

Los agentes de IA onchain conectan decisiones offchain con cuentas y cambios de estado en blockchain. Fetch.ai, Olas, AgentKit, Safe y x402 representan descubrimiento, servicios persistentes, herramientas de acción, política de cuenta y pago, en lugar de una única categoría de producto intercambiable. La implementación más sólida muestra por qué se propuso una acción, por qué la política la permitió, qué firmó la wallet y si la liquidación coincidió con el mandato. Comience con trabajo observable, agregue autoridad acotada solo a flujos repetibles y mantenga la recuperación fuera del modelo.

Preguntas frecuentes

¿Los agentes de IA onchain necesitan un token?

No. Una aplicación puede combinar un modelo, APIs de datos, herramientas de transacción y una smart account sin emitir ni requerir un token dedicado. Un token solo importa cuando cumple una función necesaria como pago, staking, acceso, gobernanza o coordinación.

¿Qué se ejecuta offchain en un agente de IA onchain?

El modelo, la memoria, el contexto privado, el procesamiento de datos y la mayor parte de la inferencia suelen ejecutarse offchain porque el cómputo es costoso y las entradas pueden ser sensibles. La blockchain registra con más frecuencia identidad, permisos, pagos, llamadas a contratos y el estado final.

¿Son suficientes las smart accounts para los agentes de IA onchain?

No. Una smart account puede hacer cumplir umbrales, módulos y límites, pero la configuración aún debe revisarse. Módulos inseguros, listas de permitidos demasiado amplias, sesiones largas, recuperación débil o interfaces de firma ilegibles pueden debilitar el límite de la cuenta.

¿Con qué permisos de wallet debería empezar un agente de IA onchain?

La supervisión de solo lectura y la preparación de transacciones sin firmar exponen la menor autoridad financiera. La ejecución basada en aprobaciones es el siguiente paso. La automatización acotada debería llegar solo después de que las pruebas de rutas negativas muestren que las acciones inválidas, obsoletas o cambiadas se rechazan de forma confiable.

Descargo de responsabilidad: La información proporcionada en AiCryptoCore.com tiene únicamente fines educativos e informativos y no constituye asesoramiento financiero, de inversión ni de trading. Las inversiones en criptomonedas conllevan riesgos y pueden resultar en pérdidas financieras. Realice siempre su propia investigación y consulte con un asesor financiero calificado antes de tomar cualquier decisión de inversión.