Microsoft researchers find clearing an agent’s chat history helps long research runs escape ruts

What did Microsoft researchers find?

Eight researchers at Microsoft Research, with interns Ziyang Cai and Christos Ziakas as joint first authors, posted “Fork-and-Flush: Escaping Idea Basins in Autoresearch Agents” to arXiv on 5 October. It picked up wider attention on 12 October after The Decoder covered it. The paper studies autoresearch agents, the loop popularised by Andrej Karpathy in which an agent proposes a solution, runs it, gets a score and tries again, sometimes for days, much like the long coding-agent runs that Alibaba’s QwenGyre was built to train.

The finding is simple to state. Give the same agent the same task several times and the runs plateau at very different scores, and extra compute rarely closes the gap. The authors argue each run commits early to one approach and spends the rest of its budget polishing it, and that its own chat history is part of what keeps it there.

Their remedy, fork-and-flush, is equally simple: at set points, copy the agent’s workspace into four fresh agents with no conversation history, let each work for a short stretch, and continue from whichever scores best. On a matched budget it beat both a single long run and four independent runs on 12 of 13 tasks.

Why do long agent runs get stuck?

The team first ran eight independent agents on p171, a competitive-programming optimisation task. All started from the same empty workspace with the same model and prompt, yet their best scores ended between 68.3 and 100.0, with a median of 81.9. Most runs flattened early and stayed flat for thousands of compute credits.

To see why, the authors mapped what the agents actually built. They had a language model rewrite each submitted program as a functional specification, then asked it which of two candidates was more similar in approach to a third, and fitted a two-dimensional map to those judgments. On five tasks the map agreed with 85 percent of held-out judgments, against 50 percent for chance.

On the map, each run’s submissions sit in a tight cluster, separate from the others. The authors call these clusters idea basins, by analogy with the valleys gradient descent can get trapped in. The agents in the study already compacted their chat histories into summaries from time to time, and that was not enough to break them out.

How does fork-and-flush work?

The method combines two moves. Forking launches several parallel copies of the agent, each with its own exploration budget, and keeps only the highest-scoring one. Flushing keeps the workspace, meaning every file the agent has written, but throws away the conversation, so a branch has to work out what to do from the code itself rather than from the reasoning that led there.

In the paper’s fixed schedule, a run opens with four agents starting from empty workspaces and keeps the best as the leader. The leader then works alone until a third of the budget is spent, when four fresh-context branches fork from its workspace for about 6 percent of the budget each; the winner becomes the new leader. The same happens at two-thirds of the budget.

The authors relate it to older population methods such as Population Based Training, in which weak workers copy a strong worker’s state and then vary it. Here, the state copied is a folder of files and the variation comes from forgetting. Every condition ran in GitHub Copilot CLI with the same tools and prompts, the same command-line agent that recently gained local sandboxing.

How much did it help?

The 13 tasks range from polyomino packing, job-shop scheduling and sphere packing to a lattice cryptanalysis problem, inferring the source of groundwater contamination from well readings, Anthropic’s public kernel-optimisation take-home on a simulated VLIW machine, and shrinking a CIFAR image classifier. Eleven tasks used GPT-5.6-terra at high reasoning effort and two used GPT-5.5. Budgets ran from 6,000 to 100,000 credits per run, where 100 credits is about one dollar, and single runs lasted up to 107 hours.

Because raw scores use different scales, the paper normalizes each task between the worst and best results. Fork-and-flush averaged 0.78, against 0.47 for a single run and 0.54 for best-of-four, relative gains of 66.0 and 44.4 percent. Its average across five runs even beat the single-run baseline’s best result. Run-to-run spread also fell, from 0.26 to 0.16 in normalized standard deviation.

Some jumps were large. On AHC014 the mean score rose from 23.71 to 57.46, and on the order-add task from 24.60 to 49.52. The one clear loss was the cryptanalysis task, where a single run averaged 155.3 and fork-and-flush 144.6. In an 11-task ablation, flushing alone scored 0.55 and forking alone 0.57, against 0.45 for a single run and 0.71 for both.

The idea map shows the mechanism at work. On polyomino, three of four branches stayed where they forked, while the fourth moved 43 times the typical step size in its first submission, landed in a different basin and finished at 93.9, against a single-run median of 84.6. It fits a wider push to put outside checks around long agent runs, from scorers like these to guard models that catch missed safety steps.

How can you use the idea?

Anyone running long agent loops with a reliable scorer can try the idea without new tooling: snapshot the working directory, start a few new sessions from the snapshot with only the task prompt, let them run briefly, score them and keep the winner. It needs no retraining and no access to model weights, and it uses budget that best-of-N would spend on shallow, separate runs.

It suits problems where a program can be graded automatically and repeatedly, such as optimisation, kernel tuning, model compression or puzzle-like research tasks. That is the same kind of loop behind DeepMind’s Lean-checked Erdős proofs, where a verifier, not the agent’s own judgment, decides what counts as progress.

The paper also offers a reason to think the gap will not close by itself. On randomly generated MAX-3-SAT puzzles with three Qwen3.5 models, run-to-run spread peaked when a model reached about half of a strong classical solver’s quality and vanished on easy or impossible instances. Since research tasks sit at the edge of what models can do, the authors expect the variance to persist as models improve.

What are the limits?

The evidence is limited by cost. Thirteen tasks with five runs per method in the main table, four for the CIFAR task, is a small sample for agent runs this noisy, and the authors say expense limited how many tasks they could include. The schedule was fixed in advance rather than tuned per task, which is honest but means the best settings are unknown.

The method also depends on an automatic scorer that can rank partial work, which many real research questions lack. The idea maps rely on a language model judging which programs are similar, though the authors checked that a second embedding method gave the same picture. The paper links no code release, and the main experiments ran on OpenAI models inside one agent, GitHub Copilot CLI.

These are the authors’ results and we have not reproduced them. The broader lesson is still useful for anyone evaluating agents: a single long run says as much about where the agent started as about what it can do, a point that also runs through the debate over how to fit METR’s agent time-horizon data.