Um agente de inteligência artificial pode entender perfeitamente o que você pediu e ainda assim fracassar por um motivo banal: a ferramenta escolhida não funciona. A API está fora do ar, a autenticação expirou, o endpoint mudou, a documentação está errada ou o serviço simplesmente nunca esteve operacional. Para o usuário, tudo isso aparece como uma resposta ruim. Para o agente, porém, são problemas diferentes que exigem uma capacidade comum: perceber a confiabilidade das ferramentas enquanto trabalha.
Essa distinção ganha importância à medida que os agentes deixam de ser simples conversadores e passam a operar sistemas reais. Eles consultam bancos de dados, enviam mensagens, atualizam planilhas, fazem reservas, executam código e movimentam processos empresariais. Nesses ambientes, encontrar uma ferramenta semanticamente adequada é apenas o primeiro passo. É preciso encontrar uma ferramenta que também esteja disponível e consiga concluir a tarefa.
O limite da busca por similaridade
Grande parte dos sistemas atuais seleciona ferramentas como um mecanismo de busca. O agente transforma a solicitação em uma representação vetorial, compara essa representação com descrições de APIs e devolve as opções mais parecidas. Se a pessoa pede “encontre voos baratos para São Paulo”, o sistema procura ferramentas relacionadas a passagens, viagens e preços.
Essa estratégia resolve uma parte importante do problema, mas trata o catálogo como se fosse estático. Uma descrição pode parecer perfeita e, mesmo assim, apontar para um serviço com link quebrado, autenticação ausente ou comportamento instável. O mecanismo de busca sabe que a ferramenta parece relevante, mas não sabe que ela falhou cinco minutos atrás.
Na prática, relevância e disponibilidade são dimensões diferentes. Uma ferramenta de calendário pode ser a escolha semanticamente correta para criar uma reunião, mas uma segunda ferramenta, menos parecida na descrição, pode ser a única que está funcionando naquele momento. Um agente confiável precisa combinar as duas informações.
O que o RATED acrescenta
O paper RATED: Reliability-Aware AI Agent Tool Retrieval via Execution Dynamics propõe uma arquitetura para fazer exatamente isso. O sistema começa com um codificador de busca treinado para relacionar pedidos humanos às ferramentas adequadas. Em seguida, um módulo leve reorganiza as candidatas usando o resultado das execuções anteriores.
A ideia é inspirada nos chamados bandidos contextuais. A cada solicitação, o sistema observa o contexto, escolhe uma ferramenta e recebe um retorno parcial: a execução funcionou ou falhou. Esse sinal atualiza a preferência pelas opções disponíveis. A ferramenta não precisa ser removida definitivamente do catálogo. Basta perder posições quando acumula falhas e recuperar espaço quando volta a funcionar.
Essa escolha é importante porque evita uma solução pesada. O agente não precisa retreinar seu modelo de linguagem depois de cada erro. Também não precisa esperar um grande lote de experiências para ajustar seu comportamento. O módulo de confiabilidade aprende de forma incremental, usando o próprio fluxo operacional como fonte de informação.
O resultado é uma mudança de perspectiva. A recuperação de ferramentas deixa de ser uma etapa isolada antes da execução e passa a ser um processo contínuo. O sistema não pergunta apenas “qual ferramenta descreve melhor esta tarefa?”, mas também “qual ferramenta tem maior probabilidade de concluí-la agora?”.
Um catálogo com problemas reais
Para avaliar a proposta, os pesquisadores criaram o EcoAgent, um benchmark reunindo 5.172 definições de ferramentas extraídas de quatro ecossistemas de agentes: LangChain, CrewAI, LlamaIndex e n8n. O conjunto inclui nomes, descrições funcionais, endpoints e informações de autenticação. Também foram associados sinais de qualidade de metadados, como consistência entre nome e descrição, credibilidade da origem e qualidade da documentação.
A fotografia não é confortável. Apenas 2.940 ferramentas, ou 56,8% do catálogo, atingiram o limiar definido pelos autores para serem consideradas confiáveis segundo esses metadados. Isso não significa que todas as demais estejam permanentemente quebradas, mas revela uma realidade pouco discutida: catálogos de ferramentas crescem mais rápido do que sua manutenção.
O benchmark também combina consultas sintéticas e consultas derivadas de tarefas reais. Na parte real, são 6.379 consultas únicas e 9.946 pares verificados entre pedidos e ferramentas. Essa separação ajuda a evitar um resultado artificial em que o modelo apenas memoriza padrões criados pelo próprio conjunto de treinamento.
Há ainda um limite metodológico que merece atenção. A confiabilidade dos metadados é calculada automaticamente, e não por uma auditoria humana completa de cada serviço. O resultado é útil para comparação, mas não substitui testes de produção. Uma API pode ter documentação impecável e ainda apresentar instabilidade em horários de pico.
Os números que mudam a conversa
Nos testes apresentados, o RATED melhorou em 52,2% o MRR, uma métrica que avalia a posição da ferramenta correta no ranking, em comparação com o recuperador de APIs do ToolLLM em consultas reais. Isso mostra que o sistema consegue combinar melhor o significado do pedido com a qualidade das candidatas.
O resultado mais expressivo aparece quando os autores injetam falhas em 30% das ferramentas. Um recuperador estático escolheu uma opção defeituosa em 86,2% dos casos em que a ferramenta mais relevante semanticamente estava indisponível. O RATED reduziu essa taxa para 2,9%. Em outra configuração do experimento, a taxa ficou em 2,5%.
Essa diferença representa uma mudança operacional concreta. Um agente estático pode repetir a mesma chamada várias vezes, insistindo em uma API quebrada porque sua descrição continua sendo a mais parecida. Um agente orientado por feedback reconhece o padrão, rebaixa a opção e tenta uma alternativa. A memória do erro passa a fazer parte da capacidade de agir.
O custo adicional também foi pequeno: cerca de 0,172 milissegundo por etapa em relação à inferência baseada apenas no codificador. Isso é relevante porque sistemas empresariais frequentemente trocam alguns milissegundos por uma redução substancial de falhas, retrabalho e intervenção humana.
O resultado, contudo, não significa que o problema esteja resolvido. O próprio estudo observa que o desempenho em consultas conhecidas não garante robustez diante de ferramentas novas. O chamado caminho de inicialização a frio, quando ainda não existem experiências suficientes sobre uma ferramenta recém-adicionada, continua sendo um desafio.
O impacto para empresas brasileiras
No Brasil, a questão aparece em praticamente toda automação conectada a serviços externos. Um agente de atendimento pode precisar consultar estoque, calcular frete, emitir nota fiscal e registrar o contato em um CRM. Um agente financeiro pode depender de bancos, sistemas de cobrança e serviços de validação. Um agente de vendas pode combinar anúncios, comércio eletrônico, mensageria e análise de dados.
Quando uma dessas integrações falha, o custo não é apenas técnico. O cliente recebe uma promessa que não foi cumprida, o funcionário precisa assumir a tarefa e a empresa pode perder uma oportunidade. Em setores regulados, uma tentativa repetida com parâmetros incorretos também pode gerar risco de bloqueio, cobrança duplicada ou registro inconsistente.
Uma camada de recuperação consciente da confiabilidade permitiria criar políticas mais realistas. O agente poderia preferir uma ferramenta nacional quando ela estiver estável, usar uma alternativa internacional em caso de indisponibilidade ou solicitar aprovação humana antes de tentar uma operação sensível. A confiabilidade deixaria de ser uma propriedade fixa do catálogo e passaria a ser uma variável observada pelo sistema.
Isso também muda a forma de comprar tecnologia. Em vez de avaliar apenas a quantidade de integrações oferecidas por uma plataforma, as empresas deveriam perguntar quantas ferramentas são monitoradas, como os erros são registrados, quais alternativas existem e se o agente consegue explicar por que mudou de rota. Um catálogo enorme não é necessariamente um catálogo útil.
O novo trabalho da engenharia de agentes
O RATED sugere que a engenharia de agentes terá de se aproximar da engenharia de operações. Descrições, embeddings e prompts continuam importantes, mas não bastam. Será necessário medir disponibilidade, latência, taxa de erro, qualidade de autenticação, custo e capacidade de recuperação.
Uma arquitetura madura deveria registrar o resultado de cada chamada sem transformar esse histórico em uma caixa-preta impossível de auditar. Também deveria separar falhas temporárias, como um limite de requisições, de falhas estruturais, como um endpoint inexistente. O mesmo sinal binário de sucesso ou fracasso pode esconder causas muito diferentes.
Há ainda uma questão de governança. Se o agente aprende a evitar uma ferramenta, alguém precisa conseguir verificar por quê. Caso contrário, um problema transitório pode excluir um fornecedor por tempo demais, ou um serviço malicioso pode simular sucessos e manipular o ranking. Feedback operacional é poderoso, mas precisa de trilhas de auditoria, limites de exploração e mecanismos para reiniciar ou revisar as preferências aprendidas.
De buscador de APIs a operador adaptativo
A contribuição mais importante do RATED não está apenas na queda da taxa de falhas. Ela está em tratar a seleção de ferramentas como uma decisão que acontece durante a execução, e não antes dela. Essa diferença parece pequena, mas muda o desenho inteiro de um agente.
Agentes confiáveis não serão aqueles que conhecem o maior número de APIs. Serão aqueles que sabem quando uma integração deixou de ser uma boa opção, encontram uma rota alternativa e comunicam a incerteza antes de produzir um efeito irreversível. A inteligência prática de um sistema não está somente em escolher certo na primeira tentativa. Está também em aprender rapidamente quando a realidade contradiz sua escolha.
Para empresas e desenvolvedores, a mensagem é direta: cada chamada de ferramenta deve ser tratada como uma experiência operacional. O agente precisa observar o resultado, atualizar suas hipóteses e decidir novamente. No mundo real, onde serviços caem, credenciais expiram e catálogos envelhecem, a confiabilidade não pode ser presumida. Ela precisa ser aprendida.