Long-running AI agents do not just run out of context. According to a new paper, they also get stuck in the kind of solution they have already tried. Researchers including Microsoft-affiliated authors call these traps "idea basins", and their fix is to fork the agent into parallel branches that keep the files but forget the conversation. The method, Fork-and-Flush, beat a single run by 66.0% and a best-of-4 baseline by 44.4% at equal compute across 13 tasks, as The Decoder reported.
If you run coding or research agents for hours, this is a practical result: the cheapest intervention may be to clear the chat while keeping the work.
TL;DR: the questions people will ask
| Question | Short answer |
|---|---|
| What is the problem? | Repeated runs of the same autoresearch agent on the same task plateau at very different scores (68.3 to 100.0 in one example), even with far more compute |
| What is the proposed fix? | Fork-and-Flush: fork into K branches that inherit the workspace, flush each branch's chat context, continue from the best |
| How big is the gain? | +66.0% over a single run, +44.4% over best-of-4, on min-max normalized average score over 13 tasks |
| Does flushing alone help? | Yes, per The Decoder: average 0.45 to 0.55 on 11 tasks with no branching |
| Is it more consistent? | Normalized standard deviation fell from 0.26 to 0.16 |
| Is code available? | No paper-specific repo is linked on the arXiv page |
| Who wrote it? | Ziyang Cai, Christos Ziakas, Vasilis Kontonis, Tim Pearce, Siddhartha Sen, Akshay Krishnamurthy, Shivam Garg and Dimitris Papailiopoulos; affiliations are not listed on the arXiv abstract page |
Why this matters for anyone building agents
Most agent harnesses treat the transcript as the agent's memory and try to preserve it with summaries and compaction. This paper argues the opposite for long optimization-style work: the transcript is also a source of lock-in. Every earlier decision, justification and dead end sits in the prompt and nudges the next step toward more of the same. For teams paying for hours of agent time, that means the marginal token spent late in a long session may be worth less than a token spent in a fresh session over the same files. It also reframes parallelism: the value of running several agents is not only speed but diversity of approach, which is exactly what a shared long context erodes.
What the paper actually found
The study looks at "autoresearch" agents: systems that repeatedly propose a change, evaluate it against a score, and refine. Think of an agent that spends hours improving a scheduler, a packing algorithm or a cryptanalysis attack, saving files and results as it goes. It is the same loop pattern we cover in the loop engineering guide.
The authors ran the same agent on the same task eight times. Final scores landed anywhere from 68.3 to 100.0. Giving the runs much more compute did not close that gap. When they embedded the candidate artifacts by functional similarity, each run appeared to stay in its own small neighborhood of the solution space. That is the "idea basin": once an agent commits to an approach and the conversation fills with reasons why that approach is right, it keeps polishing instead of trying something different.
Long-running agent loop where the context window fills and idea basins form, shown for the Fork-and-Flush agent research
How Fork-and-Flush works
The method has two verbs.
- Fork: the agent splits into K parallel branches. Each branch inherits the previous workspace, meaning code, files and saved results.
- Flush: each branch discards its chat context. It starts a fresh conversation, but on top of the existing work.
After a fixed horizon the system picks the best-scoring branch and continues from it. The reported intuition is that branches that keep their old context tend to slide back into the same basin, while fresh context restores diversity. Because the workspace carries over, nothing learned in the files is lost.
Parallel branches diverging from one trunk, illustrating forking an agent workspace in Fork-and-Flush
This is structurally close to the Git-worktree pattern many Claude Code and Codex users already run by hand: several agents, same repo, separate sessions. If you use that setup, see our Claude Code commands reference for the building blocks.
The numbers
According to The Decoder's summary of the paper, the evaluation used 13 long-running tasks, including polyomino packing, job-shop scheduling and cryptanalysis, with GPT-5.6-terra and GPT-5.5 as the agent models.
| Method | Normalized average score |
|---|---|
| Single run | 0.47 |
| Best-of-4 | 0.54 |
| Fork-and-Flush | 0.78 |
Other reported results:
- Fork-and-Flush had the highest mean score on 12 of the 13 tasks.
- Normalized standard deviation dropped from 0.26 for single runs to 0.16.
- On 11 tasks, clearing context without branching raised the average from 0.45 to 0.55, about 22%.
A caution on reading these figures: they are min-max normalized per task, so they show relative ordering, not absolute quality. The 66.0% and 44.4% numbers are relative improvements on that normalized average, and we have only read the abstract and the secondary summary, not the full paper's appendix on limitations.
Why best-of-N is not the same thing
Best-of-N spends compute on N independent runs and keeps the top one. Each run still accumulates its own long conversation and drifts into its own basin, so you are sampling a handful of basins. Fork-and-Flush instead periodically branches from the best current state and resets the context, so later compute builds on earlier progress rather than restarting from nothing. That is why it can beat best-of-4 at the same budget: it reuses work and re-diversifies ideas.
Does it get better with stronger models?
The authors also tested how this variance changes with model capability, using MAX-3-SAT with Qwen3.5 at 4B, 9B and 27B. Run-to-run variance followed an inverted U: it peaked on tasks at the edge of a model's ability. Easy tasks are solved reliably and impossible ones fail reliably; the middle is where early choices decide the outcome. The authors expect this pattern to persist as models improve, because frontier agents will simply be pointed at harder tasks. That suggests periodic context resets may stay useful for frontier agents rather than being a workaround for weak ones.
A long context ribbon passing through an agent loop, representing why long-running agents benefit from context resets
What to try in your own agent harness
You cannot download the authors' implementation today, but the pattern is easy to approximate.
- Persist state outside the chat. Keep a notes file, a results log and the code in the working directory. A flush is only safe if the next session can reconstruct what happened from files.
- Reset on a schedule. After a fixed number of iterations or a plateau in the score, start a new session in the same directory with a short handoff summary rather than the full transcript.
- Fork when you have budget. Copy the directory into K worktrees, run each with a fresh session, and keep the best by your own evaluator.
- Tell the new session what failed, not why it was right. A handoff that rehearses the old argument can pull the agent right back into the basin.
- Always keep an objective score. The method relies on picking the best branch; without a trustworthy evaluator, forking just multiplies noise.
This lines up with other recent findings about what agents do and do not need to carry around. Our post on why agents need documentation more than memory makes the same bet from the other side: durable files beat long transcripts. For the cost trade-off of running several agents, see the Vals AI comparison of agent teams versus a single agent. And for how Microsoft's other agent research is positioned, see Agent Lightning v1.
Limits and open questions
- Compute framing. The comparison is at equal compute, but wall-clock time, orchestration complexity and the cost of the evaluator are separate concerns. Forking K branches in parallel is faster per step than serial work only if you have the capacity to run them.
- Evaluator dependence. All 13 tasks have a score. Open-ended work with no clean metric, such as most product coding, does not give you a branch-selection signal.
- Task coverage. Packing, scheduling and cryptanalysis are optimization-style problems. Whether the same gains hold for multi-file refactors or agentic coding on messy repos is not shown by this summary.
- No public code yet. Without a reference implementation, replication will vary by harness.
- Model names. The model labels come from The Decoder's report; check the paper for exact configurations before citing them.
A related reminder from human-AI work: a Berkeley and CMU study found that people persist less after AI assistance, a different failure but a similar theme of getting stuck early in how a problem is approached.
Bottom line
The practical takeaway is modest and actionable: if an agent has been working for a long time and its score has flattened, start a fresh conversation over the same files before you throw more compute at the same context. Branching and picking the best result pushes the gain further. Treat the headline percentages as relative results on one benchmark suite from one paper, and watch for the authors' code release.
Related reading
- Loop engineering for coding agents
- Claude Code commands reference
- Agents don't need memory, they need documentation
- Agent teams vs a single agent: token cost and quality
- Agent Lightning v1 from Microsoft
- AI assistance and persistence study
- Paper: Fork-and-Flush on arXiv
Figures and paper details are accurate as of October 12, 2026 and come from the arXiv abstract page and The Decoder's summary.