When Should an AI Agent Ask a Clarifying Question Before Using a Tool?

The agent receives "update John's record" and finds three possible matches. It picks one anyway and calls the tool. In another flow, it asks which file format you prefer before a reversible operation that already has an acceptable default.

The problem is not asking questions. It is deciding when guessing costs more than waiting. An agent should ask for clarification when missing information could change the target, authority, evidence, or effect of the next action. If a verified, reversible default remains useful, it can proceed and record the assumption.

This question belongs before the tool, not after an external effect has happened. It is also different from when an AI agent should ask for human approval: clarification supplies a missing fact; approval authorizes an action that is already understood.

Short answer

• Ask when missing information could select another record, recipient, resource, or effect.
• Proceed when a known, reversible default fits the goal.
• Do not confuse a clarifying question with approval, escalation, or a new task.
• Pause the tool with an explicit state and preserve the current step.
• Treat an answer, cancellation, timeout, and undelivered question as different outcomes.

Should the agent ask or use a safe default?

The practical rule is to compare the consequence of the assumption with the value of continuing. If a wrong guess could change a record, send something to the wrong person, consume a limited resource, or apply a different policy, ask before the tool call. If the choice is reversible and the application defined the default, continue with the assumption made visible.

The OpenAI GPT-5.1 prompting guide, checked on October 23, 2026, recommends pausing for one to three brief questions when missing information would change a concrete plan. The same guidance says to proceed with defaults when that is safe. The condition matters more than turning three questions into a fixed rule.

Use this matrix before deciding:

Do not use the model's textual confidence as the only signal. An agent can say it understood while still choosing between two targets. The policy should inspect the candidate action, missing fields, and possible effect. The model can help phrase the question; the runtime decides whether the tool may run.

Ambiguity is not the trigger. The trigger is ambiguity that changes a decision. An incomplete name may be fine for an exploratory read that returns candidates for review. The same incomplete name before a write requires a pause or a different policy.

Are clarification, approval, and escalation the same thing?

No. Clarification answers "which missing fact is needed?" Approval answers "do you authorize this specific action?" Escalation answers "which person or system should take over because the agent lacks authority or evidence?" Mixing these interactions produces confusing screens and states that are hard to test.

The OpenAI Agents SDK tools guide, checked on October 23, 2026, places execution, approval, timeout, output, and error handling at the tool boundary. That boundary is a sensible place to keep the policy, even when the agent proposes the question.

A safe sequence can be:

1. The model proposes the next action and possible arguments.
2. The runtime checks whether a missing field could change the effect.
3. If one is missing, the runtime creates a pending question and does not call the tool.
4. The person answers, cancels, or does not answer within the allowed time.
5. The runtime validates the answer against the task and the current state version.
6. Only then does the action return to approval policy or execution.

The Anthropic tool-use guide, checked on October 23, 2026, notes that a model may infer a missing parameter instead of asking. That is why the decision should not depend only on spontaneous model behavior. A required parameter in the schema helps, but the runtime still has to distinguish "I do not know the target" from "I know the target, but authorization is missing."

How do you put the decision at the tool boundary?

Start by describing the candidate action without executing it. The policy receives the missing field, consequence type, reversibility, and possible default. It returns a discriminated decision: ask, proceed, approve, or stop.

The following is an illustrative fixture. It does not use an agent SDK or call an external service. The point is to keep the decision deterministic and put the provider interface in a separate adapter.

type Consequence = "low" | "high";

type NextDecision =
  | { kind: "ask"; question: string; options?: string[] }
  | { kind: "proceed"; assumption: string | null }
  | { kind: "approve" }
  | { kind: "stop"; reason: string };

type DecisionInput = {
  missing?: string;
  consequence: Consequence;
  reversible: boolean;
  safeDefault?: string;
  needsApproval: boolean;
};

function decideNext(input: DecisionInput): NextDecision {
  if (input.missing && !(input.reversible && input.safeDefault)) {
    return {
      kind: "ask",
      question: input.missing,
      options: ["First option", "Second option"],
    };
  }
  if (input.needsApproval) return { kind: "approve" };
  if (input.consequence === "low" && input.reversible) {
    return { kind: "proceed", assumption: input.safeDefault ?? null };
  }
  return { kind: "stop", reason: "no safe decision is available" };
}

The criterion is intentionally simple. In a real application, missing may come from domain validation, an ambiguous lookup, or an authorization policy. The function should not decide that two accounts are the same just because the model selected the same string for both.

The ask result is an instruction to create a pause, not a final message. An adapter can show a question in a UI, send an event to a queue, or return an intermediate response. In every channel, the effectful tool stays blocked until a valid answer exists.

How do you represent a resumable pause?

The pause should store enough information to resume without starting over or applying an old answer. A state version prevents a question created before a change from being used as if it were current.

type ClarificationState = {
  taskId: string;
  stateVersion: number;
  currentStep: string;
  status: "waiting" | "answered" | "cancelled" | "timed_out" | "undelivered";
  question: string;
  options: string[];
  answer?: string;
};

function acceptAnswer(
  state: ClarificationState,
  answer: string,
  expectedVersion: number,
): ClarificationState {
  if (state.status !== "waiting") throw new Error("clarification is no longer pending");
  if (state.stateVersion !== expectedVersion) throw new Error("stale clarification");
  if (state.options.length > 0 && !state.options.includes(answer)) {
    throw new Error("answer is outside the allowed options");
  }
  return { ...state, status: "answered", answer };
}

The state should not contain only the question. currentStep says where the task was, taskId prevents crossing executions, and stateVersion rejects late answers. The executor can turn answered into arguments for the next step, but it should validate the domain again before the tool call.

The Microsoft process-navigation evaluation scenario, checked on October 23, 2026, tests whether an agent handles an interruption and resumes the correct step. A useful question cannot send the workflow back to the beginning or skip a dependency.

Cancellation, timeout, and delivery failure need their own states. A timeout is not a user answer. If the product wants to use a default after the deadline, that must be an explicit policy limited to the reversible case. It must not silently turn an absence into answered.

How do you ask a question that reduces uncertainty?

Ask about the decision, not the entire conversation. A good question points to a field that changes the next action, uses short options when the set is finite, and makes the next consequence clear. "What do you want to do?" sends planning back to the user. "Which of these two orders should I update?" narrows the choice that blocks the tool.

The Findings of ACL 2026 paper on structured-uncertainty clarification, checked on October 23, 2026, models the decision as a choice between executing the best candidate action and asking. It uses belief state, questions aimed at specific parameters, and a cost for redundant questions. This is research, not a threshold ready to copy, but it supports a useful separation between an uncertain field and a generic question.

Choose the question in this order:

1. List the candidate actions with different effects.
2. Identify the field whose value separates those actions.
3. Ask only for that field or for a choice that represents it.
4. Include a cancellation option when the task may be abandoned.
5. Re-evaluate the action and authority after the answer.

Limit consecutive questions. The right number depends on the flow, interface, and cost of each turn. Starting with one load-bearing question is better than making every task complete a full form. If context is still missing after the answer, create another explainable pause or hand off to a person.

How do you test the path where the agent should not ask?

Test the decision, state, and effect. An agent can ask the right question and still fail if the tool runs before the answer, a repeated answer executes twice, or unattended mode skips the pause.

An initial matrix should include:

• missing field with high consequence: create waiting and make zero tool calls;
• missing field with a reversible default: proceed and record the assumption;
• valid answer: resume the same taskId and currentStep;
• answer outside the options: remain pending;
• repeated answer: reject it after consuming the question;
• old state version: reject it;
• cancellation: produce zero effects and an observable reason;
• timeout: remain pending or end according to policy, without becoming an answer;
• undelivered question: do not release the tool;
• no user available: respect pause mode instead of pretending an answer arrived.

In a Hermes WebUI regression report, the interface needed a callback that could receive batched questions and return a structured envelope of answers and outcome. It shows why tests should cover the whole interaction contract, including cancellation and delivery, rather than only the question text.

The negative path matters as much as the question path. Give the agent a request that is sufficiently determined and confirm that no question appears. Then provide an ambiguity that changes the target and confirm that execution stays blocked. This comparison prevents a "always ask" rule from looking safe simply because it never lets the agent act.

The agent trajectory guide expands the matrix to tool order, arguments, and stopping. The TypeScript tool-call validation guide covers schemas and data boundaries. This post stays one step earlier: deciding whether the action should exist before validating or executing its arguments.

When is a question not the best response?

Do not ask when the answer would not change the next decision. If every option leads to the same safe read, the question only moves work to the person. Use a documented default, record it, and allow correction when the effect is reversible.

Do not use a preference question to solve a lack of authority. If the agent cannot access the record, a "yes" does not grant permission. Use approval policy or hand off to the responsible person. The guide to pausing and resuming an agent without restarting covers the pause boundary; this post focuses on deciding whether the missing thing is data, authorization, or a stop condition.

If the information is in a source the application can safely query, a read tool may be better than a question. The agent can find candidates, show the ambiguity, and then ask the person to choose. That reduces the user's burden without turning an approximate lookup into an automatic write.

Finally, do not turn the prompt into an execution contract. The instruction can tell the model to ask, but the runtime has to block the tool, validate the answer, and preserve state. Without that barrier, the agent can write a correct question and still execute the wrong action in the next turn.

Checklist for releasing clarification in an agent

• Does the policy say which consequence makes information load-bearing?
• Does the agent distinguish a safe default, clarification, approval, escalation, and stop?
• Does the question happen before the effectful tool?
• Does the state hold taskId, version, step, and status?
• Is an answer checked against the current task and allowed options?
• Do cancellation, timeout, and delivery failure remain different from an answer?
• Does resumption return to the right step without repeating effects?
• Is there a test where the agent should not ask?
• Does unattended mode have an explicit rule for pending questions?
• Does logging record the decision without retaining unnecessary data or secrets?

A reliable agent is not one that asks more often. It recognizes which gaps change the action and turns that decision into a state the code can block, test, and resume.

Quick questions

Should the agent ask whenever a parameter is missing?

No. If the parameter has a verified default and the operation is reversible, the agent can proceed while recording the assumption. Ask when the missing value could change the target, authorization, evidence, or effect. The tool schema helps find required fields, but it does not decide the consequence of each value by itself.

Does a clarifying question replace human approval?

No. Clarification completes the information needed to define the action. Approval authorizes an already defined action whose target and arguments the person can review. Keep the states separate so a preference answer cannot be interpreted as authorization for an external effect.

What happens if the person does not answer?

The task should stay pending or end with an explicit timeout, cancellation, or delivery-failure result. Silence is not an answer. A default after timeout is acceptable only when the application defined it and it remains safe, reversible, and observable for that flow.

How this article was produced

Samuel Fajreldines is responsible for this article. The research compared current documentation from OpenAI, the OpenAI Agents SDK, and Anthropic, a primary Findings of ACL 2026 paper, Microsoft's evaluation material, and recent public discussions. An equivalent JavaScript fixture ran locally with seven assertions covering the decision, pause, resume, repeated answer, cancellation, timeout, and old-version paths. The TypeScript code is illustrative and did not call a model, provider, or external service.

AI assistance supported source discovery, organization, drafting, localization, image generation, and consistency review. It did not provide a production test, benchmark, interview, or client incident. To keep context between sessions, the author uses RemoteCode, a tool he built; this is not evidence that the pattern improves performance.

Sources consulted

• OpenAI, "GPT-5.1 Prompting Guide", checked 2026-10-23
• OpenAI Agents SDK, "Tools", checked 2026-10-23
• Anthropic, "Tool use with Claude", checked 2026-10-23
• Wang et al., "Structured Uncertainty guided Clarification for LLM Agents", checked 2026-10-23
• Microsoft, "Process navigation and multistep guidance", checked 2026-10-23
• Hermes WebUI issue, "Batch questions for tool use", checked 2026-10-23