I defined when AI
should ask instead of answer

Research led the official evaluation framework and tooling. My contribution was the behavioral criteria, decision model, prompt guidance, and designer-facing interpretation of what “good” meant for clarification.

A conversational system has to decide which meaning the user intended. If it chooses incorrectly, the response can be factually correct and still fail.

That was happening at ServiceNow. The system was over-indexing on accuracy and coverage: find relevant information, avoid hallucination, and answer as completely as possible. In ambiguous moments, that produced two failure modes.

Two failure modes

A behavior model optimized for “accurate and complete” was still failing the user. Accurate and complete is not the same as understood.

A response can be accurate and still be wrong for the user’s intent. A response can be comprehensive while making the user do the work the AI should have done.

That meant “detect ambiguity” was not a useful strategy. At that density, ambiguity was not an exception. It was the normal condition of enterprise conversation.

Why this mattered

The wrong-intent problem was annoying. The region assumption was riskier: nothing in the response marked it as an assumption. The assistant stated the assumed policy scope with the same confidence as the retrieved policy content.

The broader pattern was just as important: the AI was being rewarded for producing accurate, complete answers, even when the more useful behavior would have been to pause, narrow, or ask.

That distinction shaped the rest of the work: some AI failures come from saying something false. Others come from doing the wrong thing with true information. Clarification is most valuable at that boundary.

I looked at failure patterns where the response was not obviously “bad” by traditional standards. The system often retrieved the right source, used plausible wording, and produced a complete answer.

The issue was what the response made the user do next.

The pattern became clear: answer correctness is not the same as intent correctness.

So the evaluation and behavior strategy needed to measure whether intent was resolved, not just whether the answer was right.

The research showed that ambiguous requests were not limited to obviously vague prompts.

Longer requests were not safer. They gave the AI enough to start and not enough to finish. People were not writing perfectly specified prompts. They were using shorthand, incomplete references, everyday terminology, prior context, and assumptions about what the assistant already knew.

Query-coding pass · three buckets

The “clear” pile keeps shrinking as we read more carefully.

A usability study also showed that long, catch-all answers were making tasks harder to complete. One participant said they would have wanted the assistant to ask a question back rather than guess.

The important signal was not that users wanted more questions. It was that they preferred a focused question when it got them to the right answer faster.

The goal was not minimum turns. It was the shortest path to the right outcome.

One extra turn can remove the work of reading the wrong answer. I did not want a system that asked every time something was ambiguous.

The risk: false friction

Asking by default would solve answer burden by creating a different failure mode. Clarification only works when it reduces the total work for the user. A bad clarification question can be just as harmful as a bad answer: it can ask for information the system already has, expose internal ontology, or force the user to understand how the system is organized.

This is the arithmetic behind a claim that sounds counterintuitive: adding a turn can shorten the journey when the alternative is scanning, repair, reformulation, or abandonment.

That meant the assistant needed to decide:

This is why clarification became a behavior policy, not a copy pattern.

The early version asked whenever there was more than one possible interpretation. It was directionally right, but blunt. The assistant often asked in the system’s language rather than the user’s.

Nobody set out to run this test. The behavior disappeared in a routine platform update, and existing metrics did not treat it as a regression: answer rates, latency, and resolution did not clearly explain what changed.

Users noticed the absence of clarification faster than they had noticed its presence. That is what made the customer escalations meaningful: they surfaced a value existing quality signals were not set up to measure.

The question technically clarified, but it clarified in the system’s language. The user still had to understand ServiceNow’s internal categories before they could choose.

The rebuild created the opportunity to define the behavior more intentionally.

I found that two variables mattered most:

Confidence: how strongly the system could identify the user’s likely intent.

Consequence: what would happen if the system guessed wrong.

The important move was keeping those variables separate.

Confidence was the obvious signal. It was also the wrong one.

A single certainty score is easier to route on, easier to test, and cheaper to implement. But it collapses two different questions into one:

• How likely is the leading interpretation?
• What happens if that interpretation is wrong?

I pushed to keep consequence separate because two requests can have similar confidence and very different risk.

Same confidence, different risk: each can appear interpretable, but the consequence of being wrong changes the right behavior.

Retrieving a policy is cheap to get wrong. Writing a record, triggering a workflow, approving something, changing access, or resetting an account is not.

Consequence is a property of the action, not the model’s feeling of certainty. It belongs in the behavior system.

A confidence-only model treated ambiguity as a single score. It could tell the system how likely the top interpretation was, but not how expensive it would be to choose incorrectly.

The point was not to make the assistant cautious everywhere. It was to make caution proportional to risk.

A clarifying question can look simple in the UI, but the sentence is the visible output of a larger behavior system.

Every layer could independently produce the wrong sentence. None of those layers were visible to the user.

That is why the design work could not stop at the wording. The wording had to carry the behavior model.

The taxonomy did not start clean.

I built it by grouping, splitting, renaming, and testing ambiguous requests until the categories described what the system needed to decide, not just how vague the sentence sounded.

Taxonomy in progress · clustering pass 3 of 6

A generic approach treated all ambiguity the same. A categorized approach let the system match the response to the specific problem.

The categories evolved as I tested more examples. Some merged, some split, and some cases that looked similar at first required different behaviors.

That became the important design move:

The taxonomy made “ambiguous” specific enough for prompt engineers to route, content designers to write, and evaluators to score.

Each type required a different response strategy.

This is the difference between asking a question and designing a useful clarification.

Scenario

User: Add me to the project.

Context available to the system:

• The user is on three active projects: Atlas, Northstar, and Meridian.
• Northstar has an open access request.
• The system can use project context, but should not assume the user wants the open request unless it makes that assumption visible.

The final question was not just nicer copy. It encoded the behavior model.

I also created examples and counterexamples so teams could recognize what not to ship.

The standard became:

The guidance went beyond “sound natural.”

I defined rules that prompt engineers and content teams could apply:

Clarification anatomy: what the AI understood, plus the unresolved distinction, plus user-recognizable options, plus a way out if none fit.

The design goal was not a nicer question. It was a better decision.

The assistant should not make the user restate the whole request. It should carry forward what it knows and ask only for the missing variable.

The rubric asked whether the system:

Every logged interaction could be evaluated through two questions:

1. Did the system actually have enough information to act?
2. What did it do?

This made evaluation more useful for AI behavior design. It judged the decision, not only the output.

A separate, smaller head-to-head evaluation gave texture to the rollout.

Two candidate implementations were run against the same scenario set. The implementation built to the disambiguation standard asked a needed clarifying question in its first turn on 55% of scenarios that required one, compared with 20% for the comparison implementation.

This was not optimized as a target. It was useful because it showed that the behavior standard changed what the system recognized as answerable.

The 175% increase is indexed to the prior implementation because the absolute trigger rates are confidential.

What makes the number worth trusting is not its size. The increase was what the new decision boundary produced, not a target the team optimized for.

The shipped strategy was an intermediate step, not the full behavioral framework. It used the technical mechanisms available in the platform to trigger clarification more effectively and reduce automated guessing.

The full next-generation framework weighed context, interpretation strength, ambiguity type, consequence, and response strategy together. Fifteen teams requested early access before it launched.

Internal business modeling projected deflection improving from roughly 8% to 36% as conversational pattern coverage expanded from 40% to 83% of intents.

That is a projected 4.5× lift.

Business model projection, not claimed outcome.

This is business context, not an outcome I claim credit for. It explains why better AI behavior mattered at scale.

The deeper impact was organizational.

Instead of design coming in at the end to make clarification sound better, design had a role in deciding what the system should detect, what it should infer, what it should ask, how it should respond, and how teams should know whether that behavior was right.

I made the strategy stick three ways.

Internal partner feedback captured the impact:

That mattered because the work did not end with a recommendation. It became something teams could ship, evaluate, and reuse.