TL;DR
In a conversation, the model gets stuck on its first guess about what you wanted, and then just patches the old answer with new information — instead of rebuilding it from scratch. The model formally accepts your correction ("got it, understood"), but in practice it keeps dragging fragments of the old, already-wrong interpretation into the text.
Picture this: you ask for help with a report "for tomorrow's review." The model decides this is for the board and writes it presentation-style, upbeat tone included. You clarify: "No, this is a failure post-mortem for engineers — I need the unvarnished causes." The model adds technical details — but the tone, structure, and overall "pitch-deck spirit" stay exactly the same. It said it understood, but it never rebuilt the task from the ground up.
The fix isn't to trust that the model will rethink its approach after a correction on its own. Either explicitly tell it to forget all previous assumptions and start with a clean slate, or use a two-phase setup from the start: have the model ask all its clarifying questions first, and only then execute the task.
Method Blueprint
SCENARIO A — Rollback (if the correction comes AFTER a wrong answer, single prompt):
STEP 1: Explicitly say "forget all past assumptions, rebuild the answer from scratch
based only on this current correction" → a new answer with no leftovers from the old version
SCENARIO B — Two-phase (if the task is ambiguous from the start, two turns):
STEP 1: Ask the model to FIRST ask all its clarifying questions,
without starting the task → a list of questions
STEP 2: Answer the questions → the model executes the task → a final answer
with no "tail" from the wrong interpretation
Example in Action
Task: A startup founder asks for help breaking down a failed feature launch ahead of tomorrow's meeting.
Prompt 1 (first message):
Help me write up why our latest feature launch failed.
Need it for tomorrow's meeting.
Not knowing the audience, the model will most likely write it as an investor pitch: softened language, "growth opportunities," minimal technical detail.
Prompt 2 (correction + rollback):
Correction: this is a breakdown for our engineering team, not for investors.
I need the technical root causes of the failure and concrete fix steps, no sugarcoating.
Forget all the assumptions you made in your previous answer about tone and audience.
Rebuild the breakdown from scratch, based only on this correction.
Don't reuse the structure or phrasing from the previous answer.
Result: The model produces a new text written exactly like an engineering post-mortem — with concrete technical root causes, no glossing over the failure, and no leftover pitch-deck language. Without an explicit rollback, the model would most likely have just bolted technical details onto the old, still-"presentation-y" structure.
Why This Works
In a conversation, the model doesn't re-examine the whole picture of the task when it gets a correction — it patches the already-generated answer, layering new facts on top of the old shape. This happens even when the model verbally confirms it understood the correction.
On the other hand, the model is genuinely good at generating coherent text from scratch when it gets a clean, unambiguous instruction with no history of previous versions attached.
An explicit "forget everything and start over" command cuts off the model's escape route into patching — it's forced to generate the answer based solely on the current conditions, not on the skeleton of the old text.
Levers you can pull: - Order of information — if you can, give all the conditions upfront in a single message rather than piecemeal: the order matters just as much as the final set of facts. - Explicit rollback vs. a plain correction — the phrase "forget past assumptions" sharply increases genuine reconsideration, rather than just verbal agreement. - Two-phase from the start — stronger than a rollback after the fact, since it prevents the model from forming a wrong interpretation in the first place.
Prompt Template
Rollback (after the model has already gone down the wrong path):
Forget all the assumptions you made in your previous answers about this task.
Here's the updated condition: {correction}.
Rebuild the answer from scratch, based only on this correction.
Don't reuse the structure, tone, or content from previous answers.
Two-phase (from the very start of the conversation):
Before doing the task "{task}", ask me all the clarifying questions
you need to remove any ambiguity.
Don't start the task until I've answered all of them.
🚀 Quick Start — paste into your chat:
Here are two techniques for handling ambiguous tasks in a conversation with an AI:
(1) Two-phase — ask the model to first ask clarifying questions, without doing the task yet;
(2) Rollback — if the correction comes after the model has already started doing the task wrong,
explicitly ask it to forget past assumptions and rebuild the answer from scratch.
Adapt one of these techniques to my task: {my task}.
Ask questions if you need more details.
[paste the template above]
The LLM will ask which scenario applies to you — whether the task is ambiguous from the start (use two-phase) or the correction came after a wrong answer (use rollback) — since that determines which template to use.
Limitations
⚠️ Not a full fix, just proof the mechanism can be addressed: the authors themselves warn that rollback and two-phase are a way to demonstrate that the problem is treatable, not a ready-made universal recipe.
⚠️ Code and structured tasks are the highest-risk zone: if the old interpretation is already "baked into" the structure (a data schema, an interface, a plan with dependencies), even a rollback might not fully clear all the traces.
⚠️ Verbal agreement doesn't guarantee an actual rethink: the model might say "got it, fixing it" and still drag the old logic into the code or the structure of the answer — visible agreement ≠ behavioral change.
⚠️ Summarizing the conversation makes it worse: if you ask the AI to compress the chat history, it may "collapse" the ambiguity into a single version, losing alternative interpretations that hadn't yet been ruled out.
How It Was Studied
Researchers ran Gemini-2.5-Pro and Gemini-2.5-Flash through nearly 300 writing, planning, and coding tasks that started with an ambiguous request followed by a correction. They added 20 hand-crafted pilot tasks and 30 tougher adversarial scenarios. In total, about 7,160 trials and nearly 14,000 API calls.
They tested different orderings of information (everything at once / correction first / ambiguity first), different memory strategies (raw history, compressed summary, step-by-step reasoning, a single unified "state sheet"), and two direct interventions — explicit rollback and a two-phase policy.
The biggest surprise: code turned out to be the most vulnerable zone — contamination there was almost twice as high as in writing tasks, because early guesses get baked directly into interfaces and data schemas. Even more unexpected: step-by-step reasoning and explicitly tracking conversation state didn't help — and sometimes even hurt, turning uncertainty into false confidence. But a simple explicit rollback zeroed out measured contamination in the controlled experiment, and the two-phase policy (ask first, then act) eliminated wrong decisions entirely.