Lost in Conversation: How Intent Mismatch Breaks Multi-Turn Chats with LLMs

The original method from the paper is a three-component system:

STEP 1: The Refiner analyzes the history Input: Contrastive pairs (a failed dialogue D- vs a successful request D+) → Output: A set of interpretation rules E = {e₀, e₁, ..., eₙ}

STEP 2: The Mediator rewrites the request Input: The current dialogue context Cₜ + rules E → Output: A clear instruction Û

STEP 3: The Assistant does the task Input: The clear instruction Û → Output: Result R

_(Requires separate calls and some coding to automate)_

⚠️ Where the method shines: Iterative tasks where you refine requirements as you go. Personal projects with an interaction history.

Task: You're an editor at a media outlet and you constantly ask ChatGPT to rewrite copy. The model keeps making it too formal, even though you want a conversational tone. Every time it takes 3-4 rounds of "make it simpler," "cut the corporate-speak," "write it like you're telling a friend."

Prompt (the principle adapted for chat):

First, rewrite my request as a clear instruction.

My communication patterns:
- When I say "rewrite", I mean: keep all the facts and structure, change only the style
- My default style: conversational, short sentences, no corporate jargon or clunky participle phrases
- Unless I say otherwise, the target audience is educated US readers aged 25-40
- When I give an example phrase in quotes, it's a tone reference, not something to paste in literally

Here's my request: 
Rewrite this paragraph about the new feature in Slack.

[your text]

First show me: how you understood the task (style, tone, what to change, what to keep).
Then give me the result.

Result: The model will first spell out its interpretation: "Here's how I read it: keep the facts, but deliver them conversationally, without 'is being implemented' and 'within the framework of.' Tone like a normal post, target audience — tech folks and active social media users." Then it gives you the text. You see WHAT the model took away from your request — and if it's off, you correct the interpretation before the work, not after.

The LLM's weakness: The model can't read minds. It's trained to guess the intent of a statistically average user from millions of examples. When you write vaguely ("rewrite," "make it better"), the model fills the gaps with its own assumptions about the "average rewrite request." Those assumptions often don't match your real criteria, because everyone has their own patterns and expectations.

The LLM's strength: The model does the task brilliantly when the intent is stated explicitly. When the instruction is detailed and unambiguous, the model spends all its intelligence on execution, not on guessing "what did they actually mean?"

How the method uses this: The Mediator principle splits the job in two. First — rewriting the vague request into a clear one, accounting for the context and patterns of the specific user. Then — executing against a clear instruction. This strips uncertainty out of the model's input. Instead of "guess what they want," the model gets "here's the exact spec, go."

Control knobs in the adapted prompt:

• The "My communication patterns" block → add your own interpretation rules. The more precisely you describe your request style, the less the model has to guess.

• "First show me how you understood" → drop this line if you only want the result without commentary. But for multi-turn refinement it's better to keep it — you'll catch interpretation gaps BEFORE the work is done.

• Reference examples → instead of abstract rules, show concrete "bad / good" pairs. Models pick up patterns from examples better than from descriptions.

The original method requires coding (Refiner, history, automatic routing). But the principle can be applied by hand in a regular chat.

🔧 Technique 1: "Clarify first, then do"

Instead of a direct request, ask the model to restate your task before doing it:

Here's my task: [your request]

First:
1. Restate the task in your own words — how you understood it
2. Point out what's unclear or could be interpreted different ways
3. Suggest clarifying questions

Then I'll adjust, and you'll do the precise version.

Effect: The model makes its assumptions explicit BEFORE doing the work. You see where it's filling in blanks and fix the interpretation up front, not after three failed attempts.

🔧 Technique 2: Contrastive examples from your history

Show the model your successful and failed interactions on a similar task:

I often ask you to [type of task].

Here are two examples of my past requests:

BAD RESULT:
My request: [what you wrote]
Your answer: [what the model produced]
Problem: [what was wrong]

GOOD RESULT:  
My request: [what you wrote]
Your answer: [what the model produced]
Why it worked: [what was right]

Now my new task: [current request]

Follow the pattern from the good example.

Effect: The model sees WHAT EXACTLY you count as success. It's like few-shot prompting, but for interpreting your intentions rather than the output format.

🔧 Technique 3: A personal system prompt

Create a dedicated chat with a profile of how you communicate in the system message:

You are my assistant for [task domain].

My patterns:
- When I say [X], I mean [Y]
- My default style: [description]
- Unless I say otherwise, my audience is: [who]
- Level of detail: [how much]
- Output format: [which]

IMPORTANT: If my request could be interpreted different ways — 
first show how you understood it, then ask whether it needs adjusting.

Effect: Every new request in that chat is automatically interpreted through your rules. No need to re-explain the context every time.

🔧 Technique 4: "Reflect before executing" (meta-prompt)

Ask the model to apply Mediator logic to your request:

Here's my request: [your task]

Before doing it:

1. INTENT INFERENCE:
   - What I said explicitly
   - What I imply but didn't say
   - What assumptions you're making about my criteria

2. AMBIGUITY CHECK:
   - Which parts of the request could be read different ways
   - Which details I didn't specify

3. RECONSTRUCTED REQUEST:
   - A complete, clear instruction reflecting how you understood the task

Show all three. I'll say "OK" or adjust point 3.
Then you'll do the final version.

Effect: The model explicitly separates guessing the intent from doing the work. You see its whole chain of interpretation and can step in at exactly the right point.

You're helping me with {task_type}.

MY COMMUNICATION PATTERNS:
- When I say "{typical_phrase}", I mean: {what_you_really_want}
- Default style: {style_description}
- Default audience: {who}
- {rule_3}
- {rule_N}

CONTRASTIVE EXAMPLES:
Bad example:
Request: {what_doesnt_work}
Problem: {why}

Good example:
Request: {what_works}
Why it worked: {reason}

RULE: If my request could be understood different ways — 
first show HOW YOU UNDERSTOOD the task, ask whether it needs adjusting,
then do it.

---

Current task: {your_request}

What to fill in: - {task_type} — the domain: rewriting copy, code review, idea analysis, etc. - {typical_phrase} — your go-to wording ("rewrite," "improve," "check this") - {what_you_really_want} — what you actually mean by that phrase - Contrastive examples — pull them from real history: what did NOT work vs what did - {your_request} — the specific task right now

🚀 Quick start — paste into the chat:

Here's a template for a personal profile that interprets my requests. 
Ask me questions to fill in the {in_braces} fields.

[paste the template above]

The model will ask: what kinds of tasks you usually give, which phrases you use, which style you prefer, whether you have examples of failed and successful requests. These questions help build your "communication profile" — a set of rules for interpreting YOUR wording, not that of the averaged-out user from the training data.

⚠️ Needs an interaction history: To build a personal profile, you need examples of your successful and failed requests. For new kinds of tasks you've never done with the model, the technique pays off less.

⚠️ Adds a step: Mediator logic means rewriting first, executing second. That's two requests instead of one. For simple, unambiguous tasks ("translate this into Spanish") it's overkill.

⚠️ Subjective criteria are harder: If your criteria are fuzzy even to you ("make the text more interesting"), it's hard for the model to extract a clear rule from examples. It works better for tasks with explicit quality criteria (format, style, structure, audience).

The team took the LiC (Lost in Conversation) benchmark and ran several top models through it: GPT-4o-mini, GPT-5.2, DeepSeek-V3.2-Thinking. They tested four domains: Code, Database, Actions, Math. They compared three scenarios: (1) Full — the user gives a complete, clear instruction in one request, (2) Sharded — the same task, but split across several turns with vague wording, (3) w/ Mediator — the vague request is first rewritten by the Mediator, then sent to the model.

Key finding: The quality degradation in multi-turn dialogue is constant (~60% relative drop) across all models, regardless of size and architecture. Even the reasoning model DeepSeek-V3.2-Thinking with its internal Chain-of-Thought can't cope — reasoning doesn't help when the information simply isn't in the context. This confirms the problem isn't a lack of horsepower but a structural gap between what the user wants and how the model interprets it.

Why it happens: All models are trained on similar data and aligned to the "average user." When the context is incomplete, they fill the gaps with a population prior — the statistically most likely intent. This leads to generic convergence (an averaged-out interpretation): the model confidently answers the "average" question, not yours. Scaling up parameters only strengthens this prior without closing the gap with the actual person.

The Mediator solution: The researchers built a system of three LLM components. The Refiner analyzes contrastive pairs (a failed dialogue vs a successful request) and extracts "experience" — a set of interpretation rules for a specific user. The Mediator uses that experience to rewrite a vague request into a clear instruction. The Assistant executes the task against the now-unambiguous spec. Result: quality recovers by 15-45% depending on the domain. In Actions-type tasks (sequences of actions) the gain is especially strong (+40-45%), because that's where people most often make implicit references to earlier context.

"Intent Mismatch Causes LLMs to Get Lost in Multi-Turn Conversation"
Geng Liu, Fei Zhu, Rong Feng, Changyi Ma, Shiqi Wang, Gaofeng Meng
City University of Hong Kong, Centre for Artificial Intelligence and Robotics HKISI CAS, Jilin University

Related work:
- Laban et al. (2025) — the original Lost in Conversation (LiC) benchmark - Zamfirescu-Pereira et al. (2023) — a study of how users iteratively formulate goals - MTBench, MT-Bench-101, LOCOMO — benchmarks for multi-turn dialogue