When a Conversation Goes Bad, Restart It (Here's How)

TL;DR: Don't paste the old transcript into the new chat, extract from it. Ask the dying thread for four things: established facts, confirmed decisions with reasons, the current draft or code verbatim, and anything unresolved or contradictory. Paste that into the fresh conversation instead of the history, and the useful state survives while the failed framing, the repeated corrections, and the contradictions get left behind on purpose.

What Actually Needs to Survive the Restart?

Not the conversation. The conversation is where the thread went wrong, and pasting it wholesale into a new chat just imports the failure along with the parts worth keeping. What needs to survive is a smaller, cleaner list: the facts that got established, the decisions you actually made, whatever you were building, and anything still genuinely open.

This post assumes two things are already true. First, you've decided the thread is done, not worth patching, which is a separate question covered fully in when to start a new chat vs keep going: drift, contradiction, constraint decay, the cost and latency arithmetic of restarting. Second, this isn't about a single bad reply you could fix with one targeted follow-up; what to do when the first answer is bad covers that narrower, faster case. What's left, once both of those are settled, is purely mechanical: how do you carry the good parts of a longer, genuinely poisoned thread into a clean one, without dragging the poison along for the ride.

The reason this is worth doing carefully rather than just retyping from memory: models conditioned on a failing multi-turn conversation tend to compound the failure rather than correct it. In LLMs Get Lost In Multi-Turn Conversation (Laban et al., arXiv:2505.06120, submitted May 9, 2025, re-verified directly at arXiv on August 27, 2026), the authors write that models "make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely," across a simulation of more than 200,000 conversations, with an average 39% performance drop when a task was spread across turns instead of stated once. A restart works because it removes that accumulated commitment. It only works fully if what you carry forward is the state, not the mess that produced it.

Which Parts of a Long Bad Thread Are Signal, and Which Are Poison?

A thread that's gone bad over many turns, not just one reply, usually contains four distinct things tangled together, and only two of them belong in the new chat.

The bad output itself. The wrong number, the generic draft, the broken function. This is the easiest to spot and the easiest to accidentally re-include, because it's often sitting right above the correction that made it into the record.

POISON, do not carry forward:
"Revenue grew approximately 40% in Q3, driven by strong performance
across all major product lines and continued market expansion."

Even quoting it back as a "don't do this again" example keeps its exact wording in the new thread's context, which is closer to repeating the mistake than avoiding it. If you need to reference what went wrong, describe the property in one clause instead of pasting the sentence.

The failed framing or approach. Not the specific bad sentence, but the angle that produced several bad sentences in a row: the wrong audience assumption, the wrong architecture, the wrong source treated as ground truth. This deserves one line of acknowledgment in the handoff, not the play-by-play of how it went wrong.

SIGNAL, one line only:
"We tried scoping this to enterprise buyers first; wrong audience,
this is actually a self-serve SMB pitch. Don't reopen that framing."

The one-line version tells the new thread what to avoid without re-deriving the whole tangent that produced it, and it's usually the single most valuable line in the entire handoff.

Meta-commentary about the corrections. The turns where you told it "no, not like that" and it apologized and tried again, three or four times. This is noise about the failure, not information about the task, and it's the single most common thing people accidentally carry forward by pasting a transcript instead of extracting from it.

POISON, do not carry forward:
"You're right, I apologize for the confusion earlier. Let me try
again with a clearer approach that better addresses your needs..."

None of it changes what the model should do next. All of it changes how much the new thread has to read before reaching something useful, and a thread that wades through apologies before finding the actual constraint tends to give them the same weight it gives everything else.

Contradictions. Two places in the same thread where the model told you different things about the same fact. The temptation is to silently pick whichever one felt more recent or more confident. Don't. Flag it instead.

SIGNAL, flagged rather than resolved:
"UNRESOLVED: earlier you said the API supports webhooks; later in
this thread you said it doesn't. Confirm against the actual docs
before this ships anywhere."

Recency isn't the same as correctness. The version stated last in a long thread isn't more likely to be right just because it's more recent, and treating it that way is the exact anchoring problem a restart is supposed to escape.

Facts and decisions are signal. Drafts and code, the actual artifact, are signal. The bad output, the abandoned framing's detail, and the apology-and-retry cycle are poison. Contradictions are signal, but only once they're flagged rather than quietly resolved.

Same scenario, two ways to hand it off. The first is what most people paste. The second is what actually survives:

MESSY, everything tangled together:
So earlier you said the audience was enterprise buyers, then I said
no wait it's actually SMB, sorry for the back and forth. Here's what
we had: "Our platform seamlessly transforms your business" which I
said was too generic, and you apologized and tried again with
"Introducing the next generation of..." which was also wrong, and
then we agreed the hook should be about offline mode, I think, and
the draft was getting close but I'm not sure this is the latest
version, let me just paste the whole thing so you have context.

CLEAN, the same information extracted:
FACTS: The product's differentiator is offline mode.
DECISIONS: Audience is SMB, not enterprise (corrected earlier). Hook
must lead with offline mode, not be buried in paragraph two.
ARTIFACT: [verbatim, most recent approved draft]
OPEN QUESTIONS: none.

The Extraction Prompt: Pulling a Clean Handoff Out of a Messy Thread

Run this in the thread you're about to leave, before you open the new one. It asks for the same four categories above, in a fixed order, with explicit instructions about what to exclude.

Before I leave this conversation, extract everything I should carry
forward into a new one. Output exactly these four sections and
nothing else:

1. ESTABLISHED FACTS
   Only things confirmed as true in this conversation: from me, from
   a file I pasted, or from a source you cited. No inferences, no
   summary of what we discussed, just the facts themselves.

2. DECISIONS MADE (one-line reason for each)
   Only choices I actually confirmed. If we discussed an option but I
   never approved it, leave it out entirely.

3. CURRENT ARTIFACT, VERBATIM
   The most recent version of whatever we're building: the draft, the
   code, the outline. Paste it exactly as it stands. Not a description
   of it.

4. OPEN QUESTIONS
   Anything unresolved, including anywhere you told me two different
   things about the same fact earlier in this thread. Flag it here
   rather than picking one silently.

Do not include: a narrative of how we got here, any output I rejected,
any correction I made to an earlier correction, or your own reasoning
about why an earlier attempt failed. I only want what's still true and
still needed, stated once.

Read the output before you paste it anywhere. Ask a follow-up if a section looks thin or a fact looks inferred rather than confirmed, since the model doing the extracting is the same model that helped generate the mess, and it can occasionally carry a wrong assumption into its own summary of what happened.

What If the Extraction Comes Back Thin or Wrong?

Sometimes the thread is degraded enough that the extraction itself is unreliable. The same model that lost track of your constraints twenty turns ago can lose track of them again while summarizing what happened. Two checks catch this before you carry a bad extraction into a fresh thread.

First, compare the DECISIONS section against what you actually remember confirming. If it's missing something you're certain you approved, or includes something you only floated as an option, correct it directly in that thread rather than trusting the new chat to catch the error later. A wrong decision restated with confidence is harder to catch downstream than an omission is.

Second, if any section comes back noticeably thinner than the conversation that produced it, ask for that section again on its own rather than accepting the whole extraction as final.

Redo just the DECISIONS MADE section. Go back through this entire
conversation again, not just the last few messages, and check for
anything I confirmed early on that may have been dropped.

A thin section is usually easy to spot once you're looking for it:

THIN, missing an early decision:
DECISIONS MADE:
- Use a formal tone.

RESTORED, after asking the model to re-check the full thread:
DECISIONS MADE:
- Use a formal tone, because this goes to the client's legal team.
- Keep it under 400 words, confirmed at the start of the conversation.
- Do not mention pricing; that's being finalized separately.

A degraded thread's summary of itself isn't automatically more reliable than the thread was. A minute spent checking the extraction is cheaper than discovering the gap three turns into the new conversation.

Does the Handoff Change by the Kind of Work You're Doing?

The four categories hold, but what counts as the "current artifact" and what counts as a "fact" looks different depending on what you were actually doing in the dying thread. A voice sample is the fact that matters for a writing project; a confirmed behavior is the fact that matters for a code session. Five variants below, each a starting point to adapt, not a form to fill in unchanged.

Writing or content work, where tone matters as much as content:

CARRYING FORWARD: [piece name] into a new thread.

VOICE SAMPLE (2-3 sentences already approved):
"""
[paste]
"""

FACTS THAT MUST STAY ACCURATE:
- [fact]

CURRENT DRAFT, VERBATIM (most recent approved section):
"""
[paste]
"""

Match the voice sample above. Do not infer tone from anything else
in this brief.

The voice sample matters more here than any description of tone would, because "friendly but professional" means something different to every model and every reader, while three real approved sentences don't need interpreting.

Code or technical work, where the artifact is the file, not a description of it:

CARRYING FORWARD: a coding session into a new thread.

STACK: [language / framework / versions]

CURRENT STATE OF THE RELEVANT FILE(S), verbatim (paste the actual
current contents below this line, not a summary of them):
[paste]

WHAT WE CONFIRMED WORKS:
- [behavior]

APPROACHES ALREADY TRIED AND ABANDONED (one line each):
- [approach], failed because [reason]

THE ACTUAL TASK, restated fresh: [one line]

Do not re-attempt [approach] unless I ask for it explicitly.

Pasting the actual file, not a description of the bug, is what stops the new thread from re-diagnosing a problem you already diagnosed and quietly proposing the same fix that didn't work the first time.

Research or analysis, where sources need to travel with their findings:

CARRYING FORWARD: a research task into a new thread.

QUESTION I'M ACTUALLY TRYING TO ANSWER: [one line]

SOURCES CONFIRMED, with what each established:
- [source]: [finding]

SOURCES THAT TURNED OUT UNRELIABLE (do not re-fetch):
- [source]

WHERE TWO SOURCES DISAGREE (name both, don't average them):
[fact]: Source A says X, Source B says Y. Unresolved.

WHAT'S STILL MISSING: [one line]

Naming what each source established, not just listing the source, is what lets you tell later whether a fact came from something solid or from something you never actually confirmed.

An ongoing plan or project, spanning more than one session:

CARRYING FORWARD: [project] into a new thread.

CURRENT STATE OF THE PLAN, verbatim:
"""
[paste the actual outline or roadmap]
"""

DECISIONS THAT ARE FINAL (not open for re-litigation):
- [decision], because [reason]

DECISIONS STILL OPEN:
- [question]

NEXT ACTION ONLY (not the whole roadmap): [one line]

Restating only the next action, not the whole roadmap, keeps the fresh thread from treating every future step as open for renegotiation just because it's mentioned.

Client or agency work, where the same assistant may be juggling more than one client's rules at once:

CARRYING FORWARD: [client name] work into a new thread.

CLIENT-SPECIFIC RULES THAT STILL APPLY:
- [rule: brand voice, banned words, approval process]

FACTS CONFIRMED FOR THIS CLIENT:
- [fact]

CURRENT DELIVERABLE, VERBATIM:
"""
[paste]
"""

DO NOT APPLY: any rule or preference from a different client's work,
even if something like it appears elsewhere in your instructions.

Keeping client-specific rules explicit in the handoff, rather than trusting a shared assistant to remember which client is which, is exactly the mix-up a per-client variable library exists to prevent.

The pattern repeats across all five: state what's confirmed, state what's still open, and paste the actual work product rather than a description of it. A prompt library that stores one of these per project type, rather than rebuilding the categories from memory each time you restart, is exactly what a saved prompt template is for.

Extraction Beats Pasting or Freehand Summarizing, and Here's Where Each One Breaks

How Do You Know the Restart Actually Worked?

Paste the extraction into the new thread, then check before you resume the task. This is a different check from deciding whether to restart in the first place. It runs after the handoff, to confirm it actually landed.

Before you do anything else with what I just gave you: restate, in
your own words, the three things you now believe are true about this
task, and name anything from what I pasted that you're still unsure
about. Do not start the task yet.

A clean restatement means the handoff took. A restatement that's missing one of your stated facts, or that's quietly guessing at something you flagged as open, means the extraction itself was thinner than it looked, and it's worth going back to the old thread and asking a sharper follow-up before you commit further turns to the new one. Research on drafting a single, fully-specified instruction rather than assembling one across turns backs up why this matters: Prompt Architects' analysis of 10,000 ChatGPT prompts found structured, fully-specified prompts produced a 62% higher first-attempt success rate than unstructured ones. A good extraction is what turns a scattered, multi-turn failure into exactly that kind of single, complete instruction.

The Rule, in One Line

Extract before you leave, never paste the transcript. Facts, decisions, and the actual artifact travel with you. The bad output, the abandoned framing's detail, the apology-and-retry noise, and any contradiction you haven't flagged stay behind on purpose.

If the thread that's failing you is failing on the very first reply rather than after many turns of accumulated damage, the faster repair moves for one bad answer are the right page, not this one. And if you want the root causes that put a thread on a bad path in the first place, missing role, missing format, context drift, why your ChatGPT answers are bad covers them before you ever reach the point of restarting.

Keeping a version of these four categories saved somewhere you can paste from, rather than retyping the sections from memory in the moment a thread finally breaks, is the difference between a thirty-second handoff and a rebuilt-from-scratch one. That's the gap between a Context Library you maintain deliberately and a chat history you're mining under pressure.