Your agent understood the first request and missed the real one

People work out what they need while talking

Consider a customer who asks an agent to move a delivery to Friday. After checking the available slots, they add that nobody will be home until late afternoon. Then they explain that one item is a gift and must arrive before a birthday. The initial request was about a date. The actual decision involves timing, urgency, and possibly splitting the shipment.

An agent can answer every message politely and still solve the wrong problem. It might preserve Friday as the main objective, choose the earliest slot, and describe the booking as complete. The failure is visible only if someone follows how the customer’s requirements changed.

Research has begun to measure this distinction more directly. In LLMs Get Lost in Evolving User Intent, published as a July 2026 preprint, researchers converted static tasks into conversations where requirements are revealed, revised, or redirected. Strong performance on the static versions did not reliably transfer to those changing conversations. The study is evidence about the tested tasks and models, rather than a failure rate for deployed assistants. [1]

Product teams should examine how their tests present the request. A test that supplies the final, complete request at the beginning removes a central part of the experience you are trying to build. Real users often need the conversation to reach that request.

Early assumptions become expensive after an action

The risk grows when an agent treats its own interpretation as established fact. Suppose it decides that “the account” means a personal subscription. Later references to colleagues and shared invoices may be read through that assumption, even though the user meant a business account.

Earlier work by Microsoft and Salesforce researchers examined more than 200,000 simulated conversations. Their May 2025 paper reported substantial degradation when task information was spread across turns, and identified premature assumptions and reliance on earlier responses as recurring problems. The experiments concern a particular generation of models, and the failure pattern gives teams a specific behaviour to test. [2]

One way to address this is to maintain a small, explicit record of the current request. It should distinguish facts the user confirmed, preferences inferred from context, and unresolved questions. When the customer says “actually, use the office address,” the old destination should become superseded rather than remaining an equally plausible option in the conversation.

This record also needs to connect to actions already taken. Updating a plan after a booking has been submitted is different from updating a plan before submission. The agent should know whether it is selecting, requesting, awaiting confirmation, or modifying something that already exists.

That does not mean forcing users through a form after every message. It means doing the bookkeeping inside the product, then asking for clarification when uncertainty would materially change the next action. A small question at the right moment can prevent a much longer correction later.

A valid answer can still be a poor choice

Understanding intent also includes preferences that do not fit a strict pass-or-fail rule. A customer might accept any appointment this week but strongly prefer one that avoids a long journey. A sales prospect might be eligible for several packages but care most about a predictable monthly bill.

Apple’s COMPASS research, published in December 2025, makes this distinction explicit through travel planning. It evaluates hard constraints alongside softer preferences and reports gaps between finding an acceptable plan and finding a better one. It also examines the difficulty of coordinating several services in the same plan. [3]

Applied to a business agent, that suggests separating requirements from tradeoffs. “Under $500” is a limit. “As little disruption as possible” is a preference that needs interpretation. If two options satisfy the limit, the agent should explain the relevant difference instead of declaring the first available option the best.

For brands, this matters because the choice reveals whether the company listened. An agent that repeatedly pushes the highest-priced eligible option may technically satisfy a sales workflow while frustrating customers who asked for simplicity. A support agent that chooses the cheapest remedy may miss that the customer values certainty more than a small refund.

The evaluation therefore needs a reason for preferring one acceptable outcome over another. That reason should come from product policy or customer evidence. It should not be invented by a model grader after the conversation has finished.

This is also where personalization needs restraint. An old preference is useful context, not a permanent instruction. Someone who usually prefers email may ask for a call today because the issue is urgent.

Test the conversation at the moments when it changes

A test suite can start with a normal customer journey and change one meaningful detail at a time. Reveal a constraint late. Correct a record identifier. Withdraw permission for an action. Ask about a second issue before the first one is complete. Resume after a long pause.

Then inspect what the agent does next. Does it revise the plan? Does it cancel an action that has not yet run? Does it explain that an earlier action needs reversal? Does it carry the new requirement into the tool arguments, or only acknowledge it in prose?

One particularly revealing test places the correction immediately before a consequential operation. A customer changes the recipient after the agent has prepared a shipment. The system should check the latest confirmed state before submitting. Otherwise, the conversation can look responsive while the integration sends the old address.

Clarification should be evaluated for usefulness as well as frequency. An agent that asks five unnecessary questions may avoid mistakes by making the customer do the work. Track whether each question resolves a real ambiguity and whether information already supplied is requested again.

Clients commissioning these systems can help by sharing examples of misunderstandings their staff encounter. “Next Friday,” “the other invoice,” and “cancel that” may be easy in one context and ambiguous in another. The goal is to cover the structure of those situations, not to memorize a list of phrases.

Finally, review the result from the user’s latest request. A task completed perfectly against an abandoned plan should not receive full credit. That single change in grading can reveal failures that ordinary answer-quality reviews miss.

Build tools that show how intent changes

The next generation of conversation tooling could make changes in intent visible. Developers should be able to inspect when a constraint appeared, which earlier assumption it replaced, and whether the next action used the updated state. Coding agents could use the same record to repair memory handling or add a missing confirmation step.

Conversation simulators could then generate controlled variations around verified customer cases. Their value would come from realistic changes in behaviour, with human reviewers checking that the simulated users remain plausible. A perfectly cooperative synthetic customer would leave the original problem untouched.

There is also room for a preference-testing tool that compares acceptable outcomes, explains why one better serves the current user, and flags when a commercial objective overrides an explicit request. These tools would help teams develop agents that can keep listening after the first interpretation, which is where customers often reveal what matters to them.