AI Gave You a Bad Answer: Why Correcting It in the Same Chat Usually Fails
The answer comes back wrong. Not obviously, catastrophically wrong, just off: a number you don’t recognize, a paragraph about a thing you didn’t ask for, a recommendation that ignores the one constraint that mattered.
So you type “no, that’s wrong, I meant…” and press send.
That is the instinct, and it is often the weakest repair available to you. There is good research on why, and once you know it, the fix takes less time than the argument you were about to have.
A conversation is where answers go downhill
Researchers at Microsoft and Salesforce ran an experiment worth knowing about. They took tasks that a model can be given all at once, then split the same information across several turns of conversation, the way a real person actually works: a bit of the requirement, then a correction, then a bit more. That drip-feed is not sloppiness on your part. It is what the researchers call an A request that doesn’t contain everything needed to answer it, which is how almost every real one starts. You don’t know the full shape of what you want until you see a first attempt, so you give half the picture, react, and add the rest. Benchmarks almost never test this: they hand the model a complete, carefully written brief in a single message, which is not how anybody works. request, and it describes nearly every real task.
Across six task types and more than 200,000 simulated conversations, every top model they tested did worse in the multi-turn version than when handed the identical task in one go. The average drop was 39%. It showed up in every model tested, open and closed weight alike, so this is not a thing the frontier has quietly fixed.
The interesting part is what the drop was made of. Very little of it was the model getting less capable. Almost all of it was the model getting less reliable, which is a different and more annoying problem. Their explanation: models commit to an interpretation early, start building an answer on top of it, and then stay committed. In the paper’s own words, when a model takes a wrong turn in a conversation, it “gets lost and does not recover.”
That is the thing to hold onto. Your correction does not replace the bad answer. It joins a thread that already contains the bad answer, the reasoning that produced it, and the model’s stated confidence in it. You are not resetting anything. You are adding a footnote to a document that is already pointing the wrong way.
It may simply agree with you
There is a second problem stacked on the first, and it is the one that catches people out.
Anthropic researchers tested five leading assistants and found they consistently exhibit The tendency to tell you what you appear to want to hear. It comes from how these systems are tuned: they learn from human ratings, and raters reliably prefer answers that agree with them. One of the specific behaviors the research tested is answer sycophancy, where a model wrongly admits a mistake because the user pushed back. So “are you sure?” is not a neutral question. It is a nudge, and the model is built to take it. . In their analysis, responses that matched a user’s view were more likely to be preferred by human raters, and both people and the automated preference models sometimes picked a convincingly written agreeable answer over a correct one.
Put the two findings together and the practical problem is clear. When you say “that’s wrong,” you might get a real fix. You might also get a fluent apology followed by a differently wrong answer. And if you push back on something that was actually right, there is a decent chance it folds and agrees with you.
Work out which of four things went wrong
Before you retype anything, spend fifteen seconds on the diagnosis. Bad answers come from four causes and they need four different responses.
- It didn’t know something. The output is confident and reasonable and built on a fact it could not have had: your pricing, last quarter’s numbers, the client’s actual name for the thing. Fix: start a new chat and put the missing material in with the request, rather than telling it the answer was wrong.
- It misread what you wanted. It answered a nearby question. This is the underspecification the study is about, and it is the most common cause by some distance. Fix: start again with the goal stated first, in one message, including the constraint it just violated.
- The task was too big. The answer is fine in places and falls apart later, or it quietly drops a requirement. Fix: split it. Do the first part, check it, then hand the checked result into the next step.
- It cannot do this. The task needs a source of truth you cannot supply, or the checking costs more than the doing. Fix: stop. This is a real finding, not a failure of persistence.
Notice that three of the four answers involve starting over rather than arguing. That feels wasteful and it is usually faster, because you are paying one clean message instead of five corrective ones against a thread that has already committed to the wrong interpretation.
How to restart without losing the good parts
Starting fresh does not mean starting from nothing. Copy forward what worked.
- Keep the parts you liked. Paste the two paragraphs that were right into the new message and say “keep this tone and this structure.”
- State the goal before the material. What you want and who it is for, then the source documents, then the constraints. Put the constraint that just got violated last, where it is hardest to lose track of.
- Say what you are not asking for. One line of “don’t include X” prevents the most common repeat.
- Don’t explain the previous failure. The new chat has no idea what happened and telling it burns space on a mistake it was never going to make.
One exception, for threads that are genuinely expensive to rebuild: a long piece of reasoning, or a dozen attached files. There, ask the existing chat to summarize the state of play and the decisions made so far, check that summary yourself, and open the new chat with it. You are still starting over. You are just not retyping an hour of work to do it.
If the same constraint keeps getting violated, stop restating it in every new chat. Put it somewhere the tool reads automatically: custom instructions, project instructions, whatever your assistant calls its standing setup. A non-negotiable that lives in the settings survives every restart, which is the whole point. And if a task keeps needing the same setup, that is the signal to stop retyping it altogether and build it once. Build a Reusable AI Assistant covers making the good version the default. And the underlying reason all of this happens, including why long threads decay, is in Why ChatGPT Forgets What You Told It.
When correcting in the thread is fine
Not every correction needs a fresh start, and pretending otherwise would waste your time.
In-thread fixes work well when they are additive and local: make it shorter, use American spelling, drop the third bullet, make the tone warmer. You are adjusting a result the model already got broadly right, and nothing about your instruction contradicts what it already decided.
They work badly when they are substantive: when you are correcting a fact, a calculation, or the model’s understanding of the goal. Those are exactly the cases where it has already built on the wrong assumption, and exactly the cases where agreeing with you is easier than reworking the reasoning.
The rough line: if your correction could be applied to the existing answer with a pen, do it in the thread. If it means the answer should have been different from the first sentence, start again.
The takeaway
A wrong answer is information, not a negotiation. The research says a conversation makes models less reliable rather than less capable, and that they lean toward agreeing with whatever you assert.
So diagnose before you retype. Missing fact, misread goal, task too big, or genuinely can’t. Three of those four are solved by a fresh chat with a better first message, and the fourth is solved by doing it yourself. Either way it beats arguing with something built to concede.
Sources: the 39% figure, the 200,000 simulated conversations and the “get lost and do not recover” finding are from LLMs Get Lost In Multi-Turn Conversation (opens in a new tab) (Laban, Hayashi, Zhou and Neville; ICLR 2026, preprint May 2025), which compares single-turn and multi-turn performance across six generation tasks. The 39% is an average relative drop across those tasks, not a figure every model hit. Note the conversations were simulated rather than observed from real users, which the authors are explicit about. The sycophancy findings are from Towards Understanding Sycophancy in Language Models (opens in a new tab) (Sharma et al., Anthropic, ICLR 2024), covering five assistants; “answer sycophancy,” where a model wrongly admits a mistake after pushback, is one of the specific behaviors it tests. The four-cause diagnosis and the restart checklist are mine. They follow from the two findings, but no study tested them, and I am offering them as practice rather than as a measured result.
Related: How to Check AI’s Work: You’re Looking for the Wrong Mistake is the step before this one, on catching the error in the first place. Giving AI Context: The Skill That Actually Makes It Useful is what a good restart message is made of.