Your AI Agent Is Stuck in Its Own Chat History

By Lazar Milicevic · Published October 13, 2026 · 8 min read

You've watched it happen. Two hours into a long agent job, the agent proposes the same fix with slightly different wording, or keeps returning to the same three sources. A Microsoft Research paper on exactly this behavior, posted to arXiv on 5 October 2026, offers a fix that cuts against the usual instinct to add more context: wipe the conversation, keep the work. Here's what the paper actually measured, where it applies to a small team, and how to test the idea this week with real numbers.

What the paper actually did (and didn't do)

The paper is "Fork-and-Flush: Escaping Idea Basins in Autoresearch Agents" (arXiv 2610.07447), by Ziyang Cai, Christos Ziakas, Vasilis Kontonis, Tim Pearce, Siddhartha Sen, Akshay Krishnamurthy, Shivam Garg and Dimitris Papailiopoulos. The work was done during an internship at Microsoft Research, and the authors are also affiliated with Princeton and Imperial College. It's a v1 preprint, so I'd call it a Microsoft Research paper, not a peer-reviewed result.

The scope matters before you get excited. The paper studies "autoresearch" agents: systems that repeatedly propose a candidate solution, evaluate it, and use the score to steer the next experiment. The tasks are long research and engineering problems with a numeric score. It does not test inbox triage, invoicing, lead follow-up or customer support. Applying it to those is my inference from building these systems, not something the paper shows.

The core observation: the authors ran eight independent copies of the same agent on one research task. They plateaued at different levels, and the gaps persisted even after substantial extra compute. The runs fell into five distinct "idea basins" and stayed there. Same model, same task, same budget, different outcomes, and extra time didn't close the gap.

Idea basins: stuck, not stupid

An idea basin is a region of solution space an agent keeps circling. Once a run is inside one, more steps and more tokens refine the same approach instead of leaving it. The Decoder's coverage describes a single run's solutions almost always staying in a small region of the researchers' solution map (The Decoder). Co-author Dimitris Papailiopoulos framed it publicly as tunnel vision, comparable to gradient descent stuck in a local minimum (his post on X).

A precision note, because the "agents get dumber over time" framing is everywhere: the paper doesn't claim capability declines. It describes persistent run-to-run variance and localization in a region of solution space. "Stuck" is accurate. "Degrading" isn't something the sources back up.

The finding that changed how I think about agent design is this one: the localization persists even when the conversation history is periodically compacted. Summarizing or compressing the transcript doesn't release the agent. If you've been "fixing" long sessions by asking the model to summarize and continue, the paper suggests you may be carrying the basin forward inside the summary.

How Fork-and-Flush works

Two moves, combined:

• Flush: clear the inherited chat history, but keep the accumulated workspace (files, code, notes, intermediate results).
• Fork: split the agent into parallel trajectories. Each gets a copy of the current workspace and a fresh chat context. Each runs for a fixed horizon, then the agent continues from the highest-scoring trajectory.

In pseudocode, the loop looks like this:

def fork_and_flush(workspace, n_branches, horizon, score):
    branches = []
    for _ in range(n_branches):
        ws = copy_workspace(workspace)        # files, code, notes, results
        agent = new_agent(context=[])         # fresh chat, no inherited history
        agent.run(ws, steps=horizon)          # reads artifacts, takes its own route
        branches.append((score(ws), ws))
    best_score, best_ws = max(branches, key=lambda b: b[0])
    return best_ws                            # continue from the winner

The reported results, across 13 long-horizon research and engineering tasks (individual runs lasting up to several days), under an equal compute budget:

The measure is a min–max normalized average score, and The Decoder's table lists Fork-and-Flush at 0.78 on that scale. Read the 66% carefully: it's a relative improvement in an average normalized score, not "66% higher accuracy" and not "66% faster." Press coverage says "up to 66 percent"; the paper reports it as an average across tasks.

The best-of-N comparison is the one I'd weight more heavily. Beating a single run is easy to explain by variance alone. Beating N independent runs at the same compute suggests the structure itself, a fresh context over a shared workspace, adds something.

Why a fresh context over a shared workspace works

I can't tell you the paper's mechanism beyond what it states, so here's what's established and what's my reasoning.

Established: the basin effect survives history compaction, and flushing the history while keeping the workspace is the intervention that helped. The authors also expect the run-to-run variation they exploit to persist as models improve, with the boundary just shifting toward harder problems (The Decoder). So don't assume a stronger model makes this go away.

My reasoning, from building agent systems: a long chat is a record of everything the agent already tried. That record is evidence the model conditions on, and it steers toward more of the same. The artifacts, meaning the code, the notes, the measured results, are a different kind of thing. They say what exists and what scored well, without narrating the path that produced it. A fresh agent reading only artifacts has no commitment to the old route.

That gives you a design rule: durable files for what's been built and decided, disposable chat for the current attempt.

What this changes for small-team automations

Treat this section as my inference, not the paper's findings. The paper tested research and engineering agents with numeric scores. But the design pattern transfers cheaply, and it has benefits beyond escaping basins.

An agent that triages your inbox, drafts invoices, or follows up on leads shouldn't carry a week of chat in its head. It should read the current state from a spreadsheet, a CRM record, or a notes file, do the job, and start clean next time. Two practical wins:

• Cost: you stop paying to re-read a huge transcript on every step.
• Reliability: there's no pile of stale instructions pulling the agent sideways.

Here's the state file pattern I'd use as a starting point:

# agent_state.yaml — re-read at the start of every fresh run
task: follow up on proposals sent more than 5 days ago
constraints:                 # NEVER keep these only in chat
  - never contact clients tagged "do-not-contact"
  - use the tone guide in docs/tone.md
  - cap at 20 emails per run
decisions:
  - date: 2026-10-12
    note: skip leads with an open support ticket
attempts:
  - what: subject-line variant B
    result: no reply rate change after 3 days
    status: failed
current_best: templates/followup_v3.md
next_step: test shorter body on the lowest-engagement segment

The constraints block is the part people skip. Which brings up the main risk.

The risk: flushing deletes anything that lived only in chat

Clearing history isn't free. If your agent keeps important constraints only in conversation, such as a client's preferences or a compliance rule, a flush deletes them. The fresh agent will cheerfully take a "new route" straight through a rule nobody wrote down.

The real work isn't the flush. It's sorting everything the agent knows into memory and noise:

• Memory (goes in a file the agent re-reads every run): hard constraints, client preferences, compliance rules, decisions already made, what's been tried and failed, the current best result.
• Noise (stays in disposable chat): the back-and-forth of the current attempt, intermediate reasoning, dead-end drafts.

A quick audit: take your longest-running agent and ask what would break if its chat vanished right now. Every answer is a line that belongs in a file.

Run the test this week

You don't need Microsoft's exact method, and I'd be careful about copying numbers from secondary write-ups of the setup; I haven't cited any branch counts or budget splits from secondary sources here, and if you want those details, read the paper itself. You're testing a simple question: does a fresh context with the same workspace beat a long context on your task?

1. Pick one long-running task, or one where you've caught the agent repeating itself.
2. Make the agent write its state to a file after each major step: what it decided, what it tried, what failed.
3. Set a stop rule. If the agent produces the same kind of answer twice without progress, stop it, clear the chat, and restart from the file only.
4. Run the restart in parallel with the original on one task and compare outputs.

Track these, using real numbers from your own runs:

# simple log line per run — append to runs.csv
echo "$(date -I),task_name,variant,minutes_to_usable,retries,human_interventions,quality_1to5" >> runs.csv

• Time to a usable result
• Number of retries
• How often you had to step in

If the fresh start wins across a handful of tasks, make it the default. If it doesn't, you've lost an afternoon and learned your task isn't basin-prone. Either result is data.

My hot take, with the caveat that the paper doesn't prove it universally: many agent failures people blame on the model are context management failures. Teams keep shopping for a smarter model when the fix is a shorter memory. I'd rather run a mid-tier model with clean state than a top model drowning in its own transcript. That matches what I see building these systems; it's not a result from the paper.

Where this fits in the automations I build

I'm a senior engineer who builds AI automations that ship, and the memory-versus-noise split is a pattern worth designing in from day one: state held in a spreadsheet, CRM record or notes file, hard constraints re-read on every run, and the conversation treated as disposable. If you have a long-running agent that repeats itself and you'd like help separating what it should remember from what it should forget, that's the kind of work I do.

Want more like this?

Planning an AI automation project or need a second opinion on your architecture?

Visit bizflowai.io for services, case studies, and AI consulting.