Seu Agente Esquece Tudo. Três Abordagens Para Fazê-lo Aprender — e Uma Pergunta Que Ninguém Responde

Um estudo do MIT concluiu que 95% dos pilotos de IA generativa fracassam. Não por falha dos modelos. Porque os agentes não se adaptam.

Cada sessão começa do zero. O agente relê transcrições brutas. Redescobre as mesmas restrições. Repete os mesmos erros. Três meses depois, o piloto funciona exatamente como no primeiro dia. A diretoria encerra o projeto.

Duas publicações de abril de 2026 atacam esse problema por ângulos distintos. A IBM Research publicou o ALTK-Evolve, um sistema que converte trajetórias de agentes em diretrizes pontuadas e reutilizáveis. Rahul Garg, escrevendo no blog de Martin Fowler, descreveu o Feedback Flywheel, um framework para equipes capturarem sinais sistematicamente a partir de suas ferramentas de IA e realimentarem a infraestrutura compartilhada.

Os dois trabalhos são sérios. Os dois avançam o campo. E os dois deixam a mesma pergunta sem resposta.

Primeira abordagem: ensinar o agente a partir dos próprios erros

O ALTK-Evolve, de Vatche Isahagian e colegas na IBM Research, parte de uma observação simples: agentes repetem erros porque releem rastros brutos de execução em vez de extrair princípios deles.

A arquitetura opera em duas fases. A fase descendente captura trajetórias do agente por meio de ferramentas de observabilidade como Langfuse e OpenTelemetry. Cada chamada de ferramenta, cada passo de raciocínio, cada resultado é registrado. A fase ascendente é onde o aprendizado acontece: um LLM separado lê as trajetórias que falharam, extrai diretrizes reutilizáveis, pontua cada uma por confiabilidade e elimina as de baixo desempenho ao longo do tempo.

Quando o agente encontra uma nova tarefa, o sistema recupera apenas as diretrizes mais bem pontuadas e relevantes para aquele contexto específico. Não o histórico completo. Não um despejo de tudo que o agente já viu. Apenas os princípios que se mostraram confiáveis.

Os resultados no benchmark AppWorld merecem atenção cuidadosa.

Tarefas fáceis melhoraram 5,2 pontos percentuais (79% para 84,2%). Tarefas médias melhoraram 6,3 pontos (56,2% para 62,5%). Tarefas difíceis melhoraram 14,2 pontos (19,1% para 33,3%).

O número das tarefas difíceis merece análise. Um aumento relativo de 74% soa expressivo, e é. Mas a linha de base era 19,1%. Sair de uma em cinco para uma em três representa progresso real. Não é desempenho pronto para produção.

O padrão é revelador: quanto mais difícil a tarefa, mais o agente se beneficia das diretrizes acumuladas. Tarefas simples precisam de menos ajuda. Tarefas complexas, onde o agente tem maior probabilidade de se perder em raciocínio de múltiplas etapas, se beneficiam mais de princípios curados que previnem caminhos de falha conhecidos.

O ALTK-Evolve é de código aberto e inclui um plugin para Claude Code. A engenharia é sólida. Mas a pergunta interessante não é de engenharia.

Segunda abordagem: construir um flywheel de equipe

O Feedback Flywheel de Garg, publicado no site de Martin Fowler, opera em outro nível. Onde o ALTK-Evolve ensina agentes individuais, o Flywheel ensina equipes a acumular prática com IA de forma composta.

A percepção central: “Um output rápido que requer retrabalho extensivo não é ganho de produtividade. É retrabalho com passos extras.”

Equipes estagnam com assistentes de IA porque os usam de forma avulsa. Uma desenvolvedora descobre uma técnica de prompt e guarda para si. Outro constrói um arquivo CLAUDE.md útil mas nunca compartilha o padrão. Uma terceira encontra uma instrução que previne um erro recorrente, mas armazena apenas na configuração local.

Garg identifica quatro tipos de sinais que equipes devem capturar e realimentar:

Sinais de contexto se tornam documentos de preparação. Quando seu agente precisa das mesmas informações de fundo repetidamente, codifique uma vez e compartilhe com a equipe.

Sinais de instrução se tornam comandos compartilhados. Os padrões de prompt que funcionam são extraídos da prática individual para a infraestrutura da equipe.

Sinais de fluxo de trabalho se tornam playbooks. Não apenas o que dizer ao agente, mas quando usá-lo e quando não usar.

Sinais de falha se tornam guardrails. Quando um agente produz uma categoria de erro, a prevenção é codificada como uma restrição que a configuração de cada membro da equipe herda.

Esse território é familiar para quem já construiu agentes de código autoaperfeiçoantes. O padrão AGENTS.md, memória de repositório, persistência de instruções. A contribuição de Garg é estender o conceito da prática individual do desenvolvedor para a infraestrutura de equipe.

Sua observação mais afiada: “Equipes que adotam ferramentas de IA praticamente ao mesmo tempo podem chegar a lugares muito diferentes seis meses depois.” A diferença não é talento. É se a equipe constrói ciclos de feedback ou depende de heroísmo individual.

Terceira abordagem: deixar o agente redesenhar a própria memória

Nem o ALTK-Evolve nem o Flywheel é a abordagem mais agressiva para o autoaperfeiçoamento de agentes. Essa distinção pertence ao paradigma que examinamos no mês passado: agentes que redesenham a própria arquitetura de memória.

O experimento de Zak El Fassi mostrou um agente avaliando seu próprio sistema de memória, identificando pontos cegos estruturais e executando correções por meio de subagentes paralelos. A recuperação de informações saltou de 60% para 93%. Custo: dois dólares.

Onde o ALTK-Evolve extrai diretrizes de trajetórias, e o Flywheel captura sinais de equipe, a memória autodesenhada permite que o agente reestruture o substrato da própria cognição. Ele não está aprendendo o que fazer de diferente. Está reorganizando como armazena e recupera tudo que sabe.

Três abordagens, um ponto cego

Eis o que as três abordagens compartilham: nenhuma delas responde quem valida o que o agente aprende.

O ALTK-Evolve pontua diretrizes automaticamente. Uma diretriz que leva a falhas nas tarefas perde pontuação. Uma que leva a sucessos ganha pontuação. Mas pontuar contra a conclusão de tarefas não é o mesmo que validar a diretriz em si. Uma diretriz pode produzir resultados corretos através de raciocínio falho. Pode codificar um atalho que funciona em benchmarks mas falha em produção. Pode incorporar um viés que nenhuma métrica automatizada capturaria.

O Flywheel depende das equipes para curar sinais. Mas Garg não oferece um framework de controle de qualidade sobre o que entra na infraestrutura compartilhada. Quem revisa os guardrails antes de eles se tornarem padrões da equipe? O que acontece quando dois membros codificam instruções contraditórias? Como depreciar uma diretriz que era útil há seis meses mas agora é contraproducente?

A memória autodesenhada, como exploramos em profundidade, tem a versão mais aguda desse problema. O agente que avalia, reestrutura e valida a própria memória é juiz e réu ao mesmo tempo. O dilema do validador: qualquer sistema que avalia o próprio desempenho vai sistematicamente subestimar os modos de falha que não consegue conceber.

Mapeamos a camada de observabilidade necessária para vigiar agentes em produção. O sistema Signals da Factory detecta padrões de fricção em milhares de sessões. Mas detectar fricção não é o mesmo que validar aprendizado. Você pode observar que um agente está performando melhor em uma métrica sem compreender se o conhecimento adquirido é sólido, completo ou seguro.

A arquitetura de governança que ainda não existe

Como seria um sistema de aprendizado validado?

Separação entre aprendiz e validador. O agente que usa diretrizes não deveria ser o único juiz da qualidade delas. Esse princípio é antigo. Auditorias financeiras exigem auditores externos. Revisões de código exigem outros olhos. Fizemos esse argumento para memória; ele se aplica igualmente a diretrizes aprendidas e playbooks de equipe.

Rastreamento de proveniência para cada regra aprendida. De onde veio essa diretriz? Quais falhas a geraram? Quando foi validada pela última vez? Contra quais tarefas? O ALTK-Evolve rastreia pontuações, o que é um começo. Mas pontuação não é proveniência.

Teste adversarial do conhecimento aprendido. Depois que um agente aprende uma nova diretriz, teste-a contra cenários desenhados para expor os limites da diretriz. O ALTK-Evolve elimina diretrizes de baixa pontuação. Isso remove as obviamente ruins. Não captura as sutilmente erradas que produzem resultados corretos por motivos incorretos.

Mecanismos de depreciação e expiração. Conhecimento tem prazo de validade. Uma diretriz extraída do comportamento do GPT-4 pode não se aplicar ao Claude. Um playbook escrito para um monólito pode ser contraproducente em uma arquitetura de microsserviços. Sem políticas explícitas de expiração, o conhecimento aprendido se acumula indefinidamente, e regras obsoletas se tornam restrições invisíveis.

Validação cruzada entre abordagens. O que acontece quando uma diretriz do ALTK-Evolve contradiz um playbook do Flywheel da equipe? Quando a estrutura de memória autodesenhada pelo agente conflita com políticas de retenção organizacionais? Essas colisões são inevitáveis quando múltiplos sistemas de aprendizado operam sobre o mesmo agente. Ninguém propôs um mecanismo de resolução.

Por que isso importa agora

Essas não são preocupações teóricas. O ALTK-Evolve é de código aberto com um plugin para Claude Code. O Flywheel é um framework que equipes podem implementar hoje. Memória autoaperfeiçoante custa dois dólares. As ferramentas para aprendizado de agentes estão aqui. As ferramentas para validar o que agentes aprendem, não.

Passamos os últimos três meses construindo a base intelectual para esse argumento: como agentes aprendem, como tornar o aprendizado persistente, como observar agentes em produção, quem valida memória autodesenhada. Cada peça adicionou uma camada. Esta conecta todas.

A trajetória é clara. Agentes vão aprender. Vão melhorar a partir dos próprios erros. Vão absorver conhecimento de equipe. Vão redesenhar a própria memória. A questão não é se isso acontece. A questão é se humanos permanecem no ciclo de validação quando acontecer.

Um agente que aprende sem validação não está se autoaperfeiçoando. Está se autorreforçando. São coisas diferentes. Um melhora. O outro fica mais confiante.

---

Fontes

• Isahagian, V. et al. “ALTK-Evolve: Agentic LLM Toolkit Evolution.” IBM Research. Abril 2026. arxiv.org/abs/2603.10600
• Garg, R. “The Feedback Flywheel.” Martin Fowler / Thoughtworks. Abril 2026. martinfowler.com

Victorino Group constrói infraestrutura de governança para sistemas de IA que aprendem sozinhos, de frameworks de validação a arquiteturas de separação de responsabilidades para aprendizado de agentes: contato@victorino.com.br | www.victorino.com.br