Should Autonomous Systems Ask Clarifying Questions?

When a directive is underspecified, the system has three options: ask the operator to clarify, make assumptions and proceed, or make assumptions explicit and proceed.

Most systems default to one of the first two. The third is better.

Why Asking Questions Defeats the Point

The appeal of asking clarifying questions is obvious: the operator knows what they want, asking surfaces that knowledge, the build is more likely to be right the first time.

The problem is that autonomous operation is valuable precisely because it doesn't require constant operator attention. An operator who has to answer a questionnaire before the system starts to build isn't getting autonomous delivery — they're getting a structured interview followed by assisted execution.

There's also an epistemic problem. The questions the system asks are about things the system knows it doesn't know. The gaps that actually matter most — the ones that cause misfit at delivery — are usually things the operator doesn't know they need to specify. Asking questions doesn't surface those. Only seeing the build surfaces those.

A long pre-build Q&A creates the illusion of a well-specified directive without solving the underlying problem.

Why Silent Assumptions Are Worse

The other common failure mode: the system makes dozens of undisclosed decisions and delivers a product. The operator reviews it, notices things that seem off, but can't tell which things are choices the system made (and that could be changed) versus constraints of the approach.

"Why does the POS screen have a separate button for refunds and returns? That seems like it could be one thing."

If the system decided that and can explain why, the operator can evaluate the reasoning. If the system decided that and never said so, the operator doesn't know whether this is load-bearing or arbitrary.

Silent assumptions mean the operator has to reverse-engineer the system's reasoning from the output. That's slow, imprecise, and error-prone. It also means good decisions don't get credited and bad decisions don't get corrected.

The Right Approach: Named Assumptions

The system should proceed on its best judgment and surface the decisions that were genuinely non-obvious.

Not all decisions — that would be noise. The decisions worth surfacing are the ones where: - The directive was ambiguous and the system chose between two plausible interpretations - The system made an architectural choice with real downstream consequences - The system's default may not match the operator's context

"I interpreted 'compliance reports' as covering monthly excise duty returns and annual licence renewal. If only the monthly returns are needed, the compliance section can be simplified."

"The POS screen separates refunds from returns because they have different tax implications under Irish excise duty rules. If this distinction doesn't apply to your operation, they can be merged."

These flags do what pre-build questions can't: they're grounded in the actual artifact. The operator can see what decision was made, see its consequences in context, and decide whether to accept or redirect.

What This Looks Like in Practice

The system builds. The build includes a decision log or review notes — not a full accounting of every implementation choice, but a short list of the high-stakes non-obvious decisions.

The operator reviews the build. The decision log tells them where to look. Some decisions are fine and get confirmed. Some get redirected. The redirections become the second directive.

This approach respects the operator's time during intake (no questionnaire), surfaces the actually important information at review (when the operator can see the consequences), and produces better second directives.

The Underlying Principle

Pre-build questions treat the operator as the source of the right answer. Named assumptions treat the build as the source — the artifact reveals what the questions should have been.

Both serve the same goal: a build that fits. But one requires the operator to imagine the product before it exists, and one shows them the product and asks whether the choices hold.

The second approach is usually better. Not because operators can't answer questions, but because software is hard to specify in the abstract and easy to evaluate when concrete.

Part of an ongoing series on directive quality. Previous: what makes directives work, what operators leave out, the directive feedback loop.