¡Ultimátum! La gigantesca IA está a punto de despertar, ¿la ecología de $ETH enfrenta una "reorganización estructural", puedes soportar tu posición?

La cadena de bloques está diseñada para máquinas, pero no específicamente para agentes inteligentes.
El análisis de mercado indica que la implementación de agentes AI en la cadena no es fluida.
Aunque la blockchain posee características de permisos sin restricciones y programabilidad, le falta una capa de abstracción semántica y colaboración adaptada a agentes.
Un informe de investigación identifica cuatro fricciones estructurales que enfrentan los agentes en la cadena: descubrimiento de oportunidades, validación de confianza, lectura de datos y flujo de ejecución.
La infraestructura actual aún gira en torno a la interacción humana, dificultando que la AI gestione activos de forma autónoma y ejecute estrategias, constituyendo un cuello de botella para una adopción a gran escala.

El escenario de aplicación de los agentes AI está en evolución.
Comienzan a ejecutar tareas de forma autónoma y se desarrollan para poseer y configurar capital, así como para explorar estrategias de trading y rendimiento.
Este cambio experimental aún está en una etapa muy temprana, pero difiere radicalmente del modelo anterior donde los agentes eran principalmente herramientas sociales y analíticas.
La blockchain, por su naturaleza de permisos sin restricciones, combinable, datos abiertos y activos programables por defecto, se convierte en un campo de pruebas natural.
Esto plantea una cuestión estructural: si la blockchain es programable y sin permisos, ¿por qué aún enfrentan fricciones los agentes autónomos?
La respuesta no está en la viabilidad de la ejecución, sino en la carga semántica y de coordinación que soportan esas ejecuciones.

La blockchain garantiza la corrección en las transiciones de estado, pero generalmente no proporciona abstracciones nativas en el protocolo, como interpretaciones económicas, normativas de identidad o coordinación de objetivos.
Algunas fricciones provienen de defectos en la arquitectura de sistemas sin permisos, otras reflejan el estado actual de herramientas, gestión de contenido e infraestructura de mercado.
De hecho, muchas funciones superiores aún dependen de software y flujos de trabajo que requieren intervención humana.

El diseño de la blockchain se centra en consenso y ejecución determinista, no en interpretación semántica.
Expone primitivas básicas como slots de almacenamiento, registros de eventos y trazas de llamadas, en lugar de objetos económicos estandarizados.
Por ello, conceptos abstractos como posiciones, rendimientos, coeficientes de salud o profundidad de mercado, suelen ser reconstruidos off-chain mediante indexadores, análisis de datos, interfaces frontend y APIs.

Muchos procesos de finanzas descentralizadas, especialmente los orientados a minoristas, aún giran en torno a la interacción del usuario a través de interfaces y firmas de transacciones.
Este modelo centrado en la interfaz de usuario se ha expandido con la popularización de los minoristas, incluso cuando muchas actividades en la cadena ya son impulsadas por máquinas.
Las operaciones programadas siguen otro camino, pero también tienen limitaciones: los desarrolladores seleccionan contratos y activos en la fase de construcción, y luego ejecutan algoritmos en ese rango fijo.
Ambos modelos no se adaptan a sistemas que deben descubrir, evaluar y combinar operaciones en tiempo de ejecución, en función de objetivos que cambian continuamente.

Cuando una infraestructura optimizada para validación de transacciones se usa para interpretar estados económicos, evaluar crédito y optimizar comportamientos en torno a objetivos claros, las fricciones emergen.
Parte de estas dificultades proviene de la naturaleza sin permisos y heterogénea de la blockchain, y otra parte de las herramientas, gestión y mercado que aún dependen de revisión humana y mediación en frontend.

¿Qué diferencia a los procesos de comportamiento más autónomos respecto a los sistemas algorítmicos tradicionales en la cadena?
La diferencia no radica en el nivel de automatización o complejidad.
Los sistemas algorítmicos tradicionales pueden ser altamente parametrizables, descubrir nuevos contratos y tokens, distribuir fondos entre estrategias y reequilibrar según rendimiento.
La verdadera diferencia está en si el sistema puede manejar escenarios imprevistos en la fase de construcción.

Los sistemas algorítmicos tradicionales, por muy complejos que sean, solo ejecutan lógica predefinida en patrones establecidos.
Requieren interfaces predefinidas, evaluaciones que mapeen estados de contratos a significados económicos, reglas de crédito y estándares, y reglas codificadas para decisiones.
Cuando enfrentan situaciones no previstas, simplemente las ignoran o fallan.
No pueden razonar sobre escenarios desconocidos, solo verificar si coinciden con patrones conocidos.

Los agentes basados en modelos fundamentales cambian estos límites.
Pueden aprender a interpretar objetivos imprecisos o incompletos, generalizar interfaces desconocidas, razonar en entornos con incertidumbre en confianza y normas, explicar errores y ajustar decisiones.
Estas capacidades existen en la práctica, aunque imperfectamente.
Los modelos fundamentales pueden hallucinar, malinterpretar contenidos y tomar decisiones erróneas con apariencia de certeza.
En entornos adversariales y con capital, “interactuar con sistemas no previstos” puede significar pérdida de fondos.

El punto central no es que los agentes puedan ejecutar estas funciones de forma confiable hoy, sino que puedan intentarlo de maneras que los sistemas tradicionales no permiten, y que futuras infraestructuras harán más seguras y confiables estos intentos.
Esta diferencia debe verse como un estado continuo, no como límites absolutos.
Los sistemas de agentes trasladarán más interpretación, evaluación y autoajuste a la inferencia en tiempo de ejecución, en lugar de reglas predefinidas en la construcción.

Esto es crucial para entender las fricciones, porque los agentes intentan hacer cosas que los algoritmos tradicionales evitan.
Los algoritmos tradicionales evitan fricciones mediante la selección manual de contratos, listas blancas mantenidas por operadores, parsers preconstruidos para protocolos conocidos y ejecución dentro de límites seguros.
El trabajo semántico, de confianza y de estrategia se realiza previamente por humanos, y los algoritmos solo ejecutan dentro de ese rango.

En etapas iniciales, los agentes en la cadena pueden seguir este esquema, pero su valor central radica en trasladar la detección, evaluación y estrategia a la inferencia en tiempo de ejecución, no en reglas predefinidas.
Intentarán descubrir y evaluar oportunidades desconocidas, razonar en ausencia de reglas rígidas, interpretar estados heterogéneos y ejecutar estrategias en objetivos imprecisos.
La fricción no surge porque los agentes hagan lo mismo que los algoritmos, sino porque intentan hacer cosas radicalmente diferentes: operar en un espacio abierto, dinámico y de interpretación flexible, en lugar de un sistema cerrado y preintegrado.

Desde una perspectiva estructural, estas contradicciones no provienen de fallas en el consenso de la blockchain, sino del modo en que funciona la pila de interacción general que la rodea.
La blockchain garantiza la determinación en las transiciones de estado, el consenso en el estado final y la certeza final.
No intenta codificar interpretaciones económicas, validación de intenciones o seguimiento de objetivos en el protocolo.
Estas funciones siempre han sido responsabilidad de interfaces frontend, wallets, indexadores y otros componentes off-chain, que requieren intervención humana.

Incluso los participantes experimentados reflejan este diseño en sus interacciones.
Los minoristas interpretan estados mediante dashboards, seleccionan operaciones en interfaces, firman transacciones en wallets, sin validar formalmente los resultados.
Los traders algorítmicos automatizan la ejecución, pero aún dependen de humanos para filtrar contratos, verificar anomalías y actualizar integraciones ante cambios en interfaces.
En ambos casos, los contratos garantizan solo la corrección en la ejecución, mientras que la interpretación de intenciones, manejo de excepciones y adaptación a nuevas oportunidades queda en manos humanas.

Los sistemas de agentes eliminan o comprimen esta división.
Deben reestructurar programáticamente estados con significado económico, evaluar el progreso de objetivos y verificar resultados, no solo confirmar transacciones en la cadena.
En la blockchain, estas cargas son aún más evidentes, ya que los agentes operan en entornos abiertos, adversariales y en rápida evolución, donde nuevos contratos, activos y caminos de ejecución pueden surgir sin revisión centralizada.
Los contratos solo garantizan la correcta ejecución de transacciones, no que el estado económico sea interpretable, que los contratos sean estándar, que los caminos de ejecución reflejen la intención del usuario o que las oportunidades puedan ser descubiertas programáticamente.

A continuación, se analizarán las fricciones en cada etapa del ciclo de operación del agente: descubrimiento de contratos y oportunidades, validación de legalidad, obtención de estados con significado económico y ejecución en torno a objetivos.

Estas fricciones surgen porque el espacio de finanzas descentralizadas se expande sin permisos, y la relevancia y legalidad se filtran mediante interacción social, mercado y herramientas en la cadena.
Nuevos protocolos emergen mediante anuncios, pero también pasan por filtros en frontend, listas de tokens, plataformas de análisis y formación de liquidez.
Con el tiempo, estas señales suelen formar criterios de juicio para distinguir qué partes del espacio de operación tienen valor económico y son confiables.

Se puede proveer a los agentes con datos y señales de confianza filtrados, pero no poseen la intuición rápida que los humanos usan para interpretarlos.
Desde la perspectiva on-chain, todos los contratos desplegados son igualmente descubribles.
Protocolos legítimos, bifurcaciones maliciosas, despliegues de prueba y proyectos abandonados existen en forma de bytecode callable.
La blockchain no codifica qué contratos son importantes o seguros.

Por ello, los agentes deben construir sus propios mecanismos de descubrimiento: escanear eventos de despliegue, identificar patrones de interfaz, rastrear contratos factory y monitorear la formación de liquidez, para decidir qué contratos incluir en su decisión.
Este proceso no solo busca contratos, sino también evaluar si deben entrar en el espacio de comportamiento del agente.
Identificar candidatos es solo el primer paso.
Tras el descubrimiento preliminar, deben pasar por procesos de validación de estándar y autenticidad.

La fricción en el descubrimiento no es solo detectar nuevos despliegues.
Los sistemas algorítmicos maduros ya pueden hacer esto dentro de sus estrategias.
Por ejemplo, monitorear eventos de fábricas de Uniswap y buscar pools nuevos automáticamente es una forma de descubrimiento dinámico.
Las fricciones aparecen en niveles superiores: determinar si los contratos descubiertos son legales y si están relacionados con objetivos abiertos, en lugar de solo coincidir con tipos predefinidos.

La lógica de descubrimiento de los buscadores está estrechamente ligada a sus estrategias.
Saben qué patrones de interfaz buscar, porque sus estrategias ya los definen.
Pero los agentes que ejecutan “configurar oportunidades óptimas tras ajuste de riesgo” no pueden depender solo de filtros basados en estrategia.
Deben evaluar las oportunidades en función del objetivo, lo que requiere interpretar interfaces desconocidas, inferir funciones económicas y decidir si la oportunidad entra en su espacio de decisión.
Esto es en parte un problema de autonomía general, pero la blockchain lo intensifica.

La fricción en la capa de control surge porque la identidad y la legitimidad suelen determinarse fuera del protocolo, mediante filtros, gobernanza, documentación, interfaces y juicios de operadores.
En muchos flujos actuales, los humanos siguen siendo la parte clave en estas decisiones.
La blockchain garantiza ejecución determinista y certeza final, pero no asegura que el llamador interactúe con el contrato correcto.
Esa intención se externaliza en contextos sociales, sitios web y revisión manual.

En los procesos actuales, los humanos usan la capa de confianza del sitio web como medio de validación informal.
Acceden a dominios oficiales y ven ese sitio como un mapeo estándar entre conceptos humanos y direcciones de contratos.
Luego, las interfaces frontend generan un estándar confiable, identificando direcciones oficiales, tokens a usar y entradas seguras.

Los agentes por defecto no pueden interpretar marcas, señales sociales o “oficialidad” a través del contexto social.
Se les puede proveer datos filtrados basados en esas señales, pero convertir eso en una hipótesis de confianza duradera requiere registros, estrategias o lógica de validación explícita.
Se pueden configurar listas blancas, direcciones certificadas y políticas de confianza para los operadores.
El problema no es que sea imposible obtener contexto social, sino que mantener esas protecciones en un espacio en expansión dinámica es costoso, y su ausencia o deficiencia priva a los agentes de mecanismos de validación alternativos que los humanos usan por defecto.

Ya existen casos en los que la debilidad en la validación de confianza en los agentes ha causado pérdidas reales.
Por ejemplo, agentes que supuestamente depositaron fondos en contratos honeypot.
O agentes que, por fallos en estado o contexto, transfirieron grandes saldos a “mendigos” en línea.
Estos casos no son el núcleo del argumento, pero ilustran cómo errores en confianza, interpretación de estado y estrategia pueden causar pérdidas directas.

El problema no es solo que los contratos sean difíciles de descubrir, sino que la blockchain generalmente no tiene un concepto nativo de “contrato oficial de una aplicación”.
Esta carencia, en parte, es una característica del sistema sin permisos, no un fallo de diseño, pero genera dificultades de colaboración para sistemas autónomos.
Parte de esto proviene de una arquitectura débil en identidad estándar y de mecanismos de registro, estándares y distribución de confianza aún inmaduros.

Un agente que intenta interactuar con Aave v3 debe determinar qué direcciones son estándar, si son inmutables, si pueden ser actualizadas por proxy, o si están en proceso de gobernanza.
Los humanos resuelven esto mediante documentación, interfaces y redes sociales.
Los agentes deben verificar: modo de proxy y detalles de implementación; permisos de gestión y bloqueos temporales; módulos de actualización de parámetros gobernados; y coincidencias de bytecode o API conocidas.

Sin un registro estándar, la “oficialidad” se vuelve un problema de inferencia.
Los agentes no pueden tratar las direcciones como configuraciones estáticas.
Deben mantener listas blancas de verificación, o verificar en tiempo de ejecución mediante proxies y monitoreo de gobernanza, asumiendo riesgos de interactuar con contratos abandonados, dañados o falsificados.

En software y mercados tradicionales, la identidad de servicio se mantiene mediante espacios de nombres, credenciales y controles de acceso gestionados por instituciones.
En la cadena, un contrato puede ser llamado y funcionar, pero desde la perspectiva del llamador, puede no tener una identidad estándar en el nivel económico o de negocio.

La autenticidad de tokens y sus metadatos es la misma problemática.
Los tokens parecen autodescriptivos, pero sus metadatos no son autoritativos, solo datos devueltos por código.
Por ejemplo, WETH (Wrapped Ether) define claramente nombre, símbolo y precisión en su código, pero esto no garantiza su identidad.
Cualquier contrato puede implementar la misma interfaz ERC-20 y definir sus propios valores.
name(), symbol() y decimals() son funciones públicas de solo lectura que devuelven contenidos arbitrarios definidos por el desplegador.

De hecho, hay cerca de 200 tokens en Ethereum con nombre “Wrapped Ether”, símbolo “WETH” y 18 decimales.
¿Puedes distinguir cuál “WETH” es la versión estándar sin consultar CoinGecko o Etherscan?
El problema que enfrentan los agentes es exactamente ese.
La blockchain no verifica unicidad, no consulta registros ni impone restricciones.

Existen métodos de detección tentativos en la cadena, como verificar que el saldo de ETH coincida con la oferta total, consultar la profundidad de liquidez en exchanges descentralizados, o validar si un contrato se usa como colateral en préstamos, pero ninguno ofrece prueba absoluta.
Cada método depende de umbrales o de validaciones recursivas en otros contratos, por eso existen listas de tokens y registros como filtros off-chain.

Para los agentes, el problema central no solo es la baja confianza en los metadatos, sino que las identidades estándar suelen establecerse en contextos sociales o institucional, no en el protocolo.
Un identificador confiable en la cadena es la dirección del contrato, pero mapear intenciones humanas como “canjear por USDC” a la dirección correcta sigue dependiendo en gran medida de filtros, registros, listas blancas o mecanismos de confianza no nativos del protocolo.

Los agentes que optimizan la asignación entre protocolos DeFi deben estandarizar cada oportunidad en objetos económicos: rendimiento, profundidad de liquidez, parámetros de riesgo, estructura de tarifas, fuentes de oráculos, etc.
Desde cierto punto de vista, esto es un problema de integración de sistemas.
Pero en la blockchain, la heterogeneidad de protocolos, exposición directa de capital, múltiples estados de llamada y la falta de un modelo económico unificado complican aún más esta tarea.

La blockchain generalmente no expone objetos económicos estandarizados en el nivel de protocolo.
Solo muestra slots de almacenamiento, registros de eventos y resultados de funciones, y los objetos económicos deben inferirse o reconstruirse a partir de ellos.
Los contratos solo garantizan que las llamadas devuelvan valores correctos, no que esos valores sean interpretables como conceptos económicos claros, ni que puedan recuperarse de forma consistente a través de diferentes protocolos.

Por ello, conceptos como mercado, posición o coeficiente de salud no son primitivas del protocolo.
Son reconstruidos off-chain mediante indexadores, plataformas de análisis, interfaces frontend y APIs, transformando estados heterogéneos en abstracciones utilizables.
Los humanos solo ven esa capa estandarizada, y los agentes también pueden usarla, pero heredarán modelos de terceros, latencias y suposiciones de confianza; si no, deben reconstruir esas abstracciones por sí mismos.

Este problema se acentúa en diversos protocolos.
El valor de las participaciones en vaults, los ratios de colateral en préstamos, la profundidad de liquidez en pools de DEX, las tasas de recompensa en contratos de staking, son componentes básicos con significado económico, pero sin interfaces estandarizadas.
Cada tipo de protocolo tiene sus propios métodos de acceso, estructura y convenciones.
Incluso dentro de la misma categoría, las implementaciones varían.

El ejemplo más claro es el mercado de préstamos.
Sus conceptos económicos son en general uniformes: oferta y demanda de liquidez, tasas de interés, ratios de colateral, límites y umbrales de liquidación, pero los caminos para acceder a ellos difieren.
En Aave v3, la enumeración de mercados y la obtención del estado de reserva son pasos separados.
En Compound v3, cada despliegue corresponde a un mercado único, sin una estructura de reserva unificada, sino múltiples llamadas para obtener instantáneas.

Desde la perspectiva del agente, ambos son mercados de préstamo; pero desde la integración, son sistemas de obtención completamente diferentes.
No existe un patrón compartido, por lo que el agente debe usar métodos distintos para enumerar activos en cada protocolo, realizando múltiples llamadas y combinando estados.

Además de la diferencia estructural, esta fragmentación introduce riesgos de latencia y de consistencia.
Dado que los estados económicos no se exponen como objetos de mercado atómicos, el agente debe hacer múltiples llamadas remotas para reconstruir instantáneas, aumentando la latencia, el riesgo de limitación y la probabilidad de inconsistencias en bloques.
En entornos volátiles, cuando se calcula la tasa de interés, esta puede haber cambiado en el bloque, y si no se bloquea explícitamente el bloque, los parámetros pueden no coincidir con el estado de liquidez en diferentes alturas.

Los usuarios dependen de caches en la interfaz y de backends agregadores para mitigar estos problemas.
Los proxies que operan directamente con RPCs deben gestionar explícitamente sincronización, lotes y consistencia temporal.
Por ello, las búsquedas no estandarizadas no solo dificultan la integración, sino que limitan rendimiento, sincronización y precisión.
La falta de un esquema estandarizado para consultar datos económicos hace que, incluso si los protocolos implementan primitivas financieras similares, sus estados expuestos varíen según el contrato y su composición.
Esta diferencia estructural es la raíz de la fricción de datos.

El acceso al estado económico en la blockchain es esencialmente un patrón de extracción (pull), aunque las señales de ejecución puedan transmitirse en streaming.
Los sistemas externos consultan los estados necesarios en los nodos, en lugar de recibir actualizaciones continuas y estructuradas.
Este patrón refleja la función central de la blockchain: verificación bajo demanda, no mantener vistas de estado persistentes.

Existen primitivas push.
Suscripciones WebSocket pueden transmitir en tiempo real nuevos bloques y logs, pero no contienen la mayor parte del estado económico, salvo que el protocolo decida publicarlo redundante.
Los agentes no pueden subscribirse directamente a métricas como utilización de préstamos, reservas de pools o coeficientes de salud.
Estos valores están en el almacenamiento del contrato y la mayoría de los protocolos no ofrecen mecanismos nativos para enviarlos a los consumidores.

El mejor método actual es suscribir los encabezados de bloques y consultar en cada uno.
Los logs solo indican que el estado puede haber cambiado, pero no codifican el estado económico final; reconstruirlo requiere lectura explícita y acceso a estados históricos.
Los agentes podrían beneficiarse de un flujo inverso.
En lugar de hacer polling a cientos de contratos, pueden recibir actualizaciones estructuradas y precomputadas, enviadas directamente a su entorno de ejecución.

Una arquitectura push reduce consultas redundantes, disminuye la latencia en la percepción de cambios y permite empaquetar estados en actualizaciones semánticamente claras, en lugar de interpretarlos desde el almacenamiento bruto.
Este cambio no es trivial. Requiere infraestructura de suscripción, lógica de filtrado y transformación de cambios en eventos económicos ejecutables por los agentes.
Pero, a medida que los agentes participan de forma continua en lugar de ser consultores intermitentes, el costo de la ineficiencia del pull aumenta.

Ver a los agentes como consumidores persistentes en lugar de clientes ocasionales puede ser más coherente con su modo de operación.
¿Es realmente mejor una infraestructura push? La respuesta aún no está clara.
Los cambios masivos en estado generan problemas de filtrado, y los proxies deben gestionar explícitamente sincronización y consistencia.
Por ello, la recuperación no estandarizada no solo complica la integración, sino que limita rendimiento, sincronización y precisión.
La falta de un esquema unificado para consultar datos económicos hace que, incluso con primitivas similares, los estados expuestos varíen según el contrato y su implementación.
Esta diferencia estructural es la raíz de la fricción de datos.

La fricción en la ejecución surge porque muchas capas de interacción convierten intención, revisión y validación en flujos diseñados alrededor de interfaces, wallets y supervisión humana.
En escenarios minoristas y de decisiones subjetivas, estas funciones aún las realiza la intervención humana.
Para los sistemas autónomos, esas funciones deben formalizarse y codificarse directamente.

La blockchain, basada en la lógica de contratos, garantiza la ejecución determinista, pero no asegura que las transacciones reflejen la intención del usuario, cumplan con restricciones de riesgo o logren resultados económicos previstos.
En los procesos actuales, las interfaces y los humanos llenan ese vacío.
Las interfaces combinan operaciones, los wallets proporcionan la firma final, y los usuarios o supervisores toman decisiones estratégicas de forma informal en la última etapa.
A menudo, en condiciones de información incompleta, juzgan si la transacción es segura, si la cotización es aceptable, o si deben ajustar slippage, cambiar rutas o abandonar.

Los agentes eliminan o reducen este ciclo.
Deben reemplazar esas funciones humanas con mecanismos automáticos que interpreten intención, ejecuten estrategias y verifiquen resultados, sin depender solo de la confirmación de transacciones.
Una arquitectura centrada en la intención puede trasladar más carga de “cómo” ejecutar a un solucionador especializado, que garantice que las restricciones se cumplan antes de aceptar la ejecución.

La mayoría de las operaciones en DeFi son multietapa.
Una asignación de rendimiento puede requerir autorización, intercambio, depósito, préstamo y staking.
Algunas etapas son transacciones independientes, otras se pueden agrupar mediante múltiples llamadas o contratos de enrutamiento.
Los humanos toleran algunas etapas, que retornan a la interfaz para continuar.
Los agentes necesitan orquestar procesos deterministas: si alguna etapa falla, deben decidir reintentar, redirigir, revertir o pausar.

Esto genera nuevos modos de fallo en los procesos humanos:
Desplazamiento de estado entre decisión y on-chain; ejecución no atómica y parcial; riesgos en permisos y aprobaciones; costos ocultos en rutas y ejecución.

La fricción en la ejecución radica en que la capa de interacción descentralizada se basa en firmas de wallets humanas como control final.
Este paso soporta la validación de intención, tolerancia al riesgo y juicios informales de “¿es razonable?”.
Al eliminar al humano, la ejecución se vuelve un problema de control: el agente debe transformar objetivos en comportamientos, aplicar restricciones automáticas y verificar resultados en incertidumbre.

Este reto está en muchos sistemas autónomos, pero en blockchain es especialmente severo:
La ejecución involucra capital, contratos heterogéneos y entornos adversariales.
Los humanos toman decisiones heurísticas y aprenden por prueba y error.
Los agentes deben hacer lo mismo a velocidad de máquina, en entornos dinámicos.
Por eso, decir que “el agente solo envía transacciones” subestima la dificultad.
Enviar transacciones es la parte más sencilla.

El diseño de la blockchain no provee nativamente la capa semántica y de colaboración que los agentes necesitan.
Su objetivo es garantizar la ejecución determinista y el consenso en entornos adversariales.
La capa de interacción basada en humanos, con interfaces, revisión y supervisión, evoluciona sobre esa base.

Los agentes invierten esa estructura.
Eliminan o reducen la intervención humana, requiriendo que esas funciones se implementen en máquina.
Esta transformación revela fricciones estructurales en descubrimiento, confianza, obtención de datos y ejecución.
Estas fricciones no surgen porque la ejecución sea inviable, sino porque la infraestructura asume que siempre hay intervención humana entre interpretación y envío.

Superar estas brechas probablemente requerirá construir nuevas infraestructuras en múltiples capas:
Normalizar estados económicos entre protocolos en middleware legible por máquina;
Servicios de indexación o llamadas remotas para posiciones, coeficientes y oportunidades;
Registros para mapeo de contratos y verificación de tokens;
Y marcos para codificar restricciones, gestionar flujos multietapa y validar objetivos programáticamente.

Algunas brechas provienen de características del sistema sin permisos: despliegue abierto, identidad débil, heterogeneidad de interfaces.
Otras dependen de las herramientas, estándares y mecanismos de incentivos actuales, que con la expansión del uso de agentes y la competencia entre protocolos, podrían cerrarse.

A medida que los sistemas autónomos gestionen capital, ejecuten estrategias y se integren con aplicaciones en cadena, la arquitectura actual de interacción se volverá aún más evidente.
La mayoría de las fricciones descritas reflejan cómo las herramientas y modelos de interacción en la blockchain giran en torno a flujos mediadores humanos;
Algunas surgen de la naturaleza abierta, heterogénea y adversarial del sistema sin permisos;
Y otras son problemas comunes en entornos complejos con sistemas autónomos.

El principal reto no es que los agentes firmen transacciones, sino que tengan vías confiables para interpretar semánticamente, validar confianza y ejecutar estrategias, en un entorno que combina decisiones humanas y software.