An AI agent in an Anthropic experiment spent hours fixing package versions. The actual bug was an endpoint that didn't match the grader's API. When your own run gets stuck like that, try a clean handoff: save the work, record the evidence, and let a fresh context choose the next test.
The crucial word is evidence. If you carry over “keep fixing the packages,” you've handed the next run the same bad map.
We read the recent research on resets and checked our own conversation-summary prompt. Our practical takeaway is a handoff you can inspect: what you wanted, what's known, what failed, and which question would change the plan. You can try it on a stalled task without making resets a rule for every conversation.
Save. Keep the work and its receipts: files, test results, and what each action actually did.
Distill. Write down the facts and the open questions. “Keep fixing the packages” would hand the next run the same bad map.
Read. A fresh context reads the handoff and picks the test that tells two explanations apart.
Verify. The result is new evidence: keep the plan or change it.
Why compaction can keep the wrong plan
Context is the material an LLM reads for a call: instructions, messages and tool results. Compaction makes that material shorter, usually by summarizing older work. It's useful. You don't want to spend every turn rereading a 200-line stack trace once you've found the relevant line.
But a shorter story can still carry a bad assumption.
In the Fork-and-Flush preprint, research runs kept exploring nearby ideas even after their histories were compacted. That's a specific observation about those experiments. It gives us a reason to test whether a summary is preserving a stalled direction along with useful facts.
We checked Definable's summary prompt. It asks for the user's intent, decisions, facts, tool outcomes, promises and open work. Those are sensible things to preserve. Yet a record of a decision doesn't establish that the decision was right. Reading our own prompt made that distinction harder to ignore.
For a handoff, separate the observation from the explanation. “Test 14 still fails after changing the dependency” is an observation. “We need another dependency version” is a hypothesis. You can preserve the first and ask the next run to challenge the second.
Otherwise, you've given the rut a shorter name.
What the reset research actually shows
Anthropic's Memento harness starts a fresh instance with the previous workspace and brief notes about earlier attempts. Its serving experiment used 1.5 hours per iteration and 6 hours overall. The authors also say the harness isn't universally strong. Those are experimental settings and limits, so don't turn 90 minutes into your team's reset timer.
Fork-and-Flush goes further: it copies the workspace into parallel runs with fresh chat contexts, gives them a fixed compute budget, then continues from the highest-scoring result. Its ablation study separates the parts:
| Variant | Change | Score |
|---|---|---|
| Single run | Baseline | 0.45 |
| Flush only | Reset context | 0.55 |
| Fork only | Parallel search | 0.57 |
| Fork and flush | Both changes | 0.71 |
These are average normalized optimization scores across 11 research and engineering tasks in the paper's ablation. They're not pass rates: 0.71 doesn't mean 71% of tasks succeeded. The combined method's result also includes parallel search and selection, so you can't credit all of it to forgetting.
We'd treat this as a reason to run a small comparison on your own work. It doesn't tell you which of your tasks should reset, how often, or what a useful handoff should contain.
Write the handoff someone could check
Start with the question you'd ask a colleague taking over: what can you prove right now?
Here's an illustrative debugging case, not an incident from our team. A report export is empty. The working theory is that a dependency upgrade broke the parser. You tried versions 2.4 and 2.5; both returned zero rows. A saved raw response contains 18 rows under results, while the parser reads items.
“Keep debugging the parser upgrade” wastes that clue. A better handoff says: “The raw response has 18 rows. Both tested versions produced zero. Check the field name before trying a third version.” You've given the next run a cheap way to distinguish two explanations.
Use a template like this. The paths, dates, IDs and counts below belong to the fictional example; replace them with receipts from your run.
Goal: Export all 18 rows from the saved sample.
Constraints: Keep the output schema; no live writes.
State saved: 2026-10-29 10:15 UTC, checkpoint 3.
Files: parser.py; samples/response.json.
Evidence: response.json has 18 rows in results.
Test receipt: checks/export-14.txt, 10:12 UTC.
Observed: versions 2.4 and 2.5 both export 0 rows.
Earlier hypothesis: dependency upgrade broke parsing.
Evidence against it: failure persists on both versions.
Open question: parser reads items; sample uses results.
Next check: test field mapping on the saved sample.
External actions: report job job-42 was submitted.
Outcome: unknown; no completion receipt was returned.
Pending approval: none; live writes remain forbidden.
Before any retry: inspect job-42 using a read-only check.
Remaining budget: 20 minutes; keep the original cap.
History: saved transcript, available for specific queries.You don't need an autobiography. You need enough detail for another run to inspect the files, repeat the relevant check and understand what's still uncertain.
Keep completed actions beside their receipts. An issued request and a confirmed result are different states. If you don't know whether job-42 finished, write “unknown.” A fresh start shouldn't quietly turn uncertainty into permission to submit job-43.
Preserve the record, choose the working context
A reset changes what the model reads next. It doesn't undo a sent message, a created record or a running job. Keep those facts outside the text you're replacing, then bring the relevant ones into the handoff.
There's a concrete design example in Earendil's experimental Pi Durable. Its reset() starts a new context, optionally using a handoff note, while earlier history remains searchable. We like the separation: the record survives, and the next call can start with a smaller set of material. Its implementation illustrates that separation; our handoff template still needs testing.
Keep everything. A reset changes what the model reads next. It doesn't undo a sent message, a created record or a running job, so the record keeps all of it and earlier history stays searchable.
Select a little. The next call starts from a handoff note: the goal, the rules, the evidence and the open question. The template is 17 lines.
Check before trusting. Claims are checked against saved evidence, and an action with no receipt, like job-42, stays “unknown” until a read-only check settles it.
For your first trial, choose a quiet boundary: the current tool call has returned, the files are saved, and you know which actions are still pending. If a write is in flight, let the system reconcile its outcome before you decide what to repeat.
Restore the original instructions, access limits and remaining budget. A new context doesn't get a new mandate. Have it read the cited evidence before accepting the old explanation, and let it consult the full history when a detail is missing.
Don't dump the entire transcript straight back in. You'd be paying for a reset and then restoring the same working context you meant to test.
Test the handoff against continuing
You'll need a comparison to know whether this helps. Here's a proposed trial, with no measured results implied.
Pick 10 stalled tasks with saved starting states. Define “stalled” before selecting them: for example, 3 attempts that repeat the same approach without improving the agreed check. Use a safe test environment where each continuation gets its own copy of the state. You don't want 3 experimental branches editing the same live record.
Run each starting state under 3 conditions:
| Condition | Starting material | Question |
|---|---|---|
| Continue | Existing context | Would more time work? |
| Compact | Summary and recent work | Does less text help? |
| Handoff | Fresh context and evidence | Does a new plan help? |
Keep the model, tools and remaining spend cap the same. Charge the handoff condition for writing the note and rereading evidence; those steps aren't free. If your budget allows 3 repeats per condition, that's 10 × 3 × 3 = 90 continuations. It's a starting experiment, not a statistical guarantee.
This comparison tests the whole handoff process. To isolate the reset itself, add a fourth condition that keeps the old context but receives the same evidence note. Count that extra condition separately when you budget the trial.
Score success with the same external check in every condition. Also record total cost, elapsed time, repeated failed hypotheses and duplicated actions. A persuasive final explanation doesn't count as a fix. Our guide to agent evals covers why the run itself needs checking.
Add a separate set of healthy tasks, too. If resets help stuck runs but interrupt good ones, you'll want a selective policy. If they don't help either group, keep the simpler setup. You're testing a choice, not auditioning evidence for a decision you've already made.
The next time a run repeats a failed idea, inspect the note you'd hand its successor. Can you point to the goal, the receipts, the unresolved actions and one useful next test?
Save the work. Leave the next run room to change its mind.