68,3 a 100,0: essa foi a amplitude das notas finais de oito execuções independentes do mesmo agente de IA, na mesma tarefa, com as mesmas ferramentas, o mesmo prompt e o mesmo workspace. Nenhum bug de ambiente, nenhum dado diferente — só o acado do processo de geração. Uma execução resolveu o problema; as outras sete passaram horas refinando soluções visivelmente piores, com a sensação equivocada de estarem progredindo.
É o colega de time que entrou no projeto na sprint um, cravou uma arquitetura e nunca mais a reconsiderou — com a diferença de que o colega cede numa conversa de café, enquanto o agente releia o próprio histórico de chat a cada passo e encontra, ali, a confirmação de que o primeiro plano era bom mesmo. Um grupo da Microsoft Research tem um nome para esse comportamento e propõe um remédio que parece, à primeira vista, contraintuitivo: apagar a conversa.
O estudo (abre em nova aba), "Fork-and-Flush: Escaping Idea Basins in Autoresearch Agents", de Ziyang Cai, Christos Ziakas e outros pesquisadores, saiu como preprint no arXiv em 5 de outubro de 2026. O objeto são agentes de autopesquisa: sistemas que atacam problemas abertos propondo soluções candidatas, avaliando cada uma e usando o retorno para orientar os experimentos seguintes. O time testou treze tarefas de pesquisa e engenharia — empacotamento de poliominós, agendamento de job-shop, criptoanálise, inferência de fontes de contaminantes em água subterrânea, compressão de um classificador CIFAR sob restrição de acurácia e otimização de um kernel para uma máquina VLIW simulada, entre outras. Os agentes rodaram no GitHub Copilot CLI, com os modelos GPT-5.6-terra e GPT-5.5, em execuções que chegaram a 107 horas e orçamentos de 6 mil a 100 mil créditos (100 créditos equivalem a cerca de US$ 1, segundo os autores).
A conversa como âncora
O achado central não é o método, é o diagnóstico. Execuções independentes do mesmo agente, na mesma tarefa, convergem para regiões restritas do espaço de soluções — os autores chamam de idea basins, bacias de ideias — e as diferenças de qualidade persistem mesmo com bastante computação adicional. Para tornar isso visível, o time usou um truque elegante: um modelo reescreve cada experimento como uma especificação, responde milhares de perguntas binárias do tipo "o experimento A está mais perto de B ou de C?", e a matriz resultante é projetada em duas dimensões. As trajetórias, de fato, saturam em regiões pequenas. O embedding concordou com 85% dos julgamentos de comparação reservados para teste, contra 50% de chance.
Dimitris Papailiopoulos, pesquisador da Microsoft e um dos autores, resumiu a intuição do trabalho assim:
Eu gosto de pensar o AutoResearch como Idea Descent: uma métrica de interesse cai em função de ideias/experimentos, em que os agentes são puxados para uma ideia ou outra. Mas temos visto com muita frequência um agente desenvolver essa estranha visão de túnel, se concentrando em apenas um tipo de "ideia", meio que como um gradiente descendente preso num mínimo local.
A analogia dele com otimização não é gratuita: se o agente é um descensor de gradiente pelas ideias, fork-and-flush é basin hopping — o salto deliberado para fora da bacia.
O mecanismo
O método em si é quase decepcionantemente simples. Periodicamente, o agente é bifurcado em várias trajetórias paralelas. Todas herdam o workspace acumulado — arquivos, código, artefatos, resultados de experimentos —, mas cada uma começa com o contexto de chat completamente vazio. As cópias rodam por um horizonte fixo; a que tiver a melhor pontuação vira o tronco, e o ciclo recomeça. O agente mantém o estado, mas perde a narrativa.
Com orçamento de computação igual, o resultado médio normalizado foi 0,78 para fork-and-flush, contra 0,47 para execução única e 0,54 para best-of-4, melhorias relativas de 66,0% e 44,4%, respectivamente. O método teve a maior pontuação média em 12 das 13 tarefas, e o desvio padrão normalizado caiu de 0,26 para 0,16, ou seja: menos dispersão entre execuções, menos dependência da sorte.
O número que mais me interessou, porém, é outro: só limpar o histórico, sem bifurcar, já melhorou os resultados em cerca de 22% (0,55 contra 0,45) em 11 tarefas. Ou seja, uma boa parte do ganho não vem do paralelismo, vem de simplesmente interromper a conversa.
O que o chat está fazendo ali
Minha leitura do mecanismo, e aqui entra interpretação: o histórico de conversa de um agente não é memória neutra, é um prior. Cada hipótese abandonada, cada tentativa que falhou, cada plano elaborado e descartado continua presente como tokens. A cada passo, o modelo recondiciona sobre todo esse material, incluindo o raciocínio que levou à solução atual, e o caminho de menor resistência para gerar a próxima proposta é uma variação da anterior. O plano vigente se autoconfirma. O agente não está "aprendendo" com os erros; está sendo ancorado por eles.
A distinção que o artigo implicitamente faz é a que mais importa para quem desenha arquiteturas de agente: estado e narrativa são coisas diferentes. O estado, arquivos, resultados, código que roda, carrega a informação útil acumulada. A narrativa, o fio da conversa, carrega o viés. A aposta do fork-and-flush é que, nesses problemas, quase todo o aprendizado de valor já vive nos artefatos; a conversa é um rascunho que, com o tempo, deixa de ser rascunho e vira doutrina.
Vale registrar que o fenômeno sobrevive à compressão: segundo a cobertura do The Decoder sobre o estudo, os agentes continuavam presos em bacias mesmo quando comprimiam periodicamente os históricos. Resumir a conversa não resolve; herdar o resumo é herdar o viés resumido.
A objeção óbvia
"Apagar o contexto é jogar fora o aprendizado do agente." É o contra-argumento que qualquer um com experiência em sistemas de memória faria, e ele tem força em certos cenários. Nem toda tarefa tem sua informação concentrada em arquivos com métrica clara; há trabalho em que a percepção crucial vive só na conversa, uma restrição de negócio que o cliente mencionou de passagem, um detalhe de infraestrutura descoberto por tentativa e erro.
A resposta honesta é que o estudo não testou esses casos. As 13 tarefas têm objetivos numéricos e workspaces ricos, o ambiente ideal para que o estado sobreviva sem a narrativa. Para tarefas ambíguas, o resultado não se generaliza por si só. O que se generaliza, com meu aval de leitura, não o endosso dos autores, , é a pergunta que o método obriga a fazer: antes de limpar o contexto, o que precisa sobreviver? Se a resposta for "tudo", você não tem um agente, tem um log. Se a resposta for "nada", provavelmente o workspace está mal desenhado. No meio dos dois, há uma solução barata: antes do flush, pedir ao agente que escreva em disco um registro destilado de decisões e restrições, e recomeçar de lá. A conversa morre; o inventário fica.
Onde desconfiar
O paper é um preprint, a comparação é dos próprios autores sob orçamento igual, e não há replicação externa ainda. O cronograma de bifurcação é fixo, não reativo, ninguém detecta platô, apenas segue a agenda, , o que deixa na mesa a pergunta de quando exatamente flush. E o custo: rodar K cópias paralelas multiplica o gasto nos pontos de bifurcação, ainda que a comparação final contabilize orçamento total igual.
Dito isso, o flush simples é o experimento mais barato do mundo para quem já roda agentes de longa duração: mesma execução, mesmo prompt, só zerando a conversa em pontos planejados e preservando o workspace. A diferença de 0,45 para 0,55 nos testes dos autores não é garantia de nada no seu caso, mas é do tipo de resultado simples demais para não testar na próxima maratona de otimização.
O que sobra
A indústria corre para contextos maiores, milhões de tokens, memórias intermináveis, histórico que nunca apaga. Este artigo aponta na direção oposta: o gargalo de um agente de longa duração pode não ser quanta memória ele tem, e sim o quão bem ele sabe esquecer. Manter o estado, soltar a narrativa; preservar o que foi aprendido, descartar o caminho que levou até ali. É o mesmo critério de um bom code review com olhos frescos, só que agora com números.
Para quem constrói agentes, a conclusão prática é modesta e útil: trate o chat como rascunho com prazo de validade, e trate o workspace como a única memória que importa. O resto é o agente conversando consigo mesmo sobre o quanto a primeira ideia era boa.
Perguntas frequentes
O que é fork-and-flush?
É uma intervenção periódica em agentes autônomos: o agente é bifurcado em cópias paralelas que herdam o workspace (arquivos e artefatos) mas começam com o contexto de chat vazio; após um horizonte fixo, a cópia com melhor pontuação continua a execução.
Quanto o método melhorou os resultados?
Segundo o paper, fork-and-flush superou a execução única em 66,0% e o best-of-N em 44,4% de melhoria relativa no score médio normalizado, com orçamento de computação igual. Só limpar o histórico, sem bifurcar, rendeu cerca de 22% de melhoria em 11 das tarefas.
Funciona com qualquer modelo ou tipo de tarefa?
Foi testado com os modelos GPT-5.6-terra e GPT-5.5 via GitHub Copilot CLI, em 13 tarefas de pesquisa e engenharia com métrica clara e execuções de até 107 horas. Não há evidência publicada sobre generalização para tarefas sem objetivo mensurável ou para outros modelos.
O estudo é peer-reviewed?
Não. É um preprint no arXiv, de 5 de outubro de 2026, com comparação de orçamento igual feita pelos próprios autores; não há replicação independente publicada até agora.