Ultimato! A baleia gigante de IA está prestes a despertar, o ecossistema $ETH enfrenta uma "reorganização estrutural", a sua posição aguenta o embate?

A blockchain foi construída para máquinas, mas não foi projetada para agentes inteligentes.
Análise de mercado aponta que a implementação de agentes de IA na cadeia não é fluida.
Embora a blockchain possua características de permissão zero e programabilidade, ela carece de uma camada de abstração semântica e de coordenação adaptada a agentes.
Relatórios de pesquisa identificaram quatro fricções estruturais enfrentadas por agentes na cadeia: descoberta de oportunidades, validação de confiança, leitura de dados e fluxo de execução.
A infraestrutura atual ainda é centrada na interação humana, dificultando o suporte à gestão autônoma de ativos e à execução de estratégias por IA, formando o principal gargalo para uma implementação em larga escala.

O cenário de aplicação de agentes de IA está evoluindo.
Eles começam a executar tarefas de forma autônoma e são desenvolvidos para possuir e configurar capitais, explorar estratégias de negociação e rendimento.
Essa mudança experimental ainda está em estágio inicial, mas difere radicalmente do modelo anterior, onde agentes eram usados principalmente como ferramentas sociais e de análise.
Devido às suas características de permissão zero, composição, dados abertos e ativos programáveis por padrão, a blockchain se tornou um campo de testes natural.
Isso levanta uma questão estrutural: se a blockchain é programável e sem permissão, por que ainda há fricções para agentes autônomos?
A resposta não está na viabilidade da execução, mas na quantidade de carga semântica e de coordenação acima da execução.

A blockchain garante a correção na transição de estados, mas geralmente não fornece abstrações nativas de protocolo, como explicações econômicas, normatização de identidade ou coordenação de objetivos.
Algumas fricções derivam de falhas na arquitetura de sistemas sem permissão, outras refletem o estado atual das ferramentas, gestão de conteúdo e infraestrutura de mercado.
Na prática, muitas funções de camada superior ainda dependem de softwares e fluxos de trabalho que requerem intervenção humana.

O design da blockchain gira em torno de consenso e execução determinística, não de interpretação semântica.
Ela expõe primitivas de baixo nível como slots de armazenamento, logs de eventos e trilhas de chamadas, ao invés de objetos econômicos padronizados.
Assim, conceitos abstratos como posições, retornos, fatores de saúde ou profundidade de liquidez geralmente precisam ser reconstruídos off-chain por indexadores, camadas de análise de dados, interfaces front-end e APIs.

Muitos processos de operações financeiras descentralizadas, especialmente os voltados ao retail, ainda giram em torno de interação do usuário via interface, assinatura de transações e assinatura de cada operação.
Esse modelo centrado na interface de usuário se expandiu com a popularização de investidores individuais, mesmo que muitas atividades na cadeia já sejam conduzidas por máquinas.
Operações programadas seguem outro caminho, mas também têm suas limitações: desenvolvedores escolhem contratos e conjuntos de ativos na fase de construção, e depois executam algoritmos dentro de um escopo fixo.
Ambos os modelos não se adaptam a sistemas que precisam descobrir, avaliar e combinar operações dinamicamente, em tempo de execução, com objetivos em constante mudança.

Quando uma infraestrutura otimizada para validação de negociações é usada para interpretar estados econômicos, avaliar crédito e otimizar comportamentos com objetivos claros, as fricções começam a aparecer.
Parte dessa discrepância vem das características de sistemas sem permissão e heterogêneos, e outra parte do fato de que ferramentas de interação ainda dependem de revisão manual e intermediários front-end.

Qual a diferença entre processos de comportamento mais autônomos e sistemas tradicionais de algoritmos na cadeia?
A diferença não está no nível de automação ou complexidade.
Sistemas tradicionais podem ser altamente parametrizados, capazes de descobrir novos contratos e tokens, alocar fundos entre estratégias variadas e reequilibrar com base no desempenho.
A verdadeira distinção é se o sistema consegue lidar com cenários imprevistos na fase de construção.

Sistemas tradicionais, por mais complexos que sejam, apenas executam lógica pré-definida para padrões estabelecidos.
Precisam de interfaces predefinidas, avaliadores que mapeiam estados de contrato para significados econômicos, regras de crédito e padrões de decisão codificados.
Quando encontram algo fora do padrão, simplesmente ignoram ou falham.
Não conseguem raciocinar sobre cenários desconhecidos, apenas verificam se o contexto atual corresponde a modelos conhecidos.

Sistemas baseados em modelos fundamentais mudam essa fronteira.
Podem aprender a interpretar objetivos ambíguos ou incompletos, generalizar interfaces desconhecidas, raciocinar em ambientes de incerteza de confiança e normatização, explicar erros e ajustar-se.
Essas capacidades existem na prática, embora imperfeitas.
Modelos fundamentais podem gerar alucinações, julgamentos equivocados e decisões aparentemente seguras, mas podem levar a perdas financeiras em ambientes adversos e de capital.

O ponto central não é que agentes hoje possam executar essas funções de forma confiável, mas que eles podem tentar fazê-lo de maneiras que sistemas tradicionais não permitem, e que futuras infraestruturas tornarão esses testes mais seguros e confiáveis.
Essa diferença deve ser vista como um estado contínuo, não uma fronteira absoluta.
Agentes transferirão mais interpretação, avaliação e autoajuste para raciocínio em tempo de execução, ao invés de regras pré-definidas na construção.

Isso é fundamental para entender as fricções, pois o que agentes tentam fazer é justamente aquilo que algoritmos tradicionais evitam.
Algoritmos tradicionais evitam descobrir fricções ao deixar que humanos selecionem contratos na fase de construção, manter listas brancas, usar parsers pré-construídos para protocolos conhecidos e operar dentro de limites de segurança predefinidos.
O trabalho semântico, de crédito e de estratégia é feito antecipadamente por humanos, enquanto os algoritmos apenas executam dentro de um escopo definido.

No início, processos de agentes na cadeia podem seguir esse padrão, mas seu valor central está em transferir a descoberta, avaliação de crédito e avaliação de oportunidades para raciocínio em tempo de execução, não na fase de construção.
Eles tentarão descobrir e avaliar oportunidades desconhecidas, raciocinar sobre padrões sem regras rígidas, interpretar estados heterogêneos sem parsers pré-definidos e executar estratégias mesmo com objetivos ambíguos.
A fricção surge porque eles fazem coisas radicalmente diferentes: operam em um espaço de comportamento aberto e dinâmico, ao invés de um sistema fechado e pré-integrado.

Do ponto de vista estrutural, essa contradição não vem de uma falha no consenso da blockchain, mas do modo como a pilha de interação geral ao seu redor funciona.
A blockchain garante a transição de estados determinística, o consenso sobre o estado final e a certeza final.
Ela não tenta codificar interpretações econômicas, validação de intenções ou rastreamento de objetivos na camada de protocolo.
Essas funções sempre foram responsabilidade de interfaces front-end, carteiras, indexadores e camadas de coordenação off-chain, que sempre requerem intervenção humana.

Mesmo participantes experientes seguem esse padrão de interação.
Investidores de varejo interpretam o estado via dashboards, escolhem operações via interface, assinam transações com carteiras, e não validam formalmente os resultados.
Corretoras automatizam a execução, mas ainda dependem de humanos para selecionar contratos, verificar exceções e atualizar integrações diante de mudanças de interface.
Em ambos os casos, os contratos garantem apenas a execução correta, enquanto a interpretação de intenções, o tratamento de exceções e a adaptação a novas oportunidades ficam por conta de humanos.

Sistemas de agentes podem até eliminar essa divisão.
Devem programaticamente reconstruir estados economicamente significativos, avaliar o progresso de objetivos e verificar resultados, não apenas confirmar transações na cadeia.
Na blockchain, essa carga é ainda maior, pois agentes operam em ambientes abertos, adversariais e de rápida mudança, onde novos contratos, ativos e caminhos de execução podem surgir sem validação centralizada.
Os contratos garantem apenas a execução correta, não a interpretabilidade econômica, a padronização de contratos ou a descoberta programática de oportunidades.

A seguir, serão analisadas as fricções em cada fase do ciclo de operação do agente: descoberta de contratos e oportunidades, validação de legitimidade, obtenção de estados com significado econômico e execução de ações com base em objetivos.

Essas fricções surgem porque o espaço de DeFi se expande sem permissão, enquanto a relevância e legitimidade são filtradas por humanos via redes sociais, mercados e ferramentas na cadeia.
Novos protocolos emergem por anúncios, mas também passam por filtros de front-end, listas de tokens, plataformas de análise de dados e formação de liquidez.
Com o tempo, esses sinais tendem a criar critérios de julgamento para distinguir quais partes do espaço de atuação possuem valor econômico e são suficientemente confiáveis.

Podem fornecer dados e sinais de crédito filtrados para agentes, mas eles próprios não possuem as intuições humanas ao interpretar esses sinais.
De uma perspectiva on-chain, todos os contratos implantados são igualmente descobertos.
Protocolos legítimos, forks maliciosos, testes e projetos abandonados existem na forma de bytecode chamável.
A blockchain não codifica quais contratos são importantes ou seguros.

Por isso, agentes precisam construir seus próprios mecanismos de descoberta: escanear eventos de implantação, identificar padrões de interface, rastrear contratos de fábrica e monitorar formação de liquidez para decidir quais contratos incluir na decisão.
Esse processo não é apenas de busca, mas de avaliação de se esses contratos devem fazer parte do espaço de decisão do agente.
Identificar candidatos é apenas o primeiro passo.
Após a descoberta inicial, contratos precisam passar por processos de validação de padrão e autenticidade.

Fricções de descoberta não se referem apenas a detectar novos comportamentos de implantação.
Sistemas avançados já podem fazer isso dentro de seus próprios escopos estratégicos.
Monitorar eventos de fábricas de Uniswap e incluir automaticamente novos pools é um exemplo de descoberta dinâmica.
Fricções aparecem em níveis superiores: determinar se um contrato descoberto é legítimo e se está relacionado a objetivos abertos, ao invés de apenas corresponder a tipos de estratégia pré-definidos.

A lógica de descoberta dos buscadores está fortemente ligada às suas estratégias.
Eles sabem que tipos de interfaces procurar, pois suas estratégias já definiram isso.
Mas agentes que executam tarefas mais amplas, como “configurar risco para maximizar oportunidades”, não podem apenas confiar em filtros baseados em estratégia.
Precisam avaliar as oportunidades com base no objetivo, interpretando interfaces desconhecidas, inferindo funções econômicas e decidindo se devem entrar no espaço de decisão.
Isso é, em certa medida, uma questão de autonomia geral, mas a blockchain intensifica esse problema.

A fricção na camada de controle ocorre porque identidade e legitimidade geralmente são decididas fora do protocolo, por filtros, governança, documentação, interfaces e julgamento de operadores.
Na prática, humanos ainda desempenham papel importante nesses processos.
A blockchain garante execução determinística e certeza final, mas não garante que o chamador esteja interagindo com o contrato pretendido.
Essa validação de intenção é externalizada para contextos sociais, sites e triagens humanas.

No fluxo atual, humanos usam a camada de confiança do site como método informal de validação.
Acessam domínios oficiais e veem esses sites como mapeamentos padrão entre conceitos humanos e endereços de contratos.
Depois, a interface front-end forma uma base confiável, identificando endereços oficiais, tokens a usar e entradas seguras.

Agentes, por padrão, não conseguem interpretar marcas, sinais sociais ou “oficialidade” via contexto social.
Podem receber dados filtrados desses sinais, mas para transformá-los em hipóteses de confiança duradouras, precisam de registros, estratégias ou lógica de validação explícitos.
Podem receber listas brancas, endereços certificados e estratégias de crédito fornecidas por operadores.
O problema não é totalmente a ausência de contexto social, mas que, na expansão dinâmica do espaço de comportamento, manter essas proteções é custoso, e sua ausência ou imperfeição deixa agentes sem mecanismos de validação padrão usados por humanos.

Sistemas de agentes na cadeia já enfrentaram consequências reais de fraquezas na validação de crédito.
Em um caso, um agente supostamente depositou fundos em um contrato honeypot.
Em outro, por erro de estado ou contexto, um agente transferiu grandes saldos de tokens para um “pedinte” na rede.
Esses exemplos não são o núcleo do argumento, mas ilustram como falhas na validação de crédito, interpretação de estado e estratégias podem levar a perdas financeiras.

O problema não é a dificuldade de descobrir contratos, mas a ausência de conceitos nativos de “contrato oficial de uma aplicação”.
Essa ausência é, em parte, uma característica de sistemas sem permissão, não uma falha de projeto, mas ainda gera dificuldades de coordenação para sistemas autônomos.
Parte disso vem de uma arquitetura de identidade fraca e aberta, e parte de registros, padrões e mecanismos de crédito ainda imaturos.

Agentes que tentam interagir com Aave v3 precisam determinar quais endereços são padrão, se esses endereços são imutáveis, se podem ser atualizados por proxy ou se estão sob governança pendente.
Humans resolvem isso via documentação, interfaces e redes sociais.
Agentes precisam verificar: modo de proxy e detalhes de implementação; permissões de gestão e locks de tempo; parâmetros de controle de governança; correspondência de bytecode e APIs conhecidas.

Na ausência de registros padrão, “oficialidade” se torna uma questão de raciocínio.
Agentes não podem tratar contratos como configurações estáticas.
Devem manter listas brancas de validação contínua, ou verificar via proxy e governança em tempo de execução, assumindo riscos de interação com contratos abandonados, danificados ou falsificados.

Em software tradicional e infraestrutura de mercado, identidade de serviço é mantida por nomes, credenciais e controles de acesso geridos por entidades.
Na cadeia, um contrato pode ser chamado e funcionar normalmente, mas, do ponto de vista do chamador, não possui uma identidade padrão econômica ou de negócio.

A autenticidade de tokens e seus metadados é uma questão relacionada.
Tokens parecem capazes de se auto-descrever, mas seus metadados não têm autoridade, sendo apenas bytes retornados pelo código.
Um exemplo clássico é o WETH encapsulado.
O código amplamente utilizado do contrato WETH define claramente nome, símbolo e precisão, mas isso é apenas uma identidade aparente.
Qualquer contrato pode implementar a mesma interface ERC-20, com funções como name(), symbol() e decimals(), que retornam qualquer valor definido pelo deployer.

Na prática, há cerca de 200 tokens no Ethereum chamados “Wrapped Ether”, com símbolo “WETH” e 18 casas decimais.
Sem consultar CoinGecko ou Etherscan, é difícil distinguir qual “WETH” é o padrão.
O agente enfrenta essa situação.
A blockchain não verifica a unicidade, não consulta registros e não impõe restrições.

Existem métodos de verificação tentativos na cadeia, como checar se saldo de ETH corresponde ao total emitido, consultar profundidade de liquidez em DEXs populares ou verificar se é usado como garantia em protocolos de empréstimo, mas nenhum fornece prova definitiva.
Cada método depende de hipóteses de limiar ou de validações recursivas de outros contratos.
Essa é a razão de existirem listas de tokens e registros como camadas de filtragem off-chain.

Para agentes, o problema central não é apenas a baixa confiabilidade dos metadados, mas que a identidade padrão geralmente é estabelecida por sinais sociais ou instituições, não pelo protocolo nativo.
Identificadores confiáveis na cadeia são endereços de contrato, mas mapear intenções humanas como “trocar por USDC” para o endereço correto ainda depende de filtros, registros, listas brancas ou outros mecanismos de crédito não nativos.

Agentes que otimizam a alocação entre protocolos DeFi precisam padronizar cada oportunidade como objetos econômicos: retorno, profundidade de liquidez, risco, taxas, fontes de oráculos, etc.
De certa forma, isso é um problema comum de integração de sistemas.
Porém, na blockchain, a heterogeneidade de protocolos, exposição direta ao capital, múltiplos estados de chamada e a ausência de um padrão econômico unificado aumentam essa carga.

A blockchain geralmente não expõe objetos econômicos padronizados na camada de protocolo.
Ela expõe slots de armazenamento, logs de eventos e resultados de funções, e os objetos econômicos precisam ser inferidos ou reconstruídos a partir deles.
Os contratos garantem apenas que as chamadas retornem valores corretos, não que esses valores possam ser interpretados claramente como conceitos econômicos ou que possam ser acessados de forma consistente entre protocolos.

Assim, conceitos como mercado, posição ou fator de saúde não são primitivas do protocolo.
São reconstruídos off-chain por indexadores, plataformas de análise de dados, interfaces front-end e APIs, convertendo estados heterogêneos em abstrações utilizáveis.
Usuários humanos geralmente veem apenas essa camada padronizada.
Agentes também podem usar essa camada, mas herdam modelos de terceiros, atrasos e hipóteses de confiança;
caso contrário, precisam reconstruir essas abstrações por conta própria.

Esse problema se torna mais evidente em diversos protocolos.
Preços de fundos, taxas de empréstimo, profundidade de liquidez de pools, taxas de recompensa de contratos de staking — todos são componentes econômicos, mas não há interfaces padronizadas para acessá-los.
Cada protocolo tem suas próprias formas de obtenção, estrutura e convenções.
Mesmo dentro de uma mesma categoria, há diferenças na implementação.

O mercado de empréstimos exemplifica bem essa questão.
Conceitos econômicos como oferta, demanda, taxas, limites de crédito e limites de liquidação são comuns, mas os métodos de acesso variam.
No Aave v3, a enumeração de mercados e a obtenção de reservas são etapas distintas.
No Compound v3, cada implantação corresponde a um único mercado, sem uma estrutura de reserva unificada, exigindo múltiplas chamadas para montar uma visão do estado.

Para agentes, ambos são mercados de empréstimo, mas, na prática, representam sistemas de obtenção de dados completamente diferentes.
Não há um padrão unificado.
Agentes precisam usar métodos diferentes para enumerar ativos, fazendo múltiplas chamadas para reconstruir o estado.

Além da falta de uniformidade, essa fragmentação introduz atrasos e riscos de inconsistência.
Como o estado econômico não é exposto como uma entidade única e atômica, o agente precisa fazer múltiplas chamadas remotas para montar uma visão do estado.
Cada chamada adicional aumenta o risco de atrasos, limitação de taxa e inconsistência de blocos.
Em ambientes voláteis, a taxa de juros pode mudar entre a leitura e a ação, e sem travar o bloco, os parâmetros podem não refletir o mesmo momento.

Usuários dependem de caches de UI e back-ends agregadores para mitigar esses problemas.
Proxies que acessam diretamente RPCs precisam gerenciar explicitamente sincronização, lotes e consistência temporal.
A busca não padronizada por dados econômicos causa dificuldades na integração, limita desempenho, sincronização e precisão.
Sem uma solução padronizada de consulta de dados econômicos, mesmo que protocolos exponham primitivas financeiras similares, seus estados dependem de detalhes de implementação.
Essa diversidade estrutural é a essência da fricção de dados.

O acesso ao estado econômico na cadeia é essencialmente uma operação de pull, mesmo que sinais de execução possam ser streamados.
Sistemas externos consultam os nós para obter o estado necessário, ao invés de receber atualizações contínuas e estruturadas.
Esse padrão reflete a função central da blockchain: verificação sob demanda, não manutenção de uma visão de estado contínua.

Existem primitivas de push, como assinaturas de WebSocket para eventos e blocos, mas elas não carregam a maior parte do estado econômico, a menos que o protocolo publique explicitamente.
Agentes não podem simplesmente assinar assinaturas de uso de empréstimos, reservas ou fatores de saúde.
Esses valores estão armazenados no armazenamento do contrato, e a maioria dos protocolos não fornece mecanismos nativos para empurrar essas informações para consumidores downstream.

A melhor abordagem atual é assinar cabeçalhos de blocos e consultar novamente a cada bloco.
Logs indicam possíveis mudanças, mas não codificam o estado econômico final; reconstruí-lo ainda exige leitura explícita e acesso ao histórico.
Agentes podem se beneficiar de processos reversos, recebendo atualizações estruturadas e pré-calculadas, ao invés de fazer polling de centenas de contratos.

Arquiteturas de push reduzem consultas redundantes, atrasam a percepção de mudanças e permitem que camadas intermediárias empacotem atualizações com significado semântico claro, ao invés de interpretar dados brutos.
Essa mudança reversa não é trivial; requer infraestrutura de assinatura, lógica de filtragem e transformação de mudanças de armazenamento em eventos econômicos acionáveis.
À medida que agentes se tornam participantes contínuos, e não apenas consultores ocasionais, o custo de polling aumenta.

Ver agentes como consumidores contínuos, ao invés de clientes esporádicos, pode ser mais adequado ao funcionamento de sistemas autônomos.
Ainda não há consenso se uma infraestrutura de push é realmente superior.
Muitos estados mudam rapidamente, dificultando filtragem, e o agente precisa determinar o que é relevante, reintroduzindo uma semântica de pull em outro nível.
O problema não é a arquitetura de pull em si, mas que ela não foi projetada pensando em consumidores persistentes.
Com o crescimento do uso de agentes, talvez valha a pena explorar modelos alternativos.

A fricção na execução surge porque muitas camadas de interação atuais embalam intenções, auditorias e validações de resultados em fluxos de trabalho centrados em front-ends, carteiras e supervisores humanos.
No cenário retail e de decisão subjetiva, essa supervisão ainda é feita por humanos.
Para sistemas autônomos, essas funções precisam ser formalizadas e codificadas diretamente.

A blockchain, ao garantir execução determinística, não garante que transações sigam a intenção do usuário, respeitem limites de risco ou atinjam resultados econômicos esperados.
No fluxo atual, interfaces e humanos preenchem essa lacuna.
Interfaces combinam operações, carteiras finalizam “auditoria e envio”, e humanos ou operadores fazem julgamentos estratégicos na última etapa.
Eles muitas vezes julgam de forma informal, com informações incompletas, se a transação é segura, se a cotação é aceitável.
Se a transação falhar ou gerar resultados inesperados, eles ajustam, tentam novamente, mudam slippage ou abandonam.

Sistemas de agentes removem essa cadeia de decisão humana.
Devem substituir essas funções por automação: interpretar intenções, executar estratégias e validar resultados.
Isso exige mecanismos de verificação, não apenas execução de transações.

Arquiteturas centradas em intenção podem aliviar parte do problema ao transferir mais responsabilidades de execução para solucionadores especializados.
Ao assinar intenções com assinatura digital, ao invés de chamadas brutas, agentes podem definir restrições baseadas em resultados, que só podem ser atendidas por mecanismos de solução ou protocolos.

A maior parte das operações DeFi é multi-etapa.
Configurar um rendimento pode envolver autorização, troca, depósito, empréstimo e staking.
Algumas etapas podem ser transações independentes, outras podem ser encadeadas ou agrupadas em contratos de roteamento.
Humans toleram partes do processo, que continuam na interface.
Agentes, por outro lado, precisam de orquestração determinística: se qualquer etapa falhar, devem decidir entre tentar novamente, roteirizar, reverter ou pausar.

Isso gera novos modos de falha que antes eram ocultos: drift de estado entre decisão e on-chain; execução não atômica ou parcial; riscos de autorização e aprovação; custos ocultos de roteamento.

O ponto central é que a camada de interação DeFi ainda depende de assinaturas humanas como controle final.
Esse passo carrega validações de intenção, tolerância ao risco e julgamentos informais de “razoabilidade”.
Removendo humanos, a execução vira um problema de controle: agentes precisam transformar objetivos em comportamentos, automatizar restrições e validar resultados sob incerteza.

Esse desafio é comum a muitos sistemas autônomos, mas na blockchain é especialmente severo: execução envolve capital, contratos heterogêneos e ambientes adversariais.
Humans tomam decisões por heurísticas e tentam corrigir por tentativa e erro.
Agentes precisam fazer isso na velocidade de máquina, muitas vezes em ambientes dinâmicos.
Portanto, dizer que “agentes apenas enviam transações” subestima a complexidade.
Enviar transações é a parte mais fácil.

A blockchain não foi projetada para fornecer nativamente camadas semânticas e de coordenação para agentes.
Seu objetivo é garantir execução determinística e consenso de estado em ambientes adversariais.
A evolução dessas camadas de interação sempre foi centrada na leitura de estado por humanos, na seleção de operações via interface e na validação manual de resultados.

Agentes desafiam essa arquitetura.
Eles removem a necessidade de interpretação, aprovação e validação humanas, exigindo que essas funções sejam implementadas por máquinas.
Essa mudança revela fricções estruturais em quatro dimensões: descoberta, validação de crédito, obtenção de dados e fluxo de execução.
Essas fricções não surgem por inviabilidade da execução, mas porque a infraestrutura ao redor da blockchain ainda assume, na maioria dos casos, intervenção humana entre leitura de estado e submissão de transações.

Superar essas lacunas provavelmente requer uma nova infraestrutura em múltiplas camadas:
normalizar estados econômicos entre protocolos em middlewares legíveis por máquina;
serviços de indexação ou chamadas remotas para posições, fatores de saúde e oportunidades;
registros de mapeamento de contratos e validação de tokens;
e frameworks de execução que codifiquem restrições, gerenciem fluxos multi-etapa e validem objetivos programaticamente.

Algumas lacunas vêm das características de sistemas sem permissão: implantação aberta, identidade fraca, interfaces heterogêneas.
Outras dependem de ferramentas, padrões e incentivos atuais, que podem melhorar à medida que o uso de agentes cresce e os protocolos se tornam mais integrados.

À medida que agentes gerenciam capital, executam estratégias e interagem diretamente com aplicações na cadeia, a arquitetura de interação atual se tornará mais evidente.
A maior parte das fricções descritas reflete a evolução de ferramentas e modelos de interação centrados em trabalho humano;
parte delas decorre da natureza aberta, heterogênea e adversarial de sistemas sem permissão;
e uma parcela significativa é um problema comum em ambientes complexos.

O principal desafio não é fazer agentes assinarem transações, mas fornecer meios confiáveis para que possam interpretar semântica, validar crédito e executar estratégias, trabalho atualmente compartilhado por software e humanos.