Prompt to Make an Agent Ask Before Acting
A developer deployed a document processing agent and asked it to "update the client files with the new template." The agent, parsing "update" as an action and "client files" as a scope, immediately overwrote 340 documents with the new template. The developer had meant to apply the template only to documents created in the last month. The agent had no way to know this. It also had no instruction to ask.
This is the standard failure mode for agents that optimize for task completion without a clarification step. The agent was doing exactly what it was designed to do: complete the task efficiently. The problem was that the task was underspecified, and efficiency in the presence of ambiguity means acting on the first reasonable interpretation rather than the correct one.
The prompt pattern in this article gives agents a systematic way to identify ambiguity before acting, surface specific questions, and hold until confirmed. It includes threshold conditions so the agent does not become paralyzed by over-asking.
What Makes an Instruction Ambiguous
Not every instruction needs clarification. An agent that asks for confirmation on every step is unusable. The goal is to identify the specific conditions under which clarification is necessary and act freely otherwise.
An instruction requires clarification when it meets any of these conditions:
| Condition | Example | Why It Requires Clarification |
|---|---|---|
| Multiple reasonable interpretations lead to different actions | "Delete the old versions" — which files count as old? | Wrong interpretation causes incorrect deletions |
| Scope is undefined for a broad action | "Email the team" — which team, all members? | Wrong scope contacts unintended people |
| Action is irreversible and parameters are unclear | "Send the invoice" — which invoice, to whom? | Irreversible action on wrong target |
| Instruction conflicts with a previous instruction | Earlier: "Always ask before sending." Now: "Send all reports." | Following later instruction violates established rule |
| Completion requires information the agent does not have | "Schedule the meeting" — when, with whom, for how long? | Agent cannot complete without guessing key parameters |
For actions that are reversible and clearly scoped, the agent should proceed. The threshold is ambiguity that materially affects the action, not every possible nuance.
The Prompt
## CLARIFICATION PROTOCOL
Before taking any action, apply this evaluation in sequence:
STEP 1 — INTERPRET
State your interpretation of the instruction in one sentence: "My interpretation is: [action] applied to [scope] with [parameters]."
STEP 2 — CHECK FOR MATERIAL AMBIGUITY
Ask yourself: Are there two or more reasonable interpretations of this instruction that would lead to meaningfully different actions?
If NO: Proceed with your stated interpretation. No clarification needed.
If YES: Do not proceed. Go to Step 3.
STEP 3 — CHECK STAKES
Is this action irreversible, or does it affect resources outside the clearly defined scope of the current task?
If YES to either: Do not proceed. Go to Step 4.
If NO to both: Choose the most conservative interpretation, state it explicitly, and proceed.
STEP 4 — ASK ONCE
Ask all clarifying questions in a single message. Format:
"Before proceeding, I need to clarify [number] thing(s):
1. [Specific question about first ambiguity]
2. [Specific question about second ambiguity]
I will proceed after you answer these. I will not make further clarifying requests for this task unless a new ambiguity arises that was not resolvable from your answers."
STEP 5 — CONFIRM INTERPRETATION AFTER ANSWERS
After receiving answers, state your updated interpretation and what action you are about to take before taking it. Wait for a brief acknowledgment only if the action is irreversible. For reversible actions, state the interpretation and proceed without requiring acknowledgment.
APPLY THIS PROTOCOL TO: Any action that modifies data, sends communications, executes code, makes purchases, or affects external systems.
DO NOT APPLY TO: Reading, summarizing, analyzing, or reporting actions with no side effects.Breaking Down the Protocol
Step 1: Explicit interpretation
Making the agent state its interpretation before acting does two things. First, it forces the model to commit to a specific reading rather than acting on a vague understanding. Second, it makes the interpretation visible, which means users can catch misinterpretations before they become actions.
Without this step, agents act on implicit interpretations that are never surfaced. The developer in the opening example never saw that the agent had interpreted "client files" as all files. If the agent had stated its interpretation first, the error would have been caught.
Step 2 and 3: The two-part threshold
The clarification protocol uses two separate conditions deliberately. Step 2 asks whether there is genuine ambiguity. Step 3 asks whether the stakes are high enough to require asking regardless.
An agent that only asks when it is uncertain will sometimes be confidently wrong. An agent that also asks when the stakes are high is protected against confident errors on irreversible actions.
The two-part structure prevents a failure mode where the agent is confident but wrong about an irreversible action. If the action is irreversible, the threshold for clarification is lower.
Step 4: Ask once, ask everything
The "ask once" rule is essential for usability. An agent that asks one question, waits for an answer, asks another question, waits again, and repeats this cycle creates a frustrating interaction that users quickly abandon. Batching all questions in a single turn is both more efficient and signals that the agent has thought through the full task, not just the first ambiguity it encountered.
The commitment to not make further clarifying requests is also important. Once the user has answered the questions, the agent should proceed. If new ambiguity arises from the answers, the agent can ask again, but the bar is higher: only a genuinely new issue, not further exploration of the same question.
Step 5: State and proceed versus state and wait
The final step distinguishes between irreversible and reversible actions. For reversible actions, stating the interpretation is sufficient — the user can interrupt if something is wrong. For irreversible actions, a brief pause for acknowledgment is appropriate. This prevents the protocol from adding friction to every single step while still protecting the most critical moments.
Variations for Different Deployment Contexts
| Context | Modification |
|---|---|
| Fully automated pipeline (no human available) | Replace Step 4 with: "If clarification is required and no human is available, abort and log the ambiguity. Do not proceed with a guess." |
| High-frequency low-stakes actions | Add: "For actions you perform more than 3 times per session of the same type, you may skip Step 1 after the first instance." |
| Agent with tool approval workflow | Replace Step 5 with: "Output the proposed action in the tool_call format and await approval before execution." |
| Multi-agent system | Add: "Ambiguity in instructions from other agents is treated the same as ambiguity from human users. Route clarification requests back to the orchestrator, not to the originating agent." |
| Customer-facing agent | Simplify language: "Before I do that, I want to make sure I understand correctly. Are you asking me to [interpretation]?" |
What This Looks Like in Practice
Without the protocol:
User: Archive the old projects.
Agent: Done. I have moved 47 project folders to /archive.
[User had meant only 3 specific folders from Q1 2023]With the protocol:
User: Archive the old projects.
Agent: My interpretation is: move all project folders to /archive.
Before proceeding, I need to clarify 2 things:
1. Which projects count as "old"? (by date, status, or some other criteria?)
2. Should I archive to /archive, or is there a specific archive location you prefer?
I will proceed after you answer these.The agent's clarification is more valuable than a completed but incorrect action. A five-second pause is cheaper than recovering from the wrong archive operation on 47 folders.
Handling Edge Cases
There are two edge cases worth addressing explicitly in your prompt if they apply to your use case.
The "figure it out" response: Sometimes users respond to clarifying questions with "just use your best judgment" or "do whatever makes sense." This is a signal that the user wants action but is not available to specify. The correct behavior here is to choose the most conservative reasonable interpretation, state it, and proceed. The protocol should include: "If the user asks you to use your own judgment on an ambiguous parameter, choose the most conservative interpretation, state it explicitly, and proceed."
Time pressure: Some tasks have genuine time pressure where the cost of asking exceeds the cost of being wrong. Add: "If the task has an explicit time constraint that makes clarification impractical, choose the most conservative interpretation, state that you are doing so, and proceed. Log the ambiguity for later review."
Common Mistakes When Implementing This Pattern
The first mistake is applying the clarification protocol to read-only actions. Asking for confirmation before reading a file or generating a summary adds friction with no benefit. The protocol explicitly excludes read-only actions — make sure your implementation does too.
The second mistake is writing clarifying questions that are too broad. "What do you mean by old?" is less useful than "Should I consider files older than 90 days as old, or do you have a specific date in mind?" Good clarifying questions narrow the ambiguity to a specific, answerable choice.
The third mistake is not combining this protocol with the constraint pattern from Prompt to Define What an Agent Must Never Do. The clarification protocol handles ambiguity. The constraint pattern handles prohibition. You need both. An agent that asks before acting but has no hard limits on what it can do is still dangerous.
For managing context loss over long agent runs, see Prompt to Make an Agent Summarize Its Own Progress. For preventing the related failure mode of agents that loop indefinitely, see Prompt to Stop an Agent From Looping.
Frequently Asked Questions
How do I prevent my agent from asking too many unnecessary clarifying questions?
The prompt includes a threshold condition: ask only when the ambiguity materially affects which action is taken or whether an irreversible action occurs. For low-stakes, reversible actions, the agent should make a reasonable interpretation and proceed. This prevents the agent from becoming an endless questioner.
Can this pattern work with streaming agents that need to act continuously?
Yes, but you need to define confirmation modes. For streaming or long-running agents, use a checkpoint pattern: the agent acts freely on reversible steps and pauses at defined checkpoints before irreversible ones. The prompt includes a variation for this.
What counts as an ambiguous instruction?
An instruction is ambiguous when two or more reasonable interpretations would lead to different actions. “Send the report” is ambiguous if there are multiple reports and multiple potential recipients. “Analyze the data” is ambiguous if the scope of analysis is unclear and different scopes produce significantly different outputs.
How does this interact with tool-use frameworks like LangChain or AutoGPT?
In most tool-use frameworks, the agent has a plan-act-observe loop. This prompt modifies the plan phase: before acting, the agent checks whether the planned action requires clarification. The check happens before the tool call, not after.
Should the agent ask all clarifying questions at once or one at a time?
At once, if possible. The prompt includes an instruction to batch all clarifying questions in a single turn. Asking one question at a time in a back-and-forth creates friction. If there are three ambiguities, the agent should surface all three in one message.