Informe Galaxy: Las fricciones estructurales obstaculizan a los agentes de IA en la cadena de bloques

Artículo de: Zack Pokorny

Compilado por: Chopper, Foresight News

La implementación de agentes de IA en la blockchain no ha sido sencilla; aunque la blockchain posee características programables y sin permiso, carece de una capa semántica abstracta y de cooperación adaptada a agentes. La institución de investigación criptográfica Galaxy publicó un informe que señala que los agentes enfrentan cuatro fricciones estructurales en la cadena: descubrimiento de oportunidades, verificación confiable, lectura de datos y procesos de ejecución. La infraestructura actual sigue diseñada en torno a la interacción humana y no puede respaldar la gestión autónoma de activos ni la ejecución de estrategias por parte de la IA, lo que constituye el cuello de botella central para la adopción a escala de agentes en la blockchain. A continuación, se presenta la traducción completa del informe:

Los escenarios y capacidades de los agentes de IA ya han comenzado a evolucionar. Comienzan a ejecutar tareas de forma autónoma y se están desarrollando para poseer y configurar capital, así como descubrir estrategias de operación y rendimiento. Aunque este cambio experimental aún se encuentra en una etapa muy inicial, representa una clara diferencia con el desarrollo anterior de los agentes, que principalmente funcionaban como herramientas sociales y de análisis.

La blockchain se está convirtiendo en el campo de pruebas natural de esta evolución. La blockchain es sin permiso, componible, cuenta con un ecosistema de aplicaciones de código abierto, ofrece acceso equitativo a los datos para todos los participantes y todos los activos en la cadena son programables por defecto.

Esto plantea una pregunta estructural: si la blockchain es programable y sin permiso, ¿por qué los agentes autónomos aún enfrentan fricciones? La respuesta no radica en si la ejecución es factible, sino en cuánta carga semántica y de coordinación existe sobre la ejecución. La blockchain garantiza la corrección de las transiciones de estado, pero generalmente no proporciona abstracciones nativas del protocolo, como las necesarias para la interpretación económica, la identificación normativa o la coordinación a nivel de objetivos.

Parte de la fricción proviene de defectos de arquitectura en sistemas sin permiso, y parte refleja el estado actual de las herramientas, la gestión de contenido y la infraestructura del mercado. De hecho, muchas funciones de nivel superior aún dependen de software y flujos de trabajo que requieren intervención humana para su construcción.

El diseño de la blockchain se centra en el consenso y la ejecución determinista, no en la interpretación semántica. Exponen primitivas subyacentes como ranuras de almacenamiento, registros de eventos y trayectorias de llamadas, no objetos económicos estandarizados. Por lo tanto, conceptos abstractos como posiciones, rendimientos, coeficientes de salud y profundidad de liquidez generalmente deben ser reconstruidos fuera de la cadena por indexadores, capas de análisis de datos, interfaces de usuario e interfaces de programación de aplicaciones, transformando el estado específico de cada protocolo en formas más utilizables.

Muchos de los procesos principales de finanzas descentralizadas, especialmente aquellos dirigidos a inversores minoristas y basados en decisiones subjetivas, aún giran en torno al modelo en el que el usuario interactúa a través de una interfaz frontal y firma transacciones individuales. Este modelo centrado en la interfaz de usuario se ha expandido junto con la popularización de los inversores minoristas, aunque una gran parte de las actividades en la cadena ya estén impulsadas por máquinas. El modelo dominante actual de interacción con inversores minoristas sigue siendo: intención → interfaz de usuario → transacción → confirmación. Las operaciones programáticas siguen una ruta diferente, pero también presentan sus propias limitaciones: los desarrolladores seleccionan contratos y conjuntos de activos durante la fase de construcción, y luego ejecutan algoritmos dentro de este rango fijo. Ninguno de estos dos modelos puede adaptarse a sistemas que deben descubrir, evaluar y combinar operaciones dinámicamente en tiempo de ejecución según objetivos en constante cambio.

Cuando una infraestructura optimizada para la verificación de transacciones se utiliza en sistemas que necesitan interpretar simultáneamente el estado económico, evaluar el crédito y optimizar el comportamiento en torno a objetivos claros, comienzan a surgir fricciones. Parte de estas brechas proviene de las características de diseño sin permiso y heterogéneo de la blockchain, y otra parte de que las herramientas de interacción aún se construyen en torno a la revisión humana y los intermediarios frontales.

Antes de explorar la brecha entre la infraestructura de blockchain y los sistemas de agentes, es necesario aclarar: ¿cuál es la diferencia entre los procesos de comportamiento con mayor inteligencia autónoma y los sistemas algorítmicos tradicionales en la cadena?

La diferencia no radica en el grado de automatización, complejidad, configuración parametrizada, ni siquiera en la capacidad de adaptación dinámica. Los sistemas de algoritmos tradicionales pueden lograr una alta parametrización, descubrir automáticamente nuevos contratos y nuevos tokens, asignar fondos entre varios tipos de estrategias y reequilibrar según el rendimiento. La verdadera diferencia radica en si el sistema puede manejar escenarios no previstos durante la fase de construcción.

Los sistemas de algoritmos tradicionales, por muy complejos que sean, solo ejecutan lógicas preestablecidas en función de patrones predefinidos. Requieren un analizador de interfaz predefinido para cada tipo de protocolo, una lógica de evaluación predefinida para mapear el estado del contrato a significados económicos, reglas explícitas para juzgar la credibilidad y la estandarización, y reglas codificadas directamente para cada rama de decisión. Cuando surge una situación que no coincide con los patrones predefinidos, el sistema o bien la ignora o simplemente falla. No puede razonar sobre escenarios desconocidos; solo puede determinar si el escenario actual coincide con una plantilla conocida.

Al igual que este mecanismo automático de "pato digestivo", que puede imitar comportamientos biológicos, pero todos los movimientos están preprogramados.

Un algoritmo tradicional que escanea el mercado de préstamos DeFi puede identificar nuevos contratos desplegados que emiten eventos familiares o coinciden con patrones de fábrica conocidos. Sin embargo, si aparece un nuevo componente de préstamo con una interfaz desconocida, el sistema no puede evaluarlo. Es necesario que un humano revise el contrato, comprenda su mecanismo de funcionamiento, determine si representa una oportunidad explotable y escriba la lógica de integración. Solo después de esto, el algoritmo puede interactuar con él. El humano se encarga de interpretar, y el algoritmo de ejecutar. Los sistemas de agentes basados en modelos fundamentales cambian este límite: pueden lograr mediante capacidades de razonamiento aprendidas:

• Interpretar objetivos ambiguos o mal definidos. Instrucciones como «maximizar los rendimientos pero evitar riesgos excesivos» requieren interpretación semántica. ¿Qué se considera un riesgo excesivo? ¿Cómo se debe equilibrar el rendimiento con el riesgo? Los algoritmos tradicionales necesitan definir con precisión estas condiciones desde el inicio. En cambio, los agentes pueden interpretar la intención, tomar decisiones y optimizar su comprensión según los comentarios recibidos.
• Puede generalizar y adaptarse a interfaces desconocidas. El agente puede leer código de contratos desconocidos, analizar documentación o examinar interfaces binarias de aplicaciones nunca antes vistas, e inferir la función económica del sistema. No requiere construir previamente analizadores para cada tipo de protocolo. Aunque esta capacidad aún no está completamente desarrollada y el agente podría malinterpretar lo que ve, es capaz de intentar interactuar con sistemas que no se previeron durante la fase de construcción.
• Razonar en presencia de incertidumbre en la confianza y la normatividad. Cuando las señales de crédito son ambiguas o incompletas, el modelo base puede ponderar probabilísticamente las señales, en lugar de aplicar reglas binarias simples. ¿Este contrato inteligente es estándar? Según la evidencia disponible, ¿es legítima esta token? Los algoritmos tradicionales o siguen reglas o no tienen solución; en cambio, los agentes pueden razonar sobre la confianza.
• Explica el error y realiza los ajustes. Cuando ocurren situaciones inesperadas, el agente puede razonar sobre la causa raíz y decidir cómo responder. En contraste, los algoritmos tradicionales solo ejecutan módulos de captura de excepciones, reenviando solo la información de la excepción sin interpretarla.

Estas capacidades existen actualmente, pero no son perfectas. Los modelos base generan ilusiones, malinterpretan contenido y toman decisiones erróneas con aparente confianza. En entornos adversos y con capital en juego (es decir, donde el código puede controlar o recibir activos), "intentar interactuar con sistemas no previstos" podría significar pérdida de fondos. La idea central de este artículo no es que los agentes ya puedan ejecutar estas funciones de manera confiable, sino que pueden intentar realizarlas de formas que los sistemas tradicionales no pueden lograr, y que la infraestructura futura permitirá que estos intentos sean más seguros y confiables.

Esta diferencia debe verse más como un continuo que como un límite categorizado absolutamente. Algunos sistemas tradicionales incorporan formas de razonamiento aprendido, y algunos agentes también pueden depender de reglas codificadas en rutas críticas. Esta distinción es direccional, no absolutamente binaria. Los sistemas de agentes transfieren más interpretación, evaluación y trabajo adaptativo al razonamiento en tiempo de ejecución, en lugar de depender de reglas predefinidas durante la fase de construcción. Este punto es crucial para el análisis de los problemas de fricción, ya que los sistemas de agentes buscan lograr exactamente lo que los algoritmos tradicionales evitan por completo. Los algoritmos tradicionales evitan la fricción de descubrimiento al permitir que los humanos filtren conjuntos de contratos durante la fase de construcción; evitan la fricción de control mediante listas blancas mantenidas por operadores; evitan la fricción de datos utilizando analizadores preconstruidos para protocolos conocidos; y evitan la fricción de ejecución operando dentro de límites de seguridad predefinidos. Los humanos realizan previamente el trabajo semántico, de crédito y estratégico, mientras que los algoritmos simplemente ejecutan dentro de esos límites. Los primeros flujos de comportamiento de agentes en cadena podrían seguir este modelo, pero el valor central de los agentes radica en transferir la evaluación de descubrimiento, crédito y estrategia al razonamiento en tiempo de ejecución, en lugar de confiar en reglas predefinidas durante la fase de construcción.

Intentan descubrir y evaluar oportunidades desconocidas, razonar sobre la estandarización sin reglas codificadas, interpretar estados heterogéneos sin analizadores preestablecidos y ejecutar restricciones de estrategia frente a objetivos posiblemente ambiguos. La existencia de fricción no se debe a que los agentes realicen lo mismo que los algoritmos pero con mayor dificultad, sino a que intentan hacer cosas completamente distintas: operar en un espacio de comportamiento abierto y dinámicamente interpretado, en lugar de en un sistema cerrado y previamente integrado.

Desde un punto de vista estructural, esta contradicción no surge de un defecto en el consenso de la cadena de bloques, sino del funcionamiento del conjunto de la pila de interacciones que se ha desarrollado en torno a ella.

La blockchain garantiza transformaciones de estado deterministas, consenso sobre el estado final y finalidad. No intenta codificar en el nivel del protocolo interpretaciones de significado económico, verificación de intenciones o seguimiento de objetivos. Estas responsabilidades han sido históricamente asumidas por interfaces frontales, billeteras, indexadores y otras capas colaborativas fuera de la cadena, donde siempre se requiere intervención humana.

Incluso para participantes experimentados, el modelo de interacción dominante actual refleja este diseño. Los inversores minoristas interpretan el estado a través de un panel de control, seleccionan operaciones mediante la interfaz de usuario y firman transacciones con su billetera, verificando de forma no formal los resultados. Las instituciones de trading algorítmico han automatizado la ejecución, pero aún dependen de operadores humanos para seleccionar conjuntos de protocolos, verificar anomalías y actualizar la lógica de integración cuando cambian las interfaces. En ambos escenarios, el protocolo solo se encarga de garantizar la corrección de la ejecución, mientras que la interpretación de intenciones, el manejo de anomalías y la adaptación a nuevas oportunidades los realiza el ser humano.

Los sistemas de agentes comprimen e incluso eliminan esta división del trabajo. Deben reconstruir programáticamente estados con significado económico, evaluar el progreso hacia los objetivos y verificar los resultados de la ejecución, en lugar de simplemente confirmar que las transacciones se han registrado en la cadena. En la blockchain, esta carga es especialmente notable, ya que los agentes operan en un entorno abierto, adversario y en constante cambio, donde nuevos contratos, activos y rutas de ejecución pueden aparecer sin revisión centralizada. El protocolo solo garantiza la ejecución correcta de las transacciones, pero no garantiza que el estado económico sea fácil de interpretar, que los contratos sean estandarizados, que las rutas de ejecución alineen con la intención del usuario, o que las oportunidades relevantes puedan ser descubiertas programáticamente.

A continuación, se analizarán paso a paso estos rozamientos a lo largo de las distintas etapas del ciclo de funcionamiento del agente: identificar los contratos y oportunidades existentes, verificar su legalidad, obtener estados con significado económico y ejecutar operaciones en torno al objetivo.

Descubrir fricción

La fricción surge porque el espacio de comportamiento de las finanzas descentralizadas se expande abiertamente en un entorno sin permiso, mientras que la relevancia y la legitimidad son filtradas por los humanos a través de capas sociales, de mercado y de herramientas en la cadena. Nuevos protocolos emergen mediante anuncios, pero también pasan por capas de filtrado como integración en interfaces frontales, listados de tokens, plataformas de análisis de datos y formación de liquidez. Con el tiempo, estas señales suelen configurar un criterio viable para distinguir qué partes del espacio de comportamiento poseen valor económico y suficiente confiabilidad, aunque este consenso pueda ser informal, desigual y parcialmente dependiente de terceros y de la selección humana.

Se pueden proporcionar a los agentes datos filtrados y señales de confianza, pero ellos mismos carecen de los atajos intuitivos que los humanos utilizan para interpretar estas señales. Desde una perspectiva on-chain, todos los contratos desplegados tienen la misma visibilidad. Protocolos legítimos, fork maliciosos, despliegues de prueba y proyectos abandonados existen todos en forma de bytecode invocable. La blockchain en sí misma no codifica qué contratos son importantes o seguros.

Por lo tanto, el agente debe construir su propio mecanismo de descubrimiento: escanear eventos de despliegue, identificar patrones de interfaz, rastrear contratos de fábrica (es decir, contratos que pueden programarse para desplegar otros contratos) y monitorear la formación de liquidez para determinar qué contratos deben incluirse en el ámbito de decisión. Este proceso no solo consiste en buscar contratos, sino también en evaluar si deben incorporarse al espacio de comportamiento del agente.

Identificar los candidatos es solo el primer paso. Después de la detección inicial, los contratos deben someterse al proceso de verificación de estandarización y autenticidad descrito en la siguiente sección. El agente debe confirmar primero que el contrato descubierto cumple con su nombre antes de incluirlo en el espacio de decisión.

Descubrir fricción no se refiere a detectar comportamientos recién implementados. Los sistemas algorítmicos maduros ya pueden lograr esto dentro de sus propias estrategias. Los buscadores que monitorean los eventos del contrato Uniswap Factory e incorporan automáticamente nuevos pares de liquidez están realizando descubrimiento dinámico. La fricción aparece en dos niveles superiores: determinar si el contrato descubierto es legítimo y si está relacionado con objetivos abiertos, más allá de simplemente coincidir con tipos de estrategia preestablecidos.

La lógica de descubrimiento del buscador está estrechamente vinculada a su estrategia. Sabe qué patrones de interfaz buscar, porque la estrategia los ha definido. Sin embargo, un agente que ejecuta instrucciones más amplias, como «configurar las oportunidades óptimas ajustadas al riesgo», no puede depender únicamente de los filtros derivados de la estrategia. Debe evaluar nuevas oportunidades en función del objetivo mismo, lo que requiere interpretar interfaces desconocidas, inferir su función económica y determinar si dicha oportunidad debe incluirse en el espacio de decisión. Esto constituye, en cierta medida, un problema de autonomía general, pero la blockchain exacerba este problema.

Controlar la fricción

La generación de fricción en la capa de control se debe a que la verificación de identidad y legitimidad generalmente se realiza fuera del protocolo, dependiendo en conjunto de cribado, gobernanza, documentación, interfaces y juicio operativo. En muchos flujos de trabajo actuales, los humanos siguen siendo una parte esencial en el proceso de evaluación. La blockchain garantiza ejecución determinista y finalidad definitiva, pero no garantiza que el llamador esté interactuando con el contrato objetivo. Esta evaluación de intención se externaliza a contextos sociales, sitios web y cribado humano.

En el proceso actual, los humanos utilizan la capa de confianza del sitio web como un método de verificación informal. Acceden al dominio oficial (generalmente encontrado a través de plataformas agregadoras como DeFiLlama o cuentas de redes sociales verificadas del proyecto) y consideran este sitio como el medio estándar que mapea el concepto humano con la dirección del contrato. Luego, la interfaz frontal establece una referencia confiable viable, especificando qué direcciones son oficiales, qué identificadores de token deben utilizarse y qué entradas son seguras.

El Mecánico Turco de 1789 era una máquina de ajedrez que parecía funcionar de forma autónoma, pero en realidad dependía de un operador humano oculto.

Los agentes no pueden interpretar por defecto identificadores de marca, señales de autenticación social ni la "oficialidad" en contextos sociales. Se puede proporcionarles datos filtrados derivados de estas señales, pero para convertirlos en suposiciones de confianza machine-readable y duraderas, se requiere un registro, estrategia o lógica de validación explícitas. Se pueden configurar para los agentes listas blancas filtradas, direcciones autenticadas y estrategias de confianza proporcionadas por operadores. El problema no es que el contexto social sea inaccesible en absoluto, sino que mantener estas medidas de protección en un espacio de comportamiento dinámicamente expansivo tiene un costo operativo muy alto, y cuando estas medidas faltan o son incompletas, los agentes carecen de los mecanismos de validación alternativos que los humanos utilizan por defecto.

El sistema impulsado por agentes en la cadena ya ha generado consecuencias reales debido a la debilidad en la evaluación de confianza. En el caso del popular influencer de criptomonedas Orangie, se supone que un agente depositó fondos en un contrato de "honeypot". En otro caso, el agente llamado Lobstar Wilde, debido a un fallo en el estado o contexto, malinterpretó el estado de una dirección y transfirió un gran saldo de tokens a un "solicitante" en línea. Estos casos no son argumentos centrales, pero son suficientes para ilustrar cómo los errores en la evaluación de confianza, la interpretación del estado y las estrategias de ejecución pueden conducir directamente a pérdidas de fondos.

El problema no radica en que los contratos sean difíciles de encontrar, sino en que la blockchain generalmente carece de un concepto nativo de «este es el contrato oficial de una aplicación». Esta ausencia es, en cierta medida, una característica de los sistemas sin permiso, no un error de diseño, pero aún así plantea desafíos de coordinación para los sistemas autónomos. Este problema se debe en parte a la arquitectura abierta con identidades débiles y en parte a que los registros, estándares y mecanismos de distribución de confianza aún no están maduros. Un agente que intenta interactuar con Aave v3 debe determinar qué direcciones son las estándar, y si estas son inmutables, pueden actualizarse mediante proxy o actualmente están sujetas a cambios de gobernanza pendientes.

Los humanos resuelven este problema mediante documentos, interfaces frontales y redes sociales. Los agentes deben determinarlo verificando lo siguiente:

• Modelo de agente y puntos clave de implementación
• Permissions and Time Lock
• Módulo de actualización de parámetros de control de gobernanza
• Bytecode / ABI coincidentes entre despliegues

En ausencia de un registro estándar, la "oficialidad" se convierte en un problema de inferencia. Esto significa que los agentes no pueden considerar las direcciones de los contratos como configuraciones estáticas. Deben mantener una lista blanca filtrada verificada continuamente, o derivar dinámicamente la estandarización en tiempo real mediante la verificación de proxies y el monitoreo de gobernanza, o asumir el riesgo de interactuar con contratos obsoletos, comprometidos o falsificados. En el software y la infraestructura de mercado tradicionales, la identidad del servicio generalmente se ancla en espacios de nombres, credenciales y controles de acceso mantenidos por instituciones. En contraste, en la cadena, un contrato puede ser invocado y funcionar correctamente, pero desde la perspectiva del llamador, carece de estandarización económica o comercial.

La autenticidad del token y los metadatos son el mismo problema. Los tokens parecen poder autodescribirse, pero los metadatos del token no son autoritativos; simplemente son datos de bytes devueltos por el código. Un ejemplo clásico es el Ether empaquetado (WETH). El código del contrato WETH, ampliamente utilizado, define explícitamente el nombre, el símbolo y la precisión.

Esto parece una identificación, pero no lo es. Cualquier contrato puede configurarse:

• symbol() = WETH
• decimales() = 18
• name() = Wrapped Ether

Y implementar la misma interfaz de estándar ERC-20. name(), symbol() y decimals() son simplemente funciones de solo lectura públicas que devuelven cualquier contenido establecido por el desplegador. De hecho, en Ethereum hay cerca de 200 tokens con el nombre «Wrapped Ether», símbolo «WETH» y precisión de 18 dígitos. Sin consultar CoinGecko o Etherscan, ¿puedes identificar qué «WETH» es la versión estándar?

Los agentes se enfrentan a esta situación. La blockchain no verifica la unicidad, no consulta ningún registro ni impone ninguna restricción. Hoy puedes desplegar 500 contratos, todos devolviendo los mismos metadatos. Existen algunos métodos de prueba en la cadena (por ejemplo, verificar si el saldo de Ethereum coincide con la oferta total, consultar la profundidad de liquidez en intercambios descentralizados principales, validar si se utiliza como garantía en protocolos de préstamo), pero ninguno proporciona una prueba absoluta. Cada método depende ya sea de supuestos de umbral o de una verificación recursiva de la estandarización de otros contratos.

Al igual que buscar la ruta "verdadera" en un laberinto requiere orientación externa, en la cadena no existen señales nativas estándar.

Por eso existen las listas y registros de tokens como capas de filtrado fuera de la cadena. Proporcionan una forma de mapear el concepto de «WETH» a una dirección específica, lo que explica por qué las billeteras e interfaces frontales mantienen listas blancas o dependen de plataformas agregadoras confiables. Para los agentes, el problema central no es solo la baja confiabilidad de los metadatos, sino que las identidades estándar suelen establecerse a nivel social o institucional, no de forma nativa por el protocolo. El identificador confiable en la cadena es la dirección del contrato; sin embargo, mapear intenciones humanas como «intercambiar por USDC» a la dirección correcta sigue dependiendo en gran medida de filtrados, registros, listas blancas u otras capas de confianza no nativas del protocolo.

Fricción de datos

Los agentes que optimizan la asignación entre diversos protocolos de finanzas descentralizadas deben estandarizar cada oportunidad como un objeto económico: rendimiento, profundidad de liquidez, parámetros de riesgo, estructura de tarifas, fuentes de oráculos, entre otros. Desde cierta perspectiva, se trata de un problema común de integración de sistemas. Sin embargo, en la blockchain, la heterogeneidad de los protocolos, la exposición directa al capital, la concatenación de estados con múltiples llamadas y la falta de un modelo económico unificado subyacente agravan aún más esta carga. Estos elementos son precisamente los fundamentales necesarios para comparar oportunidades, simular asignaciones y monitorear riesgos.

Las blockchains generalmente no exponen objetos económicos estandarizados en el nivel de protocolo. Exponen ranuras de almacenamiento, registros de eventos y salidas de funciones, y los objetos económicos deben inferirse o reconstruirse a partir de ellos. El protocolo solo garantiza que las llamadas al contrato devuelvan los valores de estado correctos, pero no garantiza que estos valores puedan mapearse claramente a conceptos económicos legibles, ni que los mismos conceptos económicos puedan recuperarse mediante una interfaz consistente entre protocolos.

Por lo tanto, conceptos abstractos como el mercado, las posiciones y el coeficiente de salud no son primitivas del protocolo. Estos son reconstruidos fuera de la cadena por indexadores, plataformas de análisis de datos, interfaces de usuario y APIs, transformando el estado heterogéneo del protocolo en abstracciones útiles. Los usuarios humanos suelen ver únicamente este nivel estandarizado. Los agentes también pueden utilizar este nivel, pero heredan así los modelos, retrasos y supuestos de confianza de terceros; de lo contrario, deben reconstruir estas abstracciones por sí mismos.

Este problema se vuelve cada vez más prominente en diversos protocolos. Los precios de las participaciones en la tesorería, las tasas de colateralización en los mercados de préstamos, la profundidad de liquidez de los pools de intercambios descentralizados y las tasas de recompensa de los contratos de staking son componentes fundamentales con significado económico, pero ninguno cuenta con una interfaz estandarizada para su exposición. Cada tipo de protocolo tiene sus propios métodos de obtención, estructura y convenciones de unidades. Incluso dentro de la misma categoría, las implementaciones varían.

Mercado de préstamos: recuperar casos de estudio fragmentados

El mercado de préstamos refleja claramente este problema. Sus conceptos económicos son universales y aproximadamente uniformes, como la oferta y la liquidez de préstamos, las tasas de interés, la tasa de garantía, los límites de crédito y los umbrales de liquidación, pero las vías de acceso varían.

En Aave v3, la enumeración del mercado y la obtención del estado de la reserva son dos pasos independientes. El flujo típico es el siguiente:

Listar los activos de reserva mediante el siguiente método y devolver el arreglo de direcciones de tokens.

Para cada activo, obtenga los datos básicos de liquidez y tasa de interés mediante otro fragmento de código,

Este método devuelve, mediante una sola llamada, una estructura que contiene el total de liquidez, el índice de interés y las banderas de configuración, por ejemplo:

En comparación, en Compound v3, cada despliegue corresponde a un solo mercado (USDC, USDT, ETH, etc.) y no tiene una estructura de reserva unificada. En su lugar, es necesario ensamblar instantáneas del mercado mediante múltiples llamadas a funciones:

• Utilización básica
• Total
• Interest rate
• Asignación de activos garantizados
• Parámetros de configuración global

Cada llamada devuelve solo un subconjunto diferente del estado económico. «Mercado» no es un objeto de primer nivel, sino una estructura inferida construida por el llamador.

Desde la perspectiva del agente, ambos protocolos son mercados de préstamos; pero desde la perspectiva de la integración, son sistemas de adquisición con estructuras completamente diferentes. No existe un modelo compartido unificado. Por el contrario, los agentes deben utilizar diferentes métodos de enumeración de activos para cada protocolo, combinando el estado a través de múltiples llamadas.

La fragmentación genera retrasos y riesgos de consistencia

Además de la inconsistencia estructural, esta fragmentación introduce riesgos de latencia y coherencia. Dado que el estado económico no se expone como un único objeto de mercado atómico, los agentes deben reconstruir instantáneas mediante múltiples llamadas remotas a varios contratos. Cada llamada adicional aumenta la latencia, el riesgo de limitación y la probabilidad de inconsistencia entre bloques. En entornos volátiles, cuando se completa el cálculo de la tasa de oferta, la tasa ya puede haber cambiado; sin bloquear explícitamente un bloque, los parámetros de configuración podrían corresponder a una altura de bloque diferente a la del total de liquidez. Los usuarios dependen de capas de caché en la interfaz de usuario y backends agregados para mitigar indirectamente estos problemas. Los agentes que operan directamente sobre las interfaces RPC originales deben gestionar explícitamente la sincronización, el procesamiento por lotes y la coherencia temporal. Por lo tanto, la recuperación no estandarizada no solo genera inconvenientes de integración, sino que también limita el rendimiento, la sincronización y la corrección.

Debido a la falta de un esquema estandarizado para la recuperación de datos económicos, incluso cuando los protocolos implementan primitivas financieras casi idénticas, su exposición de estado depende de las especificidades y la composición de los contratos. Esta diferencia estructural es un componente central de la fricción de datos.

Posible desajuste en el flujo de datos

El acceso al estado económico en la cadena de bloques es inherentemente un modelo de extracción, incluso cuando las señales de ejecución pueden transmitirse en flujo. Los sistemas externos consultan a los nodos el estado requerido, en lugar de recibir actualizaciones continuas y estructuradas. Este modelo refleja la función central de la cadena de bloques: verificar según sea necesario, en lugar de mantener una vista continua del estado a nivel de aplicación.

Existen primitivas push. Las suscripciones WebSocket pueden transmitir en tiempo real nuevos bloques y registros de eventos, pero estos no contienen el estado de almacenamiento que lleva la mayor parte del significado económico, a menos que el protocolo elija explícitamente publicar información redundante. Los agentes no pueden suscribirse directamente a través de la cadena para obtener la utilización del mercado de préstamos, las reservas de los pools o el coeficiente de salud de las posiciones. Estos valores se almacenan en el almacenamiento del contrato, y la mayoría de los protocolos no proporcionan mecanismos nativos para enviar esta información a los consumidores aguas abajo. El modelo óptimo actual consiste en suscribirse a los encabezados de nuevos bloques y volver a consultar en cada bloque. Los registros solo pueden indicar que el estado podría haber cambiado, pero no codifican el estado económico final; reconstruir ese estado aún requiere lecturas explícitas y acceso al estado histórico.

Los sistemas de agentes podrían beneficiarse de un flujo inverso. En lugar de sondear el estado de cientos de contratos, los agentes pueden recibir actualizaciones de estado estructuradas y precalculadas, enviadas directamente al entorno de ejecución. Una arquitectura de push reduce consultas redundantes, disminuye la latencia entre los cambios de estado y la percepción del agente, y permite que las capas intermedias empaqueten el estado en actualizaciones semánticamente claras, en lugar de exigir que los agentes interpreten el significado desde el almacenamiento crudo.

Este giro inverso no es sencillo. Requiere infraestructura de suscripción, lógica para filtrar relevancia y patrones para convertir cambios almacenados en eventos económicos ejecutables por agentes. Pero a medida que los agentes se convierten en participantes continuos en lugar de consultores intermitentes, el costo de la ineficiencia del modelo de extracción se vuelve cada vez más elevado. Considerar la infraestructura como un consumidor continuo en lugar de un cliente intermitente puede alinearse mejor con la forma en que funcionan los sistemas autónomos.

Si la infraestructura push es realmente superior sigue siendo una pregunta sin resolver. Los cambios masivos de estado generan problemas de filtrado, y los agentes aún deben determinar qué cambios son relevantes, reintroduciendo así semántica pull en otro nivel. Lo crucial no es que la arquitectura pull tenga problemas en sí misma, sino que la arquitectura actual no considera consumidores de máquina persistentes; a medida que se amplíe el uso de agentes, podría valer la pena explorar otros modelos alternativos.

Ejecutar fricción

La generación de fricción ocurre porque muchas capas de interacción actuales empaquetan la conversión de intenciones, la revisión de transacciones y la verificación de resultados en flujos de trabajo diseñados alrededor de interfaces de usuario, billeteras y supervisión operativa. En escenarios de inversores minoristas y decisiones subjetivas, esta supervisión generalmente la realiza un ser humano. Para sistemas autónomos, estas funciones deben ser formalizadas y codificadas directamente. La blockchain garantiza la ejecución determinista según la lógica del contrato, pero no garantiza que las transacciones cumplan con la intención del usuario, respeten restricciones de riesgo o logren resultados económicos esperados. En los flujos actuales, la interfaz de usuario y los humanos llenan esta brecha.

Secuencia de operaciones combinadas en la interfaz de usuario (intercambio, autorización, depósito, préstamo): la billetera proporciona el nodo final de «revisar y enviar», en el que el usuario o el operador suele tomar una decisión estratégica de forma informal en la última etapa. Con frecuencia, juzgan si la transacción es segura y si los resultados de la cotización son aceptables, incluso con información incompleta. Si la transacción falla o produce resultados inesperados, el usuario vuelve a intentarlo, ajusta el deslizamiento, cambia la ruta o simplemente abandona la operación. El sistema de agentes elimina al ser humano de este ciclo de ejecución. Esto significa que el sistema debe reemplazar las tres funciones humanas mediante métodos nativos de máquina:

• Integración de intenciones. Objetivos humanos como «transferir mis stablecoins al lugar con el mejor rendimiento ajustado al riesgo» deben integrarse en planes de acción concretos: elegir qué protocolo, qué mercado, qué ruta de tokens, qué tamaño y qué autorizaciones, así como el orden de ejecución. Para los humanos, este proceso se completa implícitamente a través de la interfaz de usuario; para los agentes inteligentes, debe implementarse de forma formal.
• Ejecución de la estrategia. Hacer clic en «Enviar transacción» no solo firma, sino que también verifica implícitamente si la transacción cumple con las restricciones: tolerancia al deslizamiento, límite de apalancamiento, coeficiente de salud mínimo, contrato de lista blanca o «contratos no actualizables prohibidos». El agente debe codificar las restricciones de la estrategia como reglas verificables por máquina:
• El sistema de ejecución debe verificar que el gráfico de llamadas propuesto cumpla con estas reglas antes de transmitirlo.
• Verificación de resultados. Que una operación se registre en la cadena no equivale a completar la tarea. Aunque la operación se ejecute con éxito, aún puede no alcanzar el objetivo: el deslizamiento puede superar el rango tolerable, el tamaño de la posición objetivo puede no alcanzarse debido a límites de cuota, o las tasas pueden haber cambiado entre la simulación y el registro en la cadena. Los humanos verifican de forma informal revisando la interfaz de usuario después del hecho. Los agentes deben evaluar programáticamente las condiciones posteriores.

Esto introduce la necesidad de una verificación completa, más allá de una simple inclusión de transacción. La arquitectura centrada en intenciones puede abordar parcialmente este problema transfiriendo la mayor carga de «cómo» ejecutar desde los agentes a solucionadores especializados. Al transmitir intenciones firmadas en lugar de datos de llamada originales, los agentes pueden especificar restricciones basadas en resultados que los solucionadores o mecanismos a nivel de protocolo deben satisfacer para que la ejecución sea aceptable.

Flujo de trabajo de múltiples pasos y modos de fallo

La mayoría de las operaciones en finanzas descentralizadas son inherentemente multietapa. Una configuración de rendimiento puede requerir autorizar → intercambiar → depositar → prestar → apostar. Algunos pasos pueden ser transacciones independientes, mientras que otros se pueden agrupar mediante contratos de múltiples llamadas o enrutamiento. Los humanos pueden tolerar procesos parciales y volver a la interfaz de usuario para continuar el flujo. Los agentes, en cambio, requieren una orquestación de procesos determinista: si cualquier paso falla, el agente debe decidir si reintentar, redirigir, revertir o pausar.

Esto ha generado nuevos modos de fallo ampliamente ocultos en los procesos humanos:

• Desviación de estado entre la decisión y la cadena. Entre la simulación y la ejecución, las tasas de interés, la utilización o la liquidez pueden cambiar. Los humanos aceptan esta variabilidad; los agentes deben establecer rangos aceptables y hacerlos cumplir.
• Ejecución no atómica y parcial. Algunas operaciones pueden ejecutarse a través de múltiples transacciones o generar resultados parciales. El agente debe rastrear el estado intermedio y confirmar que el estado final cumple con el objetivo.
• Cuota de autorización y riesgo de aprobación. Los humanos firman automáticamente la autorización a través de la interfaz de usuario; los agentes inteligentes deben razonar el alcance de la autorización (cuota, usuario, duración) como parte de una política de seguridad, y no simplemente como un paso de la interfaz de usuario.
• Selección de ruta y costes de ejecución implícitos. Los humanos dependen de contratos de enrutamiento y configuraciones predeterminadas de la interfaz de usuario. Los agentes deben incorporar el deslizamiento, el riesgo de valor extraíble máximo, los costes de gas y el impacto en el precio dentro de la función objetivo.

Ejecutar: problema de control nativo de la máquina

El argumento central sobre la fricción de ejecución es que la capa de interacción en las finanzas descentralizadas utiliza la firma de billeteras humanas como plano de control final. Este paso asume la verificación de intención actual, la tolerancia al riesgo y juicios informales de «¿es razonable?». Al eliminar al ser humano, la ejecución se convierte en un problema de control: los agentes deben traducir objetivos en patrones de comportamiento, ejecutar automáticamente restricciones de estrategia y validar resultados bajo incertidumbre. Este desafío existe en muchos sistemas autónomos, pero el entorno blockchain es particularmente exigente: la ejecución implica directamente capital, contratos desconocidos combinables y está expuesta a cambios de estado adversarios. Los humanos toman decisiones mediante heurísticas y corrigen errores por ensayo y error. Los agentes deben realizar el mismo trabajo programáticamente a velocidad de máquina, a menudo dentro de espacios de comportamiento dinámicamente cambiantes. Por lo tanto, la afirmación de que «el agente solo necesita enviar una transacción» subestima la dificultad. Enviar una transacción es la parte más sencilla.

El diseño original de la blockchain no proporciona nativamente la capa semántica y de cooperación requerida por los agentes. Su objetivo es garantizar la ejecución determinista y el consenso en la transición de estados en entornos adversos. La capa de interacción construida sobre esta base ha evolucionado en torno al modelo en el que los usuarios humanos interpretan los estados a través de interfaces, seleccionan operaciones mediante interfaces frontales y verifican resultados mediante revisión manual.

Los agentes sistémicos revolucionan esta arquitectura. Eliminan al analista humano, al aprobador y al verificador del ciclo, requiriendo que estas funciones se implementen de forma nativa en máquinas. Esta transformación expone fricciones estructurales en cuatro dimensiones: descubrimiento, evaluación de crédito, obtención de datos y procesos de ejecución. Estas fricciones surgen no porque la ejecución sea inviable, sino porque la infraestructura alrededor de la blockchain aún asume, en la mayoría de los casos, la participación humana entre la interpretación del estado y la presentación de la transacción.

Cerrar estas brechas probablemente requiera construir nuevas infraestructuras en múltiples capas de la pila tecnológica: normalizar el estado económico entre protocolos en middleware legible por máquinas; servicios de indexación o extensiones de llamadas remotas para primitivas semánticas como posiciones, coeficientes de salud y conjuntos de oportunidades; un registro que proporcione mapeo estandarizado de contratos y verificación de autenticidad de tokens; y un marco de ejecución que codifique restricciones de estrategia, maneje flujos de trabajo de múltiples pasos y verifique programáticamente la finalización de objetivos. Algunas brechas provienen de las características estructurales de los sistemas sin permiso: despliegue abierto, identidad débil y interfaces heterogéneas. Otras dependen de las herramientas, estándares y diseños de incentivos actuales; a medida que aumenta la escala de uso de agentes y los protocolos compiten por optimizar la integración con sistemas autónomos, estas brechas se reducirán.

A medida que los sistemas autónomos comienzan a gestionar capital, ejecutar estrategias e interactuar directamente con aplicaciones en la cadena, las suposiciones arquitectónicas de la capa de interacción actual se volverán cada vez más evidentes. La mayor parte de la fricción descrita en este artículo refleja cómo las herramientas y los modelos de interacción blockchain han evolucionado en torno a flujos de trabajo con intermediarios humanos; parte de esta fricción proviene de la naturaleza abierta, heterogénea y adversa de los sistemas sin permiso; y otra parte son problemas comunes a los sistemas autónomos en entornos complejos.

El desafío principal no es hacer que el agente firme transacciones, sino proporcionarle un camino confiable para realizar la interpretación semántica, la evaluación de crédito y la ejecución de estrategias, tareas que actualmente comparten el software y el juicio humano entre el estado de la cadena de bloques y el comportamiento operativo.