The Cost of a Wrong Assumption Decides Whether an Agent Should Ask
Almost every instruction an agent receives is under-specified in some way. A human hands off a goal that seemed complete when they wrote it, and the agent discovers, partway in, that the words admit more than one reasonable reading. The output format was never stated. The scope has a soft edge. A pronoun points at two possible things. This is not a failure of the person who wrote the instruction, and it is not something that better prompting fully eliminates. Natural language carries assumptions that only surface when someone tries to act on them literally, and an agent acts on them more literally than any human collaborator would.
So the interesting question is not how to prevent ambiguity. It is what an agent should do the moment it notices one. There are exactly two moves available. It can stop and ask the human to resolve the ambiguity before proceeding, or it can commit to the interpretation it judges most likely and keep working. Neither move is correct in general. Which one is right is decided entirely by what it would cost to guess wrong, and an agent that reaches for the same move regardless of what the ambiguity would cost misfires predictably, erring toward paralysis on the cheap questions and toward recklessness on the expensive ones. The design work is in making that cost calculation part of the system rather than leaving it to whatever the model happens to land on.
The two responses to an under-specified goal
When a goal leaves multiple valid interpretations open, the agent has to pick one to make progress, and the choice of how to pick is itself a design decision. Clarifying first means pausing execution and surfacing the ambiguity to a human before committing to any interpretation. It buys correctness at the price of latency and of a human’s attention, both of which are real and neither of which is free. Proceeding on an assumption means committing to the reading it judges most likely and pressing on without a round-trip to the human. It buys velocity and autonomy at the price of the risk that the chosen interpretation is the wrong one.
These are not two schools of thought to pick between once and standardize on. They are two tools, and the skill being designed is the judgment that selects between them per situation. An agent that always clarifies becomes an agent nobody wants to use: slow, needy, and unable to take a step without confirmation, which defeats the entire purpose of delegating to it. An agent that always proceeds becomes an agent nobody can trust: confident, fast, and occasionally catastrophic, because it will guess on exactly the questions where guessing is unacceptable. The failure of the always-clarify agent is visible and merely annoying. The failure of the always-proceed agent is invisible until the wrong assumption has already produced its consequence. That asymmetry matters, and it is why the default posture has to be set deliberately rather than inherited from whichever behavior was easier to build.
Reversibility, stakes, and scope decide which one is right
If the choice between clarifying and proceeding is a cost calculation, then the design task is to name the variables that go into it. Three of them carry nearly all the weight, and they are worth separating because each measures a different kind of exposure.
Reversibility usually dominates the other two. If a wrong guess can be undone easily and cheaply, the downside of proceeding is bounded by the cost of the undo, and that cost is often small enough that pausing to ask would waste more than a wrong guess ever could. A draft can be rewritten. A file can be regenerated. A recoverable action carries its own insurance, and an agent that clarifies before every recoverable action is spending a certain cost, the human’s time, to avoid an uncertain and cheap one. The calculation inverts the moment the action cannot be taken back. Deleting data, sending an external communication, moving money, committing a transaction that downstream systems will act on: these are actions whose consequences persist regardless of whether the assumption behind them was sound. When the undo button does not exist, the latency of a clarification request is almost always worth paying, because the alternative is a mistake with no remedy.
Stake level scales the whole calculation. A wrong assumption on a low-impact task produces a small error; a wrong assumption on a high-impact one produces a large error even when it is technically reversible. An operation that triggers an expensive computation, consumes a scarce resource, or sets off a long batch process justifies a brief pause to confirm the scope in a way that a routine, cheap operation never would. The question is not whether the action can be undone but how much the wrong version costs before anyone gets the chance to undo it.
Scope clarity is the criterion most often overlooked, because its damage is delayed. When the boundaries of the task are themselves ambiguous, a wrong assumption does not produce a single wrong action. It produces a wrong premise that every subsequent step inherits. An agent that has guessed wrong about which system it is operating on, or which dataset it is transforming, or how wide the task actually reaches, will proceed to do a long sequence of internally correct work on the wrong target, and the error will not surface until something much later trips over it. Ambiguity about scope has a multiplier that ambiguity about a single step does not, because it corrupts the foundation the rest of the plan stands on. Clear scope collapses that multiplier; genuinely uncertain scope is one of the strongest reasons to stop and ask before a single step runs.
Read together, these three tell an agent when the ambiguity in front of it is cheap and when it is expensive. A reversible, low-stakes step inside a clearly bounded task is one an agent should resolve on its own and keep moving; hesitating there is the failure. An irreversible, high-stakes step, or any step where the scope itself is in question, is one where proceeding on a guess is the failure, and the brief latency of asking is the correct price.
A single fixed policy fails in both directions
The temptation in building this is to reach for a global setting: make the agent cautious, or make it decisive, and be done. Both versions are wrong, and they are wrong in a way that is worth stating precisely, because the instinct to standardize is strong and it produces systems that misbehave predictably.
A globally cautious agent treats every ambiguity as a reason to stop. It is safe in the narrow sense that it rarely acts on a bad assumption, but it is useless in the practical sense that it cannot carry a task through without a human walking beside it. The whole value of delegation is that the human hands off and steps away; an agent that interrupts on every soft edge has not been delegated to, it has been supervised, and supervision at that granularity is more expensive than doing the work directly. There is also a subtler cost. An agent that asks too often trains its users to stop reading the questions and to approve reflexively, which quietly destroys the value of the occasional question that genuinely needed a careful answer.
A globally decisive agent has the opposite pathology. It maintains velocity beautifully right up until the moment it guesses wrong on something irreversible, and then it produces the kind of failure that erases whatever time its decisiveness saved. Worse, because it never pauses, there is no natural checkpoint at which a human could have caught the bad assumption before it committed. The speed is real and the danger is real, and they are the same property viewed from two sides.
Neither policy is defensible because the correct behavior is not a property of the agent. It is a property of the situation, and it changes from one step to the next within a single task. The same agent, on the same run, should proceed without asking when it hits a reversible formatting question and stop to confirm when it reaches an irreversible external action a few steps later. Designing for that means the clarify-or-proceed decision cannot live as a constant. It has to be evaluated against the actual reversibility, stakes, and scope of the specific action the agent is about to take.
When one pass isn’t enough, refinement closes the gap
Some ambiguity is not about which interpretation to pick. It is about quality that cannot be fully specified in advance. A goal like producing a strong summary, a clear analysis, or a well-argued piece of writing is under-specified not because the intent is unclear but because “good enough” is a judgment that is easier to make about a finished draft than to define beforehand. Asking a human to resolve that upfront does not work, because they cannot articulate the standard until they see a candidate to react to. Proceeding on a single pass does not work either, because the first attempt rarely clears a bar that was never written down.
The pattern that fits this shape is an iterative refinement loop, and it works by splitting the labor between producing and judging. A generator produces a candidate. An evaluator, which may be a separate model instance or a structured critique against an explicit rubric, assesses that candidate and returns specific feedback about where it falls short rather than a bare pass or fail. That feedback returns to the generator, which revises, and the cycle repeats. The quality of the loop depends heavily on the richness of the evaluation. A verdict of “not good enough” gives the generator nothing to act on; a critique that names the three places the argument is thin gives it a map. The more specific the evaluator’s feedback, the faster the output converges, and the difference between a useful loop and a wasteful one is largely the difference between structured critique and a numeric score.
So the loop has to carry a ceiling on how many times it will cycle, and that ceiling is the reason the pattern can run unattended at all. Quality is a moving target, and an evaluator can be impossible to fully satisfy, so a loop chasing an unreachable bar will grind on forever, spending resources on marginal edits that never clear it while looking every bit as busy as one that is making real progress. The ceiling converts that open-ended grind into a bounded one. When it is reached, the correct behavior is to stop and hand off the best candidate so far along with a note that it did not fully converge, not to keep spinning. The refinement loop earns its place precisely because it is bounded: it improves quality where a single pass cannot, and it cannot become an infinite regress.
Assumptions have to be written down where a human can find them
Whenever an agent proceeds on an assumption instead of asking, it makes a decision that a human did not get to see. Left implicit, that decision is invisible, and an invisible assumption is one nobody can audit until it has already caused a problem. The discipline that fixes this is cheap and disproportionately valuable: when the agent resolves an ambiguity by inference, it records the interpretation it chose, in the output or in an execution log, as part of the result itself.
The payoff is in the review. A human checking the agent’s work does not have to reconstruct what it must have assumed by reverse-engineering the output. They can read the assumption directly, judge whether it was reasonable, and catch a bad one before it compounds into everything built on top of it. This turns review from a full re-derivation into a spot check, which is the difference between oversight that scales and oversight that does not. Documented assumptions also compound over time. A pattern of the agent repeatedly assuming the same thing is a signal that the underlying specification has a gap, and that signal is only legible if the assumptions were written down to begin with. An agent that decides silently forces its reviewers to trust it completely or verify it completely, and neither of those is a workable long-term posture.
The durable fix is a better specification, and the loop is the fallback
Every technique here is a way of handling ambiguity gracefully, and none of them is as good as not having the ambiguity in the first place. The clarify-or-proceed judgment, the refinement loop, the documented assumption: these are all responses to under-specified goals, and they all cost something. The larger design investment is upstream, in the specification itself. Precise, well-scoped instructions reduce the number of interpretations an agent has to choose between, which means fewer clarification interrupts, fewer assumptions to document, and fewer wrong guesses to recover from. That investment pays off across every task that ever touches the specification, which is why it is worth making even though it is slower and less immediately gratifying than tuning the agent’s behavior.
But specifications are written by humans, and humans cannot anticipate every interpretation an agent will find, so ambiguity is reduced by good specification and never eliminated by it. The runtime behavior remains the safety net, and its quality is the entire question. An agent that handles ambiguity well is not one that has been made maximally cautious or maximally decisive. It is one that measures each ambiguity against the actual cost of guessing wrong, asks when that cost is high and proceeds when it is low, bounds the loops it uses to close quality gaps, and leaves a written record of every call it made without being told. The stakes, the reversibility, and the scope decide the move. The agent’s job is to read them correctly, one situation at a time, and to make the decision it reached inspectable by the human who has to stand behind the result.
