TEAL evolui ferramentas de agentes de código sem rótulos

O que aconteceu

O arXiv publicou em 19 de outubro de 2026 o artigo "Unsupervised Tool Evolution for Coding Agents in Data-Lake Analytics" (arXiv:2610.27327v1), na categoria Computer Science > Artificial Intelligence. O texto descreve o TEAL, sigla de Tool Evolution for Analytics over data Lakes, um método que constrói e refina automaticamente uma biblioteca de ferramentas e de habilidades de uso para um agente Worker, sem depender de rótulos.

O alvo é uma repetição cara. Agentes de código respondem perguntas analíticas sobre um data lake descobrindo, limpando e combinando os dados relevantes. Terminada a resposta, descartam esse trabalho e recomeçam do zero na pergunta seguinte. A evolução de ferramentas, que cria e aprimora instrumentos reutilizáveis entre tarefas, encaixa exatamente nesse desperdício.

Como um rótulo de referência para uma pergunta de data lake exigiria um especialista resolvendo o problema antes, os autores trabalharam no regime não supervisionado. Dois agentes propõem ferramentas a partir de evidências complementares. O Explorer parte do próprio data lake. O Critic parte das trajetórias do Worker. Uma proposta só é mantida se o Worker adotar a ferramenta em uma nova execução sem passos extras e se qualquer resposta alterada tiver sustentação na evidência da trajetória.

O paper também apresenta o TEAL-Q, que gera perguntas sintéticas para alimentar a evolução quando não existem perguntas reais disponíveis.

Contexto

A avaliação usa dois benchmarks, KramaBench e LakeQA, com quatro LLMs no papel de Worker. O desenho experimental impõe step budgets, tetos para o número de passos que o Worker pode dar por pergunta. É justamente sob limite apertado que o método mostra força.

Com orçamento de 10 ou 15 passos, o TEAL melhora todos os Workers nos dois benchmarks. O Sonnet-5, avaliado com 15 passos, sobe 9,3 pontos no KramaBench e 21,7 pontos no LakeQA. O resultado contraria a intuição de que restrição de passos só piora a vida do agente: o paper relata que um orçamento mais apertado produz feedback melhor para a evolução das ferramentas.

O exemplo mais claro está no LakeQA. Uma biblioteca evoluída com 20 passos e depois implantada sem alteração em um cenário de 30 passos marca 68,3. Fica acima da linha de base, de 59,6, e também acima de uma biblioteca evoluída diretamente com 30 passos, que chega a 64,2.

Por que importa

Empresas que rodam analises sobre data lakes pagam duas vezes pelo mesmo trabalho: uma quando o agente descobre como limpar e cruzar os dados, outra quando ele refaz tudo na pergunta seguinte. O TEAL transforma esse esforço em ativo, na forma de uma biblioteca de ferramentas que sobrevive entre tarefas.

O detalhe que muda a conta é a ausência de rótulos. Sem ground truth, não é preciso um especialista resolver cada pergunta antes de o agente aprender. Isso reduz o custo de partida de qualquer pipeline analítico automatizado, porque o gargalo deixa de ser a anotação humana.

O TEAL-Q reforça esse ponto. Uma biblioteca evoluída apenas com perguntas sintéticas tem desempenho comparável ao de uma biblioteca evoluída com perguntas reais. Ou seja, times que ainda não têm um histórico de consultas podem começar mesmo assim.

Impacto

Os ganhos aparecem exatamente onde os agentes costumam falhar na prática: quando o orçamento de passos é curto e cada ação precisa valer a pena. Um salto de 21,7 pontos no LakeQA com o Sonnet-5 em 15 passos indica que a biblioteca evoluída reduz o número de ações necessárias para chegar à resposta.

O caso da biblioteca evoluída a 20 passos e mantida intacta a 30 passos aponta para reaproveitamento real. A ferramenta não foi ajustada para o cenário mais folgado e ainda assim superou tanto a linha de base quanto a versão treinada diretamente nele. Para quem opera agentes em produção, isso significa que a evolução pode acontecer sob restrição de recursos e ser transferida depois.

O efeito colateral é de ordem arquitetural. A biblioteca de ferramentas passa a ser um componente persistente do sistema, separado do modelo que a usa. Trocar o LLM Worker deixa de significar recomeçar a curadoria do zero.

O que muda

O trabalho desloca o esforço de engenharia do prompt para a manutenção de um acervo de ferramentas. A pergunta deixa de ser apenas qual modelo usar e passa a incluir o que armazenar e como julgar se uma ferramenta nova merece entrar na biblioteca.

O critério de aceitação proposto pelos autores é estrito e vale como referência para quem for implementar algo parecido: a mudança precisa ser adotada pelo Worker em uma nova execução sem passos adicionais e qualquer resposta que mudar precisa ter respaldo na trajetória registrada. Isso cria um filtro automático contra ferramentas que parecem boas na teoria e atrapalham na prática.

O que vem agora

O paper não anuncia produto, cronograma de lançamento nem adoção por alguma empresa. Os autores fecham o texto dizendo que os resultados mostram ser possível evoluir ferramentas úteis sem rótulos e que esperam inspirar trabalhos futuros sobre o que evoluir e como obter feedback na evolução de agentes não supervisionada.

O artigo está disponível no arXiv com PDF e uma versão HTML experimental, e ainda não há data divulgada para publicação em conferência.

Fontes

• arXiv: Unsupervised Tool Evolution for Coding Agents in Data-Lake Analytics (arXiv:2610.27327v1) https://arxiv.org/abs/2610.27327