Ambiguity Resolution Stays a Human Job for a While

Give an agent an ambiguous request and it resolves the ambiguity. Not visibly — it picks a reading and proceeds, and the output reads like a confident answer to a clear question. The ambiguity didn't get resolved so much as absorbed.

This is one of the most consequential behaviors in practice, and it's structural rather than a capability gap.

Why it can't be resolved from inside

Ambiguity means the request admits more than one reading and the information distinguishing them isn't present. Which reading is correct depends on something outside the request: what the person meant, what the business needs, what happened before.

An agent has three options and no good one:

• Guess and proceed. Fast, and wrong some fraction of the time with no signal attached.
• Ask. Correct, and requires a channel and a person, which asynchronous runs often lack.
• Do nothing. Safe and useless.

Better models improve the quality of the guess — a stronger model picks the more likely reading more often. It doesn't convert a guess into knowledge, because the deciding information isn't in the context to be reasoned over.

Where it shows up

Scope ambiguity. "Clean up the notification service." Three things are meant, a fourth is explicitly out of scope, and that understanding exists only in the team's shared context.

Referent ambiguity. "Fix the timeout issue." Which timeout? An agent picks the most prominent one in the code, which may not be the one anybody noticed.

Precedence ambiguity. Two stated requirements conflict in an unanticipated case. Which wins is a decision nobody made because nobody expected the case.

Implicit-constraint ambiguity. The requirement never says the change must be backwards compatible, because everyone knows it must be.

⚠️ The last two are the dangerous ones, because the request doesn't look ambiguous. Nobody notices the ambiguity until the output makes a choice somebody disagrees with.

Making the guess visible

Since guessing is unavoidable, the design goal is to make it inspectable rather than silent:

interpreted:  "the timeout issue" = the 30s HTTP client timeout in checkout
alternatives: the DB statement timeout; the session idle timeout
chose_because: the checkout timeout is the only one mentioned in recent tickets
would_change_if: the reporter meant a background job

That block costs almost nothing and turns an invisible decision into a two-second check for whoever reads it. → An agent that guesses and says so is dramatically more useful than one that merely guesses well, because the first can be corrected and the second can only be trusted.

✅ The practices that help

Make asking cheap and available. In interactive settings, a clarifying question should be a normal, encouraged move. Many system prompts implicitly discourage it by emphasizing helpfulness, and the model reads that as a preference for confident answers.

Require the interpretation to be stated, always, not only when the agent notices ambiguity. Agents are unreliable at detecting ambiguity; they're reliable at reporting what they assumed. Ask for the second.

Front-load ambiguity discovery. Have the first stage produce the question list before any work happens, so one batch of clarification replaces a series of mid-work discoveries.

Include should-ask cases in your eval set. Requests where the correct behavior is a question, not an answer. Without them, nothing measures whether the agent can decline to guess — and unmeasured behavior drifts toward confident output.

Route ambiguous work to humans at triage. The cheapest intervention: a few seconds of judgment deciding whether a ticket is specified enough, before any agent touches it.

💡 The organizational finding

Teams that instrument this discover their ambiguity rate is higher than they thought, because humans were absorbing it invisibly. An engineer receiving a vague ticket asks a quick question or fills the gap from context, and neither leaves a trace.

Making the ambiguity visible is uncomfortable and useful. The recurring ambiguities — the same underspecified thing, over and over — are fixable at the source: a template field, a definition, a default that gets written down once.

That's the durable version of the fix. The agent's guessing gets better as your specifications get better, and specification quality is something you control.

The takeaway

Ambiguity resolution needs information outside the request, so an agent can only guess — and better models guess better without guessing less. Make the guess visible by requiring the interpretation and the alternatives to be stated, make asking a first-class move, front-load the question list, and test cases where the right answer is a question. Then read what keeps coming up ambiguous, because that list is a specification problem you can actually solve.