The Information-Value Test: How AI Chooses the One Question Worth Asking

An AI agent can recognize uncertainty and still ask the wrong question. It may request information that is easy to provide but irrelevant to the decision, or pursue certainty that costs more time than it saves. The operational standard is not whether a question improves understanding. Almost any question can do that. The standard is whether the answer is likely to change what the agent should do.

The information-value test gives agents a disciplined way to select one question from many possible questions. It compares the expected decision impact of an answer with the effort, delay, and disruption required to obtain it. The result is a sharper choice among asking, investigating, assuming, and acting.

The Core Idea: Questions Are Operational Investments

Every clarification consumes resources. A person must interpret it, find the answer, and respond. Work may pause while the agent waits. Poorly timed questions also transfer the burden of reasoning back to the operator.

A valuable question changes one of four things:

• The action: the answer leads to a different next step.
• The sequence: the work remains the same, but its order changes.
• The safeguards: the action proceeds with different review, limits, or approvals.
• The commitment: the answer changes what the organization promises, spends, publishes, or records.

If every plausible answer produces the same decision, the question has little operational value. The agent should usually proceed, record a bounded assumption, or retrieve the information without interrupting anyone.

A question is worth asking when different credible answers produce materially different plans.

The Four Factors Behind Information Value

A practical test does not require precise probabilities. It requires consistent comparison. Rank each candidate question using four factors.

A question has strong information value when impact, uncertainty, and answerability are high while interruption cost is low. A high-impact uncertainty may still be a poor immediate question if the recipient cannot know the answer. In that case, the agent should seek evidence, run a reversible test, or escalate to the actual owner.

A Simple Decision Procedure

The agent can apply the test in five steps.

1. Name the pending decision. State the action that cannot yet be chosen confidently. “Understand the project” is not a decision. “Choose whether to notify customers before deployment” is.
2. List credible answer branches. For each unknown, identify realistic answers rather than every theoretical possibility.
3. Map each branch to an action. If two answers produce the same action, merge them. If all answers converge, do not ask.
4. Check cheaper evidence. Look for an authoritative record, system state, prior approval, policy, or directly observable fact.
5. Ask the smallest branching question. Phrase the question so one response selects the correct path.

This procedure prevents “context collection” from becoming an open-ended interview. The agent gathers only the information needed to distinguish among viable actions.

Worked Example: Handling a Delayed Customer Launch

Suppose an operator says: “The integration launch may slip. Handle the customer communication.”

The agent identifies a pending decision: whether to notify the customer now, wait for engineering confirmation, or prepare a draft without sending it. It identifies four unknowns:

• How long is the expected delay?
• Has the customer already been promised a specific launch time?
• What caused the delay?
• Who should send the message?

All four questions appear relevant, but they do not have equal information value.

The account record shows that the customer was promised activation by 15:00. Engineering has not provided a revised estimate. The highest-value question is therefore:

“Is activation still credible by 15:00, or should I prepare the customer for a delay beyond that commitment?”

This question works because its two answers select different actions. If the commitment remains credible, the agent can monitor and prepare a contingency draft. If not, it can draft an immediate notice and route it to the authorized sender. It avoids asking for a detailed root-cause analysis that would not change the immediate communication decision.

When the Agent Should Investigate Instead of Ask

Asking is not the default response to missing information. An agent should inspect available evidence first when the unknown is factual, recorded, current enough, and governed by a clear source of truth.

Examples include checking a contract for a promised date, reading a deployment system for current status, or consulting an access policy for the correct approver. Asking a person to restate retrievable facts creates delay and introduces memory errors.

Investigation is less appropriate when records conflict, the decision depends on current judgment, or only an accountable owner can make the choice. A system can reveal that a customer has a contractual deadline. It cannot decide whether leadership wants to offer a concession unless that authority has been delegated.

When a Bounded Assumption Is Better

Some uncertainties do not justify an interruption. The agent can proceed with an explicit assumption when the action is reversible, exposure is limited, and the assumption can be checked before commitment.

In the launch example, the agent might assume the account owner will send the message and draft it accordingly. That assumption affects formatting and routing, not the customer commitment itself. The draft remains reviewable.

A bounded assumption should include three elements:

• The assumption: “I am treating the account owner as the sender.”
• The boundary: “I will draft and route the message, but not send it.”
• The invalidation condition: “If incident policy assigns communications to support leadership, I will reroute it.”

This preserves momentum without disguising uncertainty as fact.

Common Failure Modes

Asking for completeness

The agent requests goals, background, stakeholders, timing, and preferences before identifying the actual decision. This feels thorough but imposes an unnecessary intake process. Start with the decision, then collect only discriminating information.

Asking questions with no action branch

“Can you tell me more?” may produce useful context, but it gives the respondent no indication of what matters. Replace it with a question tied to a fork: “Should this optimize for the contractual date or for launch quality if those conflict?”

Ignoring answerability

An agent may ask an executive for technical certainty or an engineer for commercial authority. The question is important but misrouted. Separate evidence questions from authority questions and send each to the appropriate owner.

Seeking precision beyond the decision

If the choice is whether to notify a customer before a deadline, a directional estimate may be sufficient. Demanding an exact recovery time can postpone communication without improving the decision.

How to Implement the Test in an Agent Workflow

Before an agent asks a person anything, require it to produce an internal question brief:

• The decision currently blocked or weakened.
• The credible answer branches.
• The action associated with each branch.
• The evidence already checked.
• The cost of waiting for an answer.
• The safe default if no answer arrives.

The user-facing question should contain only what the person needs. For example: “The customer was promised activation by 15:00. Is that still credible, or should I draft a delay notice now?” The internal brief supports discipline; the external phrasing preserves speed.

The strongest agents do not demonstrate intelligence by asking many perceptive questions. They demonstrate it by finding the single uncertainty that controls the decision, resolving it through the cheapest reliable channel, and continuing the work.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.