The User Is Present: Why Smart Agents Still Don't Get You

TL;DR for operators

Most agent demos show the easy part: the model calls a tool, gets results, and returns something plausible. The harder part is less cinematic. The user starts with an incomplete request, reveals constraints in fragments, phrases preferences indirectly, changes emphasis mid-conversation, and expects the system to somehow keep up. This is where many supposedly “smart” agents begin to look less like assistants and more like interns with excellent API access.

The paper behind UserBench argues that current LLM agents are not mainly failing because they cannot search. They often can. The deeper failure is that they do not reliably uncover what the user actually wants, and even when they do, they may not integrate those preferences into the final recommendation.¹

For operators, the useful lesson is not “travel-planning agents are bad”. That would be too small, and frankly too easy. The lesson is that agent evaluation needs to separate three capabilities that are often blurred together:

UserBench’s headline is uncomfortable: models can achieve high valid-search rates while still aligning with all user intents only around 20% of the time on average. In the main single-choice setting, even strong models actively elicit only a minority of user preferences. Claude-4-Sonnet reaches the highest total preference elicitation in that setting, but its active elicitation rate is still only 26.31%. In the multi-choice setting, Claude’s active elicitation rises slightly above 30%, but the broader pattern remains: asking enough of the right questions is not yet a solved behaviour.

That matters for any business deploying AI agents in sales, support, procurement, travel, wealth advisory, HR, or internal operations. The agent that moves fast but misunderstands quietly is not efficient. It is just producing rework at machine speed. Lovely.

The missing user is the mechanism, not a UX footnote

A standard tool-agent benchmark often treats the user as a starting prompt. The user says what they want; the agent acts; the result is graded. That is convenient for evaluation. It is also not how most work happens.

In real workflows, users rarely begin with a perfectly specified request. They say “find me a good hotel”, “prepare a supplier shortlist”, “recommend a policy”, “book something convenient”, or “make it suitable for the client”. Each phrase hides operational detail. Good for whom? Convenient relative to what? Suitable under which constraints? Cheap until what trade-off becomes unacceptable?

UserBench builds its evaluation around this communication problem. It focuses on three traits of user behaviour:

1. Underspecification: the initial request is incomplete.
2. Incrementality: preferences appear over multiple turns.
3. Indirectness: the user may imply rather than explicitly state what they want.

The domain is travel planning, but the mechanism is general. A simulated user asks for help across travel aspects such as flights, hotels, apartments, rental cars, and restaurants. The agent sees only high-level trip information at first. Specific preferences are hidden inside the environment and revealed only if the agent asks concrete preference-relevant questions, or passively after the conversation drifts for too long.

That design choice is the paper’s strongest contribution. It moves the evaluation target from “can the model complete a task?” to “can the model co-construct the task with a user?” That sounds like a soft distinction until you try to run an actual process with an agent. Then it becomes the whole machine.

A procurement agent that searches supplier databases but never asks about payment terms, delivery risk, preferred certification, or local compliance is not user-centric. A customer-support agent that immediately recommends a plan without clarifying urgency, existing setup, budget, or non-negotiables is not proactive. It is just prompt-shaped guessing.

UserBench makes that guessing measurable.

UserBench turns vague intent into an executable environment

The paper implements UserBench as a Gymnasium-style environment. That matters because it frames user interaction as something agents can repeatedly experience, score, and potentially train against. The environment supports a standard interaction loop: reset, step, observe, act. The tested agent can choose among three broad actions:

The benchmark constructs travel scenarios by combining preferences across five aspects: flight, hotel, apartment, rental car, and restaurant. These preferences are paired with implicit natural-language expressions. For example, a direct-flight preference may not be stated as “I want a direct flight”, but as a comment about a packed schedule and a desire to minimise transit time. That is exactly the sort of phrasing humans use when they assume the other side can infer the obvious. The other side, unfortunately, is now a model.

The search environment is also controlled. Instead of relying on live web data, UserBench uses pre-generated option databases. Each scenario includes options that are correct, wrong, noisy, or budget-best. Wrong options violate at least one preference. Noise options are irrelevant or unrealistic. Under the budget-constrained setting, the best option is the lowest-cost option among those satisfying the relevant preferences.

This design strips away one common excuse. If an agent fails, it is not because the web changed, the API timed out, or the hotel inventory was messy. The database is controlled. The options are labelled. The challenge is whether the agent can uncover enough user intent, search appropriately, and choose well.

That is why the benchmark is useful for business readers. It does not test whether agents can survive the chaos of production systems. It tests a more basic question: even in a controlled world, can the agent behave like it understands the person in front of it?

The main result: search works better than understanding

UserBench evaluates a range of closed and open models, including GPT-4o, Gemini-2.5-Pro, Claude-4-Sonnet, Deepseek-V3, Qwen3 variants, Llama variants, GPT-4o-mini, and Gemini-2.5-Flash. The main evaluation uses a single-choice setting: the agent may output only one option per travel aspect. This is stricter than the multi-choice setting, where the model can offer multiple options and receive credit if one of them works.

The distinction matters. Multi-choice lets a model hedge. Single-choice forces commitment. Businesses usually need commitment. A procurement shortlist can include alternatives, yes, but a booking, policy decision, credit recommendation, or support action eventually has to choose.

In the single-choice setting, the results are not flattering. GPT-4o achieves the highest score at 0.329, followed closely by Gemini-2.5-Pro at 0.317 and Claude-4-Sonnet at 0.307. These are not catastrophic in the “model does nothing” sense. They are catastrophic in the “we were promised autonomous agents” sense.

The more revealing pattern is the split between valid search and user understanding.

GPT-4o has an 82.48% valid search-attempt rate in the single-choice setting. Gemini-2.5-Flash reaches 83.62%. Qwen3-32B reaches 79.42%. In other words, several models can issue syntactically and semantically valid searches quite often.

But valid action attempts are much lower. These measure whether the agent’s user-facing actions are concrete, targeted questions that successfully probe real preferences. Claude-4-Sonnet has a 24.26% valid action-attempt rate in single-choice, GPT-4o has 27.82%, and Gemini-2.5-Pro has 29.26%. Some models are lower still.

Preference elicitation tells the same story. Claude-4-Sonnet has the highest total preference elicited in the single-choice table at 34.25%, but only 26.31% comes from active elicitation. GPT-4o elicits 27.32% total, with 24.06% active. Gemini-2.5-Pro elicits 29.71% total, with 23.85% active.

So the agent can often search the database. It just does not reliably ask the user the questions needed to make the search meaningful.

That distinction is the business argument. Tool reliability is not the same as workflow reliability. A model can call the CRM correctly and still misunderstand the sales rep’s intent. It can search a catalogue correctly and still recommend the wrong SKU. It can retrieve policy documents correctly and still fail to ask whether the employee is full-time, probationary, remote, union-covered, or in a jurisdiction with different rules.

API competence is necessary. It is not the same thing as judgement.

The multi-choice setting exposes a familiar enterprise trick: hedging

The paper also evaluates a multi-choice setting. Unsurprisingly, scores improve. GPT-4o rises to 0.710, Gemini-2.5-Pro to 0.673, and Claude-4-Sonnet to 0.612. Correct Exist Rates also rise substantially.

At first glance, this looks like progress. It is partly progress. Giving several answers increases the chance that one option is acceptable. In some business contexts, presenting a ranked set is a valid strategy.

But the paper’s interpretation is more pointed: multi-choice gains do not necessarily come from better user understanding. Preference elicitation does not consistently improve. For GPT-4o, total preference elicited actually drops from 27.32% in single-choice to 15.10% in multi-choice. Deepseek-V3 also drops. Some models improve, but the improvement is not systematic enough to support the comforting story that “more options means more understanding”.

More options can simply mean broader coverage. The model throws more candidates into the basket, and one survives. That is not collaboration. It is a polite form of brute force.

This distinction should be familiar to anyone who has used AI tools in real work. The model gives five options, one of which is almost right. The user then does the missing judgement work: filtering, correcting, merging, and explaining what should have been understood earlier. The model appears helpful because it produced material. The user pays the hidden coordination cost.

UserBench gives that cost a name.

The real difficulty is preference density, not just task size

The paper’s analysis section is useful because it does not stop at the leaderboard. It asks what makes the benchmark hard.

The first answer is straightforward: harder tiers produce lower scores. UserBench divides scenarios into easy, medium, and hard based on preference complexity, and model performance generally declines as difficulty increases. That supports the benchmark’s tiering.

The more interesting answer is about where preferences sit. The authors test whether difficulty comes mainly from the number of travel aspects or from the number of preferences attached to each aspect. The result: models struggle particularly when multiple preferences are concentrated within the same aspect.

That is a practical insight. It is easier for an agent to handle one preference for a flight, one for a hotel, and one for a restaurant than to handle several interacting constraints inside the hotel decision alone. A hotel might need parking, a specific rating range, a room type, pet-friendliness, a location trade-off, and budget optimisation. The agent has to hold all of that locally while comparing options. That is where shallow matching breaks.

For enterprise workflows, the equivalent is not “more departments”. It is constraint density inside one decision.

A contract-review agent may handle “find the governing law clause” well. It may struggle when the user wants a clause that balances jurisdiction, indemnity, renewal mechanics, data-processing obligations, and negotiation posture. A finance agent may retrieve ratios correctly but struggle when the decision depends on liquidity, covenant sensitivity, FX exposure, seasonality, and management commentary at the same time.

The problem is not only breadth. It is compression. Can the agent keep several preferences active inside one recommendation without dropping one quietly under the table? UserBench suggests the answer is often no.

Speed can be a failure mode

One of the better parts of the paper is the weighted timing analysis. It asks not just whether models eventually find a good answer, but when they do. Late correctness is not useless, but interaction has a cost. Users do not want an agent that needs twenty turns to discover the first obvious constraint. They also do not want one that guesses in turn two and creates a mess.

The paper finds a tension. Some smaller models produce earlier valid attempts, but those early attempts often look like shallow guesses rather than genuine understanding. Stronger models such as GPT-4o and Gemini-2.5-Pro do better at balancing timing and coverage, but even they are not immune to premature answering.

This is highly relevant for deployment. Many agent products optimise visibly for speed because speed is easy to sell. The answer appears quickly. The workflow moves. The demo feels alive.

But premature action can be worse than delay. In high-friction tasks, a fast wrong recommendation consumes user trust. In regulated or expensive domains, it can also consume budget, compliance capacity, and management patience. The agent that asks two specific questions before acting may feel slower, but it may reduce the number of downstream corrections.

The operational design target is therefore not “ask more questions”. That would create the opposite pathology: the agent as bureaucratic chatbot. The target is calibrated interaction: ask when the missing preference materially affects the decision, search when search can narrow the space, answer when enough constraints have been uncovered.

UserBench does not fully solve that policy problem. It does, however, make the trade-off visible.

More turns and more samples are not a cure

The paper includes additional analyses that are best read as robustness and behaviour probes, not as separate theses.

First, increasing the number of allowed interaction turns does not reliably improve performance. In some cases, performance degrades. This means the problem is not merely that models need more time. Without better dialogue planning and state tracking, extra turns can produce repetition, drift, or irrelevant conversation. The model has more rope. It does not necessarily build a bridge.

Second, pass-style sampling shows instability. The maximum score improves when more samples are drawn, but the average score stays flat or even declines. That means repeated sampling may help find a lucky good trajectory, but the typical trajectory remains weak. This is not reassuring for production systems where repeated calls cost money and users do not experience “best of many hidden attempts”. They experience the one answer put in front of them.

Third, reducing wrong and noisy options helps, but does not remove the core difficulty. This is an ablation: it tests whether the benchmark is hard mainly because the option set is cluttered. The result is that fewer distractors generally improve scores, but only modestly for strong models. The remaining challenge is still preference understanding and best-option selection under constraints.

A useful way to read the evidence is:

The practical conclusion is quietly brutal: the usual engineering patches do not fully solve the issue. More turns, more candidate answers, more samples, and cleaner search results help around the edges. They do not replace a policy for discovering and using user intent.

What businesses should test before trusting an agent

The paper’s direct evidence is about simulated travel planning. The business inference is broader: any user-facing or employee-facing agent should be evaluated on the interaction mechanics that happen before the final answer.

A useful evaluation suite should include at least five checks.

First, test underspecified starts. Do not give the agent fully polished prompts. Start with the sort of vague request a real user would give: “find a good venue”, “prepare the renewal options”, “recommend a supplier”, “help me decide”. Then measure whether the agent asks useful questions before acting.

Second, score question quality, not just question count. “Any preferences?” is cheap. “Do you need parking at the hotel, or is proximity to public transport more important?” is more useful. UserBench’s distinction between vague and concrete preference questions is exactly the right instinct.

Third, track preference retention. If the user indirectly reveals a constraint in turn four, does the agent still apply it in turn twelve? Many failures in real workflows are not failures to hear the preference. They are failures to carry it into the decision.

Fourth, separate search validity from recommendation quality. A valid search query is not a successful task. It is an intermediate behaviour. Dashboards should reflect that distinction. Otherwise teams will overestimate agent readiness because the tool-call layer looks healthy.

Fifth, include budget-aware or cost-aware scoring. The best business option is rarely “any option satisfying the stated preference”. It is the option that satisfies the relevant constraints at acceptable cost, risk, time, or effort. UserBench’s budget-aware best-option framing is simple, but the principle travels well.

This is where many enterprise pilots become misleading. They test whether the agent can complete a happy-path workflow. They do not test whether it can discover the workflow’s hidden constraints. Then production users arrive with actual preferences, half-formed goals, and all the glorious mess of normal communication. The pilot team acts surprised. Nobody should be.

The boundary: a diagnostic warning, not a universal verdict

UserBench is valuable, but its boundaries matter.

The environment uses simulated users, with GPT-4o as the user simulator in the reported experiments. That allows scalable and reproducible evaluation, but simulated user behaviour is not the same as human behaviour. Real users can be inconsistent, impatient, strategic, annoyed, overly specific, culturally indirect, or simply wrong. A benchmark that controls the user is useful for diagnosis. It is not a full substitute for field testing.

The domain is also travel planning. Travel is a good testbed because it naturally involves multiple aspects, preferences, tools, and budget trade-offs. But it is still one domain. Procurement, legal review, wealth advisory, medical triage, and construction project coordination have different risk structures and different tolerance for ambiguity.

The option databases are pre-generated. This is a strength for controlled evaluation, because it isolates user-centric reasoning from live-search noise. It is also a boundary, because production agents must deal with unstable APIs, incomplete records, stale inventory, permission constraints, and adversarial or low-quality data.

The experiments are deterministic single runs with temperature set to zero. That improves reproducibility but does not fully capture deployment settings where sampling, routing, retries, memory, retrieval augmentation, or custom prompting may change behaviour.

Finally, UserBench evaluates a particular interaction design. Better system prompts, specialised training, richer memory, domain-specific preference schemas, and explicit clarification policies may improve performance. The paper is not proof that user-centric agents cannot be built. It is evidence that current general models do not reliably become user-centric just because we give them tools and a cheerful system prompt.

That is a reasonable boundary. Also a rather inconvenient one.

The real product question is whether the agent knows when it does not know the user

The agent industry has spent a great deal of energy making models act. Tool calls, browser control, function schemas, workflows, routers, memory layers, execution traces. All useful. None sufficient.

UserBench points to the next evaluation frontier: interaction judgement. A good agent needs to know when the missing information matters, how to ask for it, how to interpret indirect answers, when to search, when to stop searching, and how to fold everything into one decision. That is not simply “better UX”. It is the control policy of the agent.

For business adoption, the lesson is straightforward. Do not certify an agent because it completes a task on a fully specified prompt. Certify it because it survives underspecification without pretending the user has already said everything important. Test whether it asks concrete questions. Test whether it remembers the answers. Test whether it chooses differently after learning a preference. Test whether it avoids the seductive nonsense of fast confidence.

The user is not a prompt prefix. The user is part of the environment.

Agents that ignore that fact may still look impressive in demos. In production, they will keep searching correctly and recommending wrongly. A small miracle of automation, really: the wrong answer, delivered faster than ever.

Cognaptus: Automate the Present, Incubate the Future.