Abstract

LLM agents with tool-calling capabilities often fail when user instructions are ambiguous or incomplete, leading to incorrect invocations and task failures. Existing approaches operate in unstructured language spaces, generating clarifying questions through prompting strategies that lack principled criteria for determining which questions to ask and when to stop. We introduce a principled formulation of structured uncertainty that operates directly over tool parameters and their domains, cleanly separating specification uncertainty (what the user wants) from model uncertainty (what the LLM predicts). Our formulation uses Expected Value of Perfect Information (EVPI) to quantify the disambiguation value of each potential question, balanced against aspect-based cost modeling that prevents redundant questioning. We demonstrate the versatility of this formulation through two applications. First, SAGE-Agent uses structured uncertainty for inference-time question selection, achieving 7-39% higher coverage on ambiguous tasks while reducing clarification questions by 1.5-2.7x compared to strong prompting and uncertainty-based baselines. Second, we show that structured uncertainty provides effective training signals: uncertainty-guided reward modeling boosts When2Call accuracy from 36.5% to 65.2% (3B model) and 36.7% to 62.9% (7B model) through uncertainty-weighted GRPO training, demonstrating more sample-efficient reinforcement learning for tool-calling agents. To enable evaluation, we present ClarifyBench, the first multi-turn dynamic tool-calling disambiguation benchmark. Our results establish structured uncertainty as a principled framework that improves both inference-time interaction efficiency and training-time sample efficiency in tool-augmented agents.

The problem

A single ambiguous request such as “cancel my subscription” maps to several valid API calls with very different consequences: which service, pause or permanent, effective when. Agents trained on next-token prediction tend to hallucinate the missing arguments rather than ask. Existing clarification methods generate questions as free text through prompting, so they have no explicit model of which parameters are missing, how much each one matters, or whether a question has already been answered. The result is over-clarification of low-impact details, under-clarification of critical ones, and no way to tell a feasible request from an infeasible one.

There was also no benchmark for this setting. Prior tool-calling benchmarks either lack ambiguous and infeasible queries or evaluate statically, without a user who answers questions and then continues the conversation.

Approach

We move disambiguation out of token space and into the space of tool parameters and their domains.

  • Structured belief state. Each tool schema defines parameters, their domains, and which are required. Candidate tool calls may leave parameters unspecified (<UNK>). The agent keeps a belief distribution over candidates, factored over tool choice and per-parameter certainty. This separates specification uncertainty (what the user wants) from model uncertainty (what the LLM predicts).
  • Expected Value of Perfect Information (EVPI). For each candidate clarifying question we compute how much perfectly resolving its target aspects would raise the probability of the best candidate. User answers are treated as constraints on parameter domains, so belief updates are exact and EVPI is tractable.
  • Aspect-based redundancy cost. An aspect is one parameter of one tool. Each question targets a set of aspects, and the cost grows with how many times those aspects have already been queried, with a penalty strength lambda. The agent asks the question with the highest EVPI minus cost and stops when the best net gain falls below a threshold.
  • SAGE-Agent (Structured Argument Uncertainty guided Elicitation Agent) inserts this loop into the Reason stage of a standard Reason-Act-Observe agent. If a tool call fails at runtime, the agent generates a corrected invocation or an error-specific question and re-enters the scoring step.
  • Uncertainty-guided reward modeling. The same belief gives a training signal. In GRPO training on 9K When2Call examples, a certainty-weighted reward up-weights confident correct tool calls, penalizes low-certainty calls, and rewards clarification only when uncertainty is high. It needs no critic to judge question quality.
User request "call Alex from work" Candidate calls call(contact=<UNK>) belief over tool and per-parameter domains Uncertainty specification vs model uncertainty unresolved aspect Select question score = EVPI - lambda x cost cost grows if the aspect was asked Tool call if gain < threshold Ask best question: "Should I text her home phone?" Answer constrains domain: phone in {home}, belief updated repeat until the best net gain falls below a threshold tool schema: parameters, domains, required
SAGE-Agent: candidate tool calls with unknown parameters are scored for uncertainty over the tool schema; questions are ranked by EVPI minus a redundancy cost, and each answer narrows the parameter domains until the agent can call the tool with confidence.

ClarifyBench. We build a multi-turn benchmark with an LLM-based user simulator that holds the true intent, answers clarifying questions, and issues follow-up requests. Sources are DocPilot tool logs and BFCL-v3, augmented by obfuscating up to three arguments and prompting GPT-4o to generate queries that omit them, or by rule-based corruption for infeasible cases. Two annotators rate every generated query on naturalness, faithfulness, and (for infeasible cases) the presence of an error-inducing requirement.

  Doc Vehicle Stocks Travel Files All
Total samples 181 139 143 119 134 716
Number of tools 18 22 19 15 18 92
Avg. # of tool calls 3.9 4.5 3.9 3.7 3.1 3.8
Explicit queries 49 50 49 50 43 241
Ambiguous queries 49 39 46 40 39 213
Infeasible queries 48 49 38 18 45 198
Avg. # of follow-ups 2.9 2.1 2.7 2.3 1.8 2.4

Source: Table 2 of the paper. ClarifyBench statistics per domain (document processing, vehicle control, stock trading, travel, file system).

Example

The paper’s Figure 1 contrasts clarification in token space with clarification grounded in the tool’s parameter domains. The agent has a contacts list with Alex C. (work number), Alex M. (home number), and Maya S. (default: work number; also a home number).

Input

"Hey! can you call Alex from work for me?"

Token-space clarification

"Which Alex do you want to call?" Redundant question, since only one Alex has a work number.

Domain-space clarification (SAGE-Agent)

Call([Alex C. (Work)]) The answer is fully determined by the parameter domain, so the agent executes directly.

Input

"Please ask Maya on text if she can pick the party supplies on Saturday?"

Token-space clarification

SMS([Maya S.], "Can you pick the party supplies on Saturday?") Assumes the default phone number for Maya, which in this case turns out to be her work contact.

Domain-space clarification (SAGE-Agent)

"Should I text her on her home phone?" The phone-number parameter has two valid values, so the agent asks the one question that resolves it.
The two examples as drawn in the paper's Figure 1. Left: token-space clarification asks a redundant question or silently assumes a default. Right: grounding the decision in the tool's parameter domains executes directly when the answer is determined and asks only when it is not.

A ClarifyBench task (from the released benchmark, ambiguous split, vehicle-control domain). The user simulator holds the intention and reveals the missing value only when asked; it then issues the follow-up request.

User query

"Would you be able to convert some liters of gasoline into gallons volumn for me? Afterwards, starting the engine to check for smooth operation would be appreciated."

Hidden user intention (seen only by the simulator)

"If asked, user clarifies that this is 'I mean 20 liters of gas.' Thereafter, user requests to start the engine to check for smooth operation."

Ground-truth tool calls

[{"tool_name": "liter_to_gallon", "parameters": {"liter": "20.0"}},
 {"tool_name": "startEngine",     "parameters": {"ignitionMode": "START"}}]

Results

Metrics on ClarifyBench: Coverage (tool call fully matches ground truth), Tool Match Rate (TMR), Parameter Match Rate (PMR), and average number of questions (#Q). Baselines share a common ReAct scaffold: ReAct with an ask_question() tool, ProCOT, Active Task Disambiguation, and Domain-aware ReAct (schema in context).

Method (GPT-4o, ambiguous split) Coverage TMR PMR Avg. #Q
ReAct + ask_question() 42.88 70.41 62.55 2.68
ProCOT 54.27 75.62 66.82 2.07
Active Task Disambiguation 45.60 77.10 60.78 3.42
Domain-aware ReAct 55.70 79.83 68.04 2.56
SAGE-Agent, heuristic-based 56.42 82.31 69.81 1.82
SAGE-Agent 59.73 86.02 71.79 1.39

Source: Table 3 of the paper, GPT-4o rows for the ClarifyBench ambiguous split. Coverage, TMR, and PMR in %, higher is better; Avg. #Q is the mean number of clarifying questions per task, lower is better.

  • SAGE-Agent asks 1.39 questions per ambiguous task, versus 2.56 (Domain-aware ReAct), 2.68 (ReAct), and 3.42 (Active Task Disambiguation), and 1.08 on explicit tasks.
  • On infeasible tasks it reaches 67.33% Coverage and 92.89% TMR, ahead of all baselines; on explicit tasks 71.67% Coverage with 1.08 questions.
  • Active Task Disambiguation needs roughly 24K tokens and 40 LLM calls per task to compute entropy over question-by-solution matrices. SAGE-Agent uses about 22K tokens with 54% fewer calls, because it parametrizes uncertainty over the schema instead of sampling solutions.
  • With Qwen2.5-14B-Instruct the pattern holds: 54.56% Coverage on ambiguous tasks versus 52.45% (ProCOT) and 51.10% (Domain-aware ReAct), with questions reduced to 1.41 from 2.07.
  • Ablation: triggering questions on <UNK> tokens alone, without EVPI scoring, costs 1 to 3 points across metrics and adds 0.2 to 0.4 questions per task.
  • Raising the redundancy penalty lambda from 0 to 0.5 cuts questions by 18.1% (ambiguous), 26.6% (explicit), and 24.2% (infeasible) while Coverage, TMR, and PMR stay within 3%, confirming the pruned questions were redundant.

Single-turn When2Call (BFCLv2). Each example has one correct action: call the tool, ask a question, or decline.

Method (GPT-4o) ToolCall P ToolCall F1 AskQuestion F1 Decline F1
ReAct 0.71 0.75 0.64 0.69
Active Task Disambiguation 0.61 0.34 0.56 0.73
SAGE-Agent 0.80 0.65 0.65 0.78

Source: Table 4 of the paper, GPT-4o rows. Precision (P) and F1 per action class. Higher is better.

  • SAGE-Agent has the best balance across the three actions: ReAct over-calls tools (ToolCall recall 0.79 but Decline recall 0.58), and Active Task Disambiguation over-asks (ToolCall recall 0.24).
  • Reward modeling: uncertainty-weighted GRPO lifts When2Call accuracy from 36.5% to 65.2% (Qwen2.5-3B) and 36.7% to 62.9% (Qwen2.5-7B). The 3B model with our reward (65.2%) beats the 7B model with the standard reward (45.1%).

Resources

Quick start

From the repository README: run the baseline ReAct agent on the ambiguous split with any OpenAI-compatible endpoint, then score the results.

git clone https://github.com/MananSuri27/ClarifyBench.git
cd ClarifyBench
pip install -r requirements.txt

export OPENAI_API_KEY="sk-..."           # or VLLM_PORT=8000 for a local vLLM server
python main.py --agent baseline --data ClarifyBench/ClarifyBench_A/ --output results/
python evaluate.py --results_dir results/ --gt_dir ClarifyBench/ClarifyBench_A/

The benchmark ships as JSON tasks under ClarifyBench/ClarifyBench_E, ClarifyBench_A, and ClarifyBench_I (explicit, ambiguous, infeasible), each with user_query, potential_follow_ups, ground_truth_tool_calls, user_intention, and an initial_config for the domain plugin.