A preprint posted July 22 finds that language model agents fail hardest not when conversations get long, but when what the user wants changes partway through. In LLMs Get Lost in Evolving User Intent, researchers Jihoon Tack, Philippe Laban and Jennifer Neville show that performance falls broadly across frontier and open models as a goal evolves - and that the sharpest failures come from task switches, where a user moves to a related job while some earlier context still applies.
Key facts
- The paper is a July 22, 2026 preprint by Jihoon Tack, Philippe Laban and Jennifer Neville.
- It names three transition types: reveal (a new constraint appears), revision (an old value is corrected), and function switch (the task itself changes).
- A turn-count control confirmed the degradation comes from changing intent, not from conversation length.
- Even an oracle recap of the current goal leaves performance below the equivalent one-shot task.
The failure is bookkeeping, not memory
The usual explanation for agents going wrong in long conversations is that they forget. This paper argues something more specific and more fixable-sounding. An agent has to maintain an editable model of the current goal: add constraints as they are revealed, overwrite constraints that have been superseded, and recognize when the user has moved to a related task while keeping only the context the two tasks share.
Those three operations fail at very different rates. Models are nearly fine at absorbing a newly supplied argument or a corrected value. They are markedly worse at tracking repeated task switches - and the damage is not immediate. The paper's observation is that models often recognize a new task right away, and then lose the correct combination of pre-switch context and new requirements over the edits that follow.
In coding-agent runs, this shows up in the tool budget. Some agents spent almost all of their available tool calls re-exploring rather than executing or testing - which is what working hard on an obsolete internal plan looks like from the outside. That is a state-update failure, not a shortage of context window.
How they measured it
The method is the part that makes the result credible. Rather than writing new conversational benchmarks by hand, the authors took existing verifiable one-shot tasks - math problems, SQL queries, deep research, software patches - and turned each into a conversation whose final turn is the original task. Earlier turns are synthesized backward: plausible earlier requests, wrong values that get corrected later, related predecessor tasks. Because the last turn is the original problem, the source task's existing checker still scores the answer exactly as before.
That design isolates the variable cleanly. And the authors ran the obvious control: repeating turns without changing intent did not produce the degradation. Replacing those repeats with intent changes did. This is a test of changing requirements, not a generic long-conversation test - a distinction most agent evaluations do not make, as our guide to how AI gets benchmarked discusses.
Prompting does not fix it
The paper's most useful negative result concerns remedies. Telling the model to reread the conversation helps somewhat, and does not close the gap. More per-turn reasoning was not a reliable cure. Most tellingly, an oracle recap - an external system explicitly restating the current goal and all applicable latest constraints - improves results but still leaves performance below what the same model achieves on the same task asked once, cleanly.
That last finding is the one builders should sit with. If a perfect summary of the current state is not enough, the residual damage is coming from the conversation history itself, not from the model failing to know what it should be doing.
What did help, in a small pilot, was training: the authors trained a 4-billion-parameter model with reinforcement learning on synthetic evolving-intent examples, and dynamic-task performance improved while static-task performance held. That points toward training and stateful architectures rather than better prompting, though a pilot on one small model is not evidence of a production-ready fix.
What to do about it now
The design implication is to stop treating a user update as another line of chat history and start treating it as a structured state operation. Maintain the active task, current values, superseded values, shared constraints, and an explicit re-plan boundary when the task switches. A recap prompt is a reasonable guardrail. A system that owns and verifies that state - rather than hoping the model reconstructs it from transcript - is the more credible remedy. Our explainer on agent memory covers the storage side of this; the paper is about the update side, which gets far less attention.
The honest caveat
These are synthetic trajectories. Exact verification happens only at the final turn, each user turn contains at most one transition, and parts of the pipeline use model-generated extraction and simulation with rejection checks. The paper demonstrates a controlled failure mode; it does not establish how often this happens in uncontrolled production agent logs. The practitioner complaints that match its description - agents drifting toward assumptions from earlier iterations, or treating the first ask as final - are corroborating anecdote, not measurement.
Originally published on Ground Truth, where every claim is checked against the primary source.
Top comments (0)