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.
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
Token-space clarification
Domain-space clarification (SAGE-Agent)
Call([Alex C. (Work)]) The answer is fully determined by the parameter domain, so the agent executes directly.Input
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)
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
Hidden user intention (seen only by the simulator)
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
- arXiv: 2511.08798
- ACL Anthology (Findings of ACL 2026)
- Code, evaluation harness, and ClarifyBench benchmark on GitHub
- Hugging Face Papers
- Adobe Research publication page
- Explainer post: SAGE-Agent and ClarifyBench
- Related on this site: CodeScout, which resolves underspecified requests for software agents by pre-exploring the repository
- All publications
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.
