Why LLMs get worse in multi-turn conversations

A model can solve a task in one request and still fail unpredictably when the same requirements arrive over several turns. What it loses is not mainly capability. A capable model becomes undependable once the conversation accumulates partial instructions, provisional answers, and its own earlier mistakes.

Laban, Hayashi, Zhou and Neville measured this in LLMs Get Lost In Multi-Turn Conversation. Across 15 models, more than 200,000 simulated conversations and six generation tasks, multi-turn performance fell an average of 39% against single-turn. The decomposition is the real finding: aptitude fell 16%, while unreliability rose 112%.

Is the problem capability or reliability?

Reliability, overwhelmingly, and the difference decides your fix.

Capability asks whether a model can produce a correct result under favorable conditions. Reliability asks how often it does across valid conversations and requirement orderings. A 16% aptitude drop against a 112% rise in unreliability says the model still knows how; it has become erratic about whether it applies what it knows.

If this were a capability problem, a better model would fix it. It does not. The strongest models tested, including Claude 3.7 Sonnet, Gemini 2.5 and GPT-4.1, showed average degradations of 30% to 40%, comparable to Llama3.1-8B-Instruct and Phi-4. Buying a bigger model does not buy your way out of this failure mode.

It also explains why demos survive and products do not. A demo walks the clean path. Production conversations contain clarifications, corrections, incomplete constraints and user reactions to intermediate output. A benchmark sampling only the clean path measures aptitude and leaves unreliability entirely unobserved, which is the same reason reliability is a distribution rather than a score.

Why do long conversations degrade?

Each turn adds state the model has to interpret, prioritize and reconcile. Requirements arrive under-specified, the model commits to an interpretation, and later instructions collide with an earlier answer the dialogue now treats as established context.

Token count is not the variable people assume it is. Context rot concerns accuracy decay as input length grows; this is about the number and sequence of exchanges, and it appears in conversations whose accumulated text is not remotely long. A short conversation with one early wrong assumption fails for a completely different reason than a long prompt that overruns the model's effective attention.

What happens after a wrong turn?

An incorrect intermediate answer stops being a disposable attempt and becomes persistent state. The model continues from its own earlier output, so later reasoning inherits the mistaken premise unless the conversation explicitly replaces it. In the authors' words, when LLMs take a wrong turn "they get lost and do not recover."

The consequence for debugging is that a bad final response is often the endpoint of a contaminated trajectory whose decisive error happened several turns earlier. And a correction inside the same thread is not equivalent to a fresh, fully specified request, because the correction still carries the earlier answer and everything assumed around it.

What actually fixes it?

Structural changes to the conversation, not a model swap:

1. Restate before execution. Convert the conversation into one request carrying the goal, constraints, inputs, output format and unresolved decisions.
2. Put hard constraints early. Do not drip critical requirements into the thread after the model has already planned or acted.
3. Restart after contamination. Open a new conversation once the model has adopted a false premise, and supply corrected state without the failed trajectory.
4. Treat wrong turns as state corruption. A later "try again" does not remove the earlier answer from the model's effective context.

These are controls, not prompt decoration. Each one reduces dependence on the model noticing and repairing its own conversational error, which is precisely the thing the study shows it does not do.

Should an agent use one conversation for the whole task?

Only while the state stays coherent. Long-lived threads are convenient, and convenience is not evidence that the thread still represents the task accurately. Derive a clean task specification for execution and keep the user-facing conversation for interaction; when the specification changes materially, regenerate it rather than asking the model to reconcile every historical exchange.

Task duration is a separate axis worth not conflating: task length concerns capability across an extended sequence of actions, while this concerns reliability as exchanges accumulate. You can have short tasks with many turns, or long tasks with carefully maintained state. The controls overlap; the diagnosis does not.

One packaging option among several is a rented expert, such as the AI Experts sellers publish on Askpert, called over API or MCP with the underlying assets staying server-side. That does not remove multi-turn unreliability. It makes the state boundary and restart policy explicit, which is the part you can actually control.

How should you test for it?

Evaluate the same task in consolidated and multi-turn form, then compare average quality, variance, constraint preservation and recovery. Your test set needs valid conversations with different requirement orders, ambiguous early turns, corrections, and deliberately injected wrong intermediate states.

Separate four outcomes: whether the model had the aptitude, whether it solved the task on this run, whether it preserved every constraint, and whether it recovered after an induced error. An aggregate score cannot tell you whether a model is incapable or merely inconsistent, and those two diagnoses lead to opposite decisions.

Keep the task fixed while changing only the delivery format. If the single-turn version has a complete specification and the multi-turn version carries the same information across turns, the gap measures conversational handling rather than a change in difficulty.