Por que a implementação de agentes de IA inteligentes na blockchain enfrenta tantos obstáculos?

Escrito por: Zack Pokorny

Traduzido por: Chopper, Foresight News

A implementação de inteligências artificiais na blockchain não tem sido fácil; embora a blockchain possua características de programabilidade e sem permissão, ela carece de camadas de abstração semântica e de coordenação adequadas para agentes inteligentes. A instituição de pesquisa em criptografia Galaxy publicou um relatório de estudo que aponta que agentes inteligentes enfrentam quatro fricções estruturais na cadeia: descoberta de oportunidades, validação confiável, leitura de dados e execução de processos. A infraestrutura existente ainda é centrada na interação humana, dificultando o gerenciamento autônomo de ativos e a execução de estratégias por IA, tornando esses fatores os principais obstáculos para uma implementação em larga escala de agentes na blockchain. A seguir, a tradução integral do relatório:

O cenário de aplicação e as capacidades dos agentes inteligentes de IA já estão evoluindo. Eles começam a executar tarefas de forma autônoma, sendo desenvolvidos para possuir e configurar capitais, explorar negociações e estratégias de rendimento. Apesar de essa mudança experimental ainda estar em estágio inicial, ela difere radicalmente do padrão anterior, onde agentes eram principalmente ferramentas de socialização e análise.

A blockchain está se tornando um campo de testes natural para essa evolução. Ela é sem permissão, combinável, possui um ecossistema de aplicações de código aberto, e seus dados são acessíveis de forma igualitária a todos os participantes, além de todos os ativos na cadeia serem, por padrão, programáveis.

Isso levanta uma questão estrutural: se a blockchain é programável e sem permissão, por que os agentes autônomos ainda enfrentam fricções? A resposta não está na viabilidade da execução, mas na quantidade de carga semântica e de coordenação que essa execução carrega. 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 identidades ou objetivos de coordenação.

Algumas fricções derivam de falhas na arquitetura de sistemas sem permissão, enquanto 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 software e fluxos de trabalho que requerem intervenção manual para serem construídos.

Arquitetura da blockchain e agentes de IA

A arquitetura da blockchain é centrada em consenso e execução determinística, não em 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, taxas de retorno, índices 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, convertendo o estado específico de cada protocolo em formas mais acessíveis.

Muitos processos de finanças descentralizadas (DeFi), especialmente aqueles voltados para investidores de varejo e decisões subjetivas, ainda giram em torno de interação via interface de usuário e assinatura de transações. Esse modelo centrado na interface de usuário se expandiu com a popularização de investidores de varejo, mesmo que muitas atividades na cadeia já sejam conduzidas por máquinas. O fluxo de interação padrão ainda é: intenção → interface → transação → confirmação. Operações programadas seguem um caminho diferente, 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 que mudam continuamente.

Quando uma infraestrutura otimizada para validação de negociações é usada para interpretar estados econômicos, avaliar crédito e otimizar comportamentos em torno de objetivos claros, as fricções começam a aparecer. Essas diferenças derivam parcialmente das características de sistemas sem permissão e heterogêneos, e parcialmente do estado atual das ferramentas, gestão de conteúdo e infraestrutura de mercado. Na prática, muitas funções de alto nível ainda dependem de software e fluxos de trabalho que requerem intervenção humana.

Comparação entre processos de agentes e estratégias tradicionais

Antes de explorar as diferenças entre infraestrutura de blockchain e sistemas de agentes de IA, é importante esclarecer: qual é a distinção entre processos de comportamento mais autônomos e os sistemas algorítmicos tradicionais na cadeia?

A diferença não está no grau de automação, complexidade, parametrização ou capacidade de autoajuste. Sistemas algorítmicos 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 está na capacidade de lidar com cenários não previstos na fase de construção.

Sistemas algorítmicos tradicionais, por mais complexos que sejam, apenas executam lógica pré-definida para padrões estabelecidos. Precisam de interfaces, interpretadores, avaliações de estado de contrato com significado econômico, regras de julgamento de crédito e padrões de decisão codificados. Quando encontram algo fora do padrão, simplesmente ignoram ou falham. Não podem raciocinar sobre cenários desconhecidos, apenas verificar se o cenário atual corresponde a um modelo conhecido.

Como uma máquina automática de “pato digestor”, que imita comportamentos biológicos, mas cujos movimentos são todos pré-programados.

Um algoritmo tradicional que monitora o mercado de empréstimos DeFi pode identificar contratos conhecidos ou novos implantes que correspondam a padrões familiares. Mas, se aparecer um novo componente de empréstimo com uma interface desconhecida, o sistema não consegue avaliá-lo. É necessário que humanos inspecionem o contrato, entendam seu funcionamento, julguem se há oportunidade de exploração e escrevam lógica de integração. Depois, o algoritmo pode interagir com ele. Humanos interpretam, algoritmos executam. Sistemas de agentes baseados em modelos fundamentais mudaram essa fronteira, permitindo que eles:

Interpretem objetivos ambíguos ou incompletos, como “maximizar rendimento evitando riscos excessivos”, que requerem interpretação semântica. O que é risco excessivo? Como equilibrar retorno e risco? Sistemas tradicionais precisam definir esses critérios com precisão antecipadamente, enquanto agentes podem interpretar intenções, julgar e ajustar sua compreensão com base no feedback.

Generalizem para interfaces desconhecidas. Agentes podem ler código de contratos desconhecidos, analisar documentação ou interfaces binárias de aplicativos nunca antes acessados, inferindo suas funções econômicas. Não precisam de parsers específicos para cada protocolo. Ainda que essa capacidade seja imperfeita, agentes podem tentar interagir com sistemas não previstos na fase de construção.

Raciocinem em ambientes de incerteza e normatividade. Quando sinais de crédito são ambíguos ou incompletos, modelos básicos podem ponderar probabilisticamente esses sinais, ao invés de aplicar regras binárias. Um smart contract é padronizado? O token é legítimo? Sistemas tradicionais seguem regras fixas ou não têm resposta? Agentes podem inferir níveis de confiança.

Interpretem erros e ajustem estratégias. Quando surgem imprevistos, agentes podem raciocinar sobre a causa e decidir como reagir. Em contraste, algoritmos tradicionais apenas executam módulos de captura de exceções, retransmitindo a mensagem de erro sem interpretá-la.

Essas capacidades existem na prática, mas ainda imperfeitas. Modelos básicos podem gerar alucinações, interpretar erroneamente conteúdos e tomar decisões aparentemente confiantes, mas incorretas. Em ambientes adversariais e envolvendo capital (como controle de código ou ativos), “tentar interagir com sistemas não previstos” pode significar perdas financeiras. O ponto central não é que agentes já possam executar essas funções de forma confiável, mas que eles podem tentar de formas que sistemas tradicionais não conseguem, e que futuras infraestruturas podem tornar esses testes mais seguros e confiáveis.

Essa diferença deve ser vista mais como um continuum do que como uma fronteira absoluta. Alguns sistemas tradicionais incorporarão raciocínio aprendido, enquanto alguns agentes podem depender de regras codificadas em pontos críticos. Essa distinção é direcional, não binária. Sistemas de agentes transferem mais interpretação, avaliação e adaptação para raciocínio em tempo de execução, ao invés de regras fixas na fase de construção. Isso é fundamental para entender as fricções, pois o que os agentes tentam fazer é exatamente aquilo que algoritmos tradicionais evitam. Algoritmos tradicionais, ao deixar humanos escolherem contratos na fase de construção, evitam fricções de descoberta; ao usar listas brancas mantidas por operadores, evitam fricções de controle; ao usar parsers pré-construídos para protocolos conhecidos, evitam fricções de dados; e ao operar dentro de limites de segurança pré-estabelecidos, evitam fricções de execução. Humanos realizam trabalho semântico, de crédito e de estratégia na fase de construção, enquanto algoritmos executam dentro de escopo definido. No início, os processos de agentes na cadeia podem seguir esse padrão, mas o valor central dos agentes está em transferir a descoberta, avaliação de crédito e estratégia para raciocínio em tempo de execução, e não na fase de construção.

Eles tentarão descobrir e avaliar oportunidades desconhecidas, raciocinar sobre normatividade sem regras fixas, interpretar estados heterogêneos sem parsers específicos, e executar estratégias mesmo com objetivos ambíguos. A existência de fricções não decorre de agentes fazerem algo semelhante a algoritmos, mas de fazerem coisas completamente diferentes: operar em um espaço de comportamento aberto, dinâmico e interpretativo, ao invés de um sistema fechado e pré-integrado.

Fricções

Do ponto de vista estrutural, essa contradição não decorre de falhas no consenso da blockchain, mas do modo de operação de toda a pilha de interação que evolui ao seu redor.

A blockchain garante a transição de estados determinística, consenso sobre o estado final e determinismo final. Ela não tenta codificar na camada de protocolo interpretações econômicas, validações de intenção ou rastreamento de objetivos. Essas funções sempre foram desempenhadas por interfaces front-end, carteiras, indexadores e outras camadas de coordenação off-chain, que sempre requereram intervenção humana.

Mesmo participantes experientes seguem esse padrão de interação. Investidores de varejo interpretam o estado via dashboards, escolhem ações via interface, assinam transações via carteira, sem validação formal do resultado. Corretoras automatizam a execução, mas ainda dependem de humanos para selecionar protocolos, verificar exceções e atualizar integrações diante de mudanças de interface. Em ambos os casos, os protocolos garantem apenas a execução correta, enquanto a interpretação de intenções, tratamento de exceções e adaptação a novas oportunidades são tarefas humanas.

Sistemas de agentes comprimem ou eliminam essa divisão. Eles precisam reconstruir programaticamente estados com significado econômico, avaliar o progresso de objetivos e verificar resultados, ao invés de apenas confirmar transações na cadeia. Na blockchain, essa carga é ainda mais evidente, 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 revisão centralizada. Protocolos garantem apenas a execução correta, não a interpretabilidade econômica, a padronização de contratos ou a conformidade com intenções do usuário, nem a descoberta programática de oportunidades.

A seguir, uma análise das etapas do ciclo operacional de agentes, destacando as fricções em cada fase: descoberta de contratos e oportunidades, validação de legalidade, leitura de estados econômicos e execução de ações.

Fricção na descoberta

A fricção surge porque o espaço de DeFi se expande sem permissão, com relevância e legalidade sendo filtradas por humanos através de redes sociais, mercados e ferramentas na cadeia. Novos protocolos aparecem 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 podem formar critérios informais para distinguir quais partes do espaço de atuação possuem valor econômico e credibilidade, embora esse consenso seja muitas vezes não oficial, assimétrico e parcialmente dependente de terceiros e de triagens humanas.

É possível fornecer agentes com dados e sinais de crédito filtrados, mas eles não possuem as intuições humanas para interpretar esses sinais. Do ponto de vista on-chain, todos os contratos implantados são igualmente descobríveis. Protocolos legítimos, bifurcações maliciosas, implantações de teste e projetos abandonados existem na forma de bytecode acessí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 (que podem implantar outros contratos programaticamente) e monitorar formação de liquidez, para decidir quais contratos devem entrar no escopo de decisão. Esse processo não é apenas de busca, mas também de avaliação de relevância e confiabilidade, para determinar se um contrato deve ser considerado uma oportunidade.

Identificar candidatos é apenas o primeiro passo. Após a descoberta preliminar, os contratos precisam passar por processos de validação de padrão e autenticidade, descritos na próxima seção. Agentes devem primeiro verificar se o contrato realmente corresponde ao que aparenta ser, antes de incluí-lo no escopo de decisão.

Fricção na descoberta não é apenas detectar novos comportamentos de implantação. Sistemas algorítmicos maduros já podem fazer isso dentro de seus escopos. Monitorar eventos de fábrica do Uniswap e incluir pools automaticamente é uma descoberta dinâmica. Fricções aparecem em dois níveis superiores: validar se o contrato descoberto é legítimo, e determinar se está relacionado a objetivos abertos, além de apenas corresponder a estratégias pré-definidas.

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 oportunidades de risco ajustado para maximizar retorno”, não podem apenas usar filtros baseados em estratégias. Precisam avaliar as oportunidades com base no objetivo, o que exige interpretar interfaces desconhecidas, inferir funções econômicas e decidir se a oportunidade deve entrar no escopo de decisão. Essa é uma questão de autonomia geral, agravada pelo fato de que a blockchain intensifica esse problema.

Fricções na camada de controle

A fricção na camada de controle surge porque a validação de identidade e legitimidade geralmente ocorre fora do protocolo, dependendo de triagens, governança, documentação, interfaces e julgamento de operadores. Ainda hoje, muitos fluxos de trabalho dependem de intervenção humana na fase de validação. A blockchain garante execução determinística e consenso 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 de páginas web como método informal de validação. Acessam domínios oficiais (normalmente encontrados via plataformas de agregação como DeFiLlama ou contas sociais verificadas do projeto) e veem esses sites como mapeamentos padrão entre conceitos humanos e endereços de contratos. Depois, a interface front-end forma um padrão confiável, identificando endereços oficiais, tokens a serem usados e entradas seguras.

O Homem de Ferro de 1789 era uma máquina de jogar xadrez, que parecia operar de forma autônoma, mas na verdade dependia de um operador humano oculto

Por padrão, agentes não conseguem interpretar marcas, sinais sociais de autenticação ou “oficialidade” via contexto social. Podem receber dados filtrados desses sinais, mas convertê-los em hipóteses confiáveis de crédito de máquina requer registros, estratégias ou lógica de validação explícitos. Podem ser configurados com listas brancas de operadores, endereços certificados e estratégias de crédito. O problema não é a impossibilidade de obter esses sinais sociais, mas que, na expansão dinâmica do espaço de atuação, manter essas proteções é dispendioso, e na ausência ou imperfeição dessas medidas, agentes carecem de mecanismos de validação padrão que os humanos usam por padrão.

Sistemas de agentes na cadeia já enfrentaram consequências reais de validações de crédito frágeis. No caso do influenciador de criptomoedas Orangie, há relatos de agentes que supostamente depositaram fundos em contratos honeypot. Em outro caso, o agente Lobstar Wilde, por erro de estado ou contexto, transferiu uma grande quantidade de tokens para um “pedinte” online. Esses exemplos, embora não sejam o núcleo do argumento, ilustram como erros de validação de crédito, leitura de estado e estratégias podem levar a perdas financeiras.

O problema não é a dificuldade de descobrir contratos, mas a ausência de uma noção nativa de “contrato oficial de uma aplicação” na blockchain. Essa ausência é, em certa medida, uma característica de sistemas sem permissão, não uma falha de projeto, mas ainda assim gera dificuldades de coordenação. O problema deriva parcialmente de arquiteturas de identidade fracas e abertas, e parcialmente de registros, padrões e mecanismos de crédito ainda imaturos. Agentes que interagem com Aave v3, por exemplo, precisam determinar quais endereços são considerados padrão, e se esses endereços podem ser atualizados via proxy, se estão sob governança, ou se estão em mudança de controle.

Humans resolvem isso via documentação, interfaces e redes sociais. Agentes precisam verificar:

Padrões de proxy e pontos de implementação

Permissões de gestão e mecanismos de bloqueio de tempo

Parâmetros de controle de governança

Correspondência de bytecode / API de implantação conhecida

Na ausência de registros padrão, “oficialidade” torna-se uma questão de inferência. Isso significa que agentes não podem tratar contratos como configurações estáticas. Devem manter listas de validação contínua, ou verificar a oficialidade via proxy e governança em tempo de execução, ou correr riscos de interagir com contratos abandonados, comprometidos ou falsificados. Em infraestruturas tradicionais, a identidade de serviço é mantida por nomes, credenciais e controles de acesso gerenciados por instituições. Na cadeia, um contrato pode ser chamado e funcionar normalmente, mas do ponto de vista econômico ou de negócio, pode não ser considerado padrão.

A autenticidade de tokens e seus metadados é uma questão semelhante. Tokens parecem auto-descritivos, mas seus metadados não têm autoridade, sendo apenas bytes retornados pelo código. Um exemplo clássico é o WETH (Wrapped Ether). O código do contrato WETH amplamente utilizado define claramente nome, símbolo e precisão.

Isso parece uma identificação, mas não é. Qualquer contrato pode definir:

symbol() = WETH

decimals() = 18

name() = Wrapped Ether

e implementar a interface ERC-20 padrão. Os métodos name(), symbol() e decimals() são apenas funções de leitura pública que retornam qualquer valor definido pelo deployer. Na Ethereum, há quase 200 tokens com o nome “Wrapped Ether”, símbolo “WETH” e 18 decimais. Sem consultar CoinGecko ou Etherscan, é impossível distinguir qual “WETH” é o padrão.

O que os agentes enfrentam é exatamente essa situação. A blockchain não verifica unicidade, não consulta registros, nem impõe restrições. Você pode implantar 500 contratos, todos retornando os mesmos metadados. Existem alguns métodos de verificação tentativos (como checar se o saldo de ETH e a oferta total correspondem, consultar profundidade de liquidez em DEXs populares, verificar se o token é usado como garantia em empréstimos), mas nenhum fornece prova absoluta. Cada método depende de hipóteses de limiar ou de validações recursivas de outros contratos.

Assim como encontrar a “verdadeira” saída em um labirinto requer orientação externa, na blockchain não há sinais nativos de padrão.

Por isso, listas de tokens e registros atuam como camadas de filtragem off-chain. Elas fornecem uma maneira de mapear o conceito “WETH” para um endereço específico, o que explica por que carteiras e interfaces de front-end mantêm listas brancas ou dependem de plataformas confiáveis de agregação. Para agentes, o problema central não é apenas a confiabilidade dos metadados, mas que a identidade padrão geralmente é estabelecida por redes sociais ou instituições, e não nativamente pelo protocolo. 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 ao protocolo.

Fricção de dados

Para agentes que otimizam a alocação entre protocolos de DeFi, é necessário padronizar cada oportunidade como um objeto econômico: taxa de retorno, profundidade de liquidez, parâmetros de risco, estrutura de taxas, fontes de oráculos, etc. Do ponto de vista de integração de sistemas, isso é comum. Mas 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. Esses elementos são essenciais para comparar oportunidades, simular alocações e monitorar riscos.

Normalmente, a blockchain 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 de forma clara como conceitos econômicos, nem que possam ser acessados de forma consistente entre protocolos.

Assim, conceitos como mercado, posição ou índice 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 usá-la, mas herdam modelos de terceiros, atrasos e hipóteses de confiança; ou precisam reconstruir essas abstrações por conta própria.

Esse problema é mais evidente em diferentes protocolos. Por exemplo, o valor de uma cota de um vault, a taxa de garantia de um mercado de empréstimos, a profundidade de liquidez de pools em DEXs ou a taxa de recompensa de contratos de staking são componentes básicos com significado econômico, mas não possuem interfaces padronizadas. Cada protocolo tem sua própria forma de acesso, estrutura e convenções. Mesmo dentro de uma mesma categoria, há variações.

Exemplo de fragmentação em mercados de empréstimo

Os mercados de empréstimo ilustram bem essa questão. Seus conceitos econômicos são amplamente padronizados: oferta e demanda de liquidez, taxas de juros, taxas de garantia, limites de crédito e limites de liquidação, mas os métodos de acesso variam.

No Aave v3, a enumeração de reservas e a obtenção do estado de reserva são etapas distintas. O fluxo típico é:

Listar ativos de reserva, retornando uma matriz de endereços de tokens.

Para cada ativo, obter dados básicos de liquidez e taxa via outro trecho de código,

que retorna uma estrutura com o volume de liquidez, índice de taxa e flags de configuração, por exemplo:

Por outro lado, no Compound v3, cada implantação corresponde a um mercado único (USDC, USDT, ETH, etc.), sem uma estrutura de reserva unificada. Em vez disso, é necessário fazer múltiplas chamadas para montar uma visão de snapshot do mercado:

Utilização básica

Volume total

Taxa de juros

Configuração de ativos de garantia

Parâmetros de configuração global

Cada chamada retorna apenas um subconjunto do estado econômico. “Mercado” não é um objeto de primeiro nível, mas uma estrutura inferida construída por múltiplas chamadas.

Para o agente, ambos os protocolos representam mercados de empréstimo; mas, na prática de integração, eles são sistemas de obtenção de dados completamente diferentes. Não há um padrão comum. Em vez disso, o agente precisa usar métodos diferentes de enumeração de ativos para cada protocolo, fazendo múltiplas chamadas para montar o estado.

Fragmentação gera atrasos e riscos de inconsistência

Além da diferença estrutural, essa fragmentação introduz atrasos e riscos de inconsistência. Como o estado econômico não é exposto como um objeto de mercado atômico, o agente precisa fazer múltiplas chamadas remotas para reconstruir o snapshot. Cada chamada adicional aumenta o atraso, o risco de limitação de taxa e a probabilidade de descompasso com o bloco. Em ambientes voláteis, taxas de juros podem mudar entre a leitura e a execução, e se o bloco não for explicitamente fixado, os parâmetros podem estar desatualizados em relação ao estado de liquidez. Interfaces de usuário e back-ends de agregação ajudam a mitigar esses problemas, mas agentes que acessam diretamente RPCs precisam gerenciar explicitamente sincronização, lotes e consistência temporal. Assim, a falta de uma abordagem padronizada de recuperação de dados econômicos não só dificulta a integração, como também limita desempenho, sincronização e confiabilidade.

Sem uma solução padronizada de recuperação de dados econômicos, mesmo que os protocolos exponham primitivas financeiras similares, seus estados variam de acordo com a implementação e composição. Essa heterogeneidade é o núcleo da fricção de dados.

Desalinhamento potencial de fluxo de dados

O acesso ao estado econômico na blockchain é essencialmente 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. Essa abordagem reflete a função central da blockchain: validação sob demanda, não manutenção de uma visão de estado persistente de aplicação.

Primitivas push existem. Assinaturas via WebSocket podem transmitir eventos de novos blocos e logs em tempo real, mas esses não carregam a maior parte do estado econômico, a menos que o protocolo publique redundâncias explicitamente. Agentes não podem assinar tópicos de mercado de empréstimos, reservas de pools ou índices de saúde de posições via assinatura na cadeia. 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 prática atual é assinar cabeçalhos de blocos e consultar novamente a cada bloco. Logs podem indicar mudanças de estado, mas não codificam o estado econômico final; reconstruí-lo ainda requer leitura explícita e acesso ao histórico de estados.

Sistemas de agentes podem se beneficiar de um fluxo reverso. Em vez de fazer polling de centenas de contratos, podem receber atualizações estruturadas e pré-calculadas, enviadas diretamente ao ambiente de execução. Uma arquitetura push reduz consultas redundantes, diminui o atraso na percepção de mudanças de estado, e permite que camadas intermediárias empacotem atualizações com significado semântico claro, ao invés de interpretar dados brutos.

Essa mudança não é trivial. Requer infraestrutura de assinatura, lógica de filtragem de relevância e mecanismos de transformação de mudanças de armazenamento em eventos econômicos acionáveis. Mas, à medida que agentes se tornam participantes contínuos, e não apenas clientes ocasionais, o custo do polling se torna mais alto. Ver agentes como consumidores contínuos, ao invés de clientes esporádicos, pode ser uma direção mais eficiente.

Ainda não há consenso se uma infraestrutura push é realmente superior. Mudanças de estado em massa criam problemas de filtragem, e os agentes precisam determinar quais mudanças são relevantes, o que reintroduz 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 automatizados. Com o crescimento do uso de agentes, explorar modelos alternativos pode ser valioso.

Fricções na execução

A fricção na execução decorre do fato de que muitas camadas de interação atualmente empacotam a conversão de intenções, auditoria de transações e validação de resultados em fluxos de trabalho centrados em interfaces, carteiras e supervisão por operadores humanos. Em cenários de varejo e 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 garante a execução determinística com base na lógica do contrato, mas não garante que a transação reflita a intenção do usuário, respeite limites de risco ou atinja resultados econômicos esperados. Nesse fluxo, interfaces de usuário e intervenção humana preenchem essa lacuna.

Operações sequenciais de interface (troca, autorização, depósito, empréstimo), assinatura final via carteira, e julgamento estratégico implícito na decisão final, muitas vezes são feitos de forma não formal. Os usuários ou operadores avaliam se a transação é segura, se a cotação é aceitável, e podem ajustar parâmetros ou desistir. Sistemas de agentes eliminam esse ciclo, exigindo que a automação substitua essas funções humanas, que precisam ser formalizadas:

Integração de intenções. Objetivos humanos como “transferir meus stablecoins para a melhor oportunidade de retorno ajustado ao risco” precisam ser convertidos em planos de ação concretos: qual protocolo, qual mercado, qual caminho de token, quanto, quais autorizações, qual sequência. Para humanos, isso é feito implicitamente via interface; para agentes, deve ser formalizado.

Execução de estratégias. Clicar em “enviar” não é apenas assinar, mas também verificar implicitamente se a transação atende a restrições: tolerância a slippage, limite de alavancagem, índice mínimo de saúde, contratos na whitelist ou “não permitir contratos upgradáveis”. Agentes precisam codificar essas restrições como regras verificáveis por máquina:

O sistema de execução deve validar se o grafo de chamadas proposto atende a essas regras antes de transmitir.

Validação de resultados. Enviar uma transação na cadeia não garante que o objetivo foi atingido. Mesmo uma transação bem-sucedida pode não alcançar o resultado desejado: slippage fora do limite, tamanho de posição abaixo do limite de crédito, ou mudança de taxas entre simulação e execução. Humanos fazem validação informal via interface após a execução. Agentes precisam avaliar formalmente as condições de pós-execução.

Isso introduz a necessidade de verificações de completude, além de simples execução. Uma arquitetura centrada na intenção pode transferir parte do esforço de “como” executar para solucionadores especializados, que avaliem se a execução atende a restrições de resultado. Ao transmitir intenções assinadas, ao invés de dados brutos de chamada, agentes podem especificar restrições de resultado, que só podem ser satisfeitas por mecanismos de protocolo ou solucionadores que as atendam.

Fluxos de trabalho multi-etapa e modos de falha

A maior parte das operações de DeFi é, na essência, multi-etapa. Uma alocação de rendimento pode envolver autorização → troca → depósito → empréstimo → staking. Algumas etapas podem ser transações independentes, outras podem ser encadeadas via múltiplas chamadas ou contratos de roteamento. Humanos podem tolerar etapas parciais, retornando à interface para continuar. Agentes precisam de orquestração determinística: se qualquer etapa falhar, devem decidir por re-tentar, redirecionar ou pausar.

Isso gera novos modos de falha que muitas vezes ficam ocultos na operação humana:

Desalinhamento de estado entre decisão e on-chain. Entre simulação e execução, taxas de juros, utilização ou liquidez podem mudar. Humanos aceitam essa variabilidade; agentes precisam definir limites aceitáveis e forçar sua conformidade.

Execução não atômica e resultados parciais. Algumas operações podem ocorrer em múltiplas transações ou gerar resultados parciais. Agentes precisam acompanhar estados intermediários e verificar se o estado final atende ao objetivo.

Risco de limites de autorização e aprovação. Humanos assinam autorizações de forma intuitiva; agentes precisam raciocinar sobre limites (quantidade, usuário, prazo) como parte de estratégias de segurança, não apenas como passos de interface.

Custos de roteamento e execução implícita. Humanos confiam em rotas padrão e configurações de interface. Agentes devem incorporar slippage, risco de retirada máxima, custos de gas e impacto de preço na função objetivo.

Controle nativo na execução: o problema

A fricção na execução centraliza-se na questão de que a camada de interação atual usa assinatura de carteiras humanas como controle final. Essa etapa carrega validação de intenção, tolerância a risco e julgamento informal de “razoabilidade”. Sem humanos, a execução vira um problema de controle: agentes precisam transformar objetivos em padrões de comportamento, executar estratégias automaticamente e validar resultados sob incerteza. Esse desafio é comum em muitos sistemas autônomos, mas na blockchain é especialmente severo: a execução envolve capital, contratos desconhecidos e ambientes adversariais. Humanos tomam decisões heurísticas e ajustam por tentativa e erro. Agentes precisam fazer o mesmo em velocidade de máquina, muitas vezes em ambientes dinâmicos. Assim, “apenas submeter uma transação” é a parte mais fácil.

Conclusão

A concepção original da blockchain não foi de fornecer nativamente camadas semânticas e de coordenação para agentes inteligentes. Seu objetivo é garantir execução determinística e consenso de estados em ambientes adversariais. Essa base sustenta uma camada de interação centrada na leitura de estado por humanos, na seleção de ações via interface e na validação manual de resultados.

Sistemas de agentes desafiam essa arquitetura. Eliminam operadores humanos, exigindo que funções de interpretação, aprovação e validação sejam implementadas como mecanismos nativos de máquina. Essa mudança revela quatro fricções estruturais: descoberta, validação de crédito, obtenção de dados e execução. Essas fricções não surgem porque a execução seja inviável, mas porque a infraestrutura atual ainda assume intervenção humana na interpretação de estado e submissão de transações.

Superar esses obstáculos provavelmente requer uma nova infraestrutura em múltiplas camadas: normalização de estados econômicos entre protocolos, serviços de indexação ou chamadas remotas para variáveis semânticas como posições e índices de saúde, registros padrão de contratos e validação de tokens, além de frameworks para codificar estratégias, gerenciar fluxos multi-etapa e validar resultados de forma programática. Algumas dessas lacunas decorrem de características de sistemas sem permissão — implantação aberta, identidade fraca, interfaces heterogêneas — e outras dependem de padrões, incentivos e ferramentas que, com a expansão do uso de agentes e a otimização de protocolos para integração autônoma, podem ser resolvidas.

À medida que agentes autônomos começarem a gerenciar capital, executar estratégias e interagir diretamente com aplicações na cadeia, a arquitetura atual de interação se tornará cada vez mais evidente. A maior parte das fricções descritas reflete o fato de que as ferramentas e os modelos de interação na blockchain ainda giram em torno de fluxos de trabalho mediados por humanos; algumas derivam da natureza sem permissão, heterogênea e adversarial do ambiente; outras são problemas universais de ambientes complexos com agentes autônomos.

O principal desafio não é fazer agentes assinarem transações, mas fornecer meios confiáveis para que eles realizem tarefas que atualmente dependem de julgamento humano e software na interpretação semântica, validação de crédito e execução de estratégias.