The Ask Gap: Why AI Agents Fail Not Because They Can’t Think — But Because They Don’t Know When to Stop

A ticket lands in the queue.

It looks ordinary: update a parser, answer a business question, patch a workflow, produce a SQL query. The agent opens the files, explores the schema, writes code, runs a few checks, and submits something plausible. The output is polished. The reasoning trace is confident. The dashboard marks the task as completed.

Then a human reads it and says the most expensive sentence in automation: “That is not what we meant.”

This is not a story about an agent being stupid. That would be easier. This is a story about an agent being competent enough to continue when it should have stopped. The agent did not lack syntax, search ability, or tool access. It lacked judgment: the ability to notice that the missing piece was not recoverable from the environment and that a human needed to be asked.

That is the central diagnosis in HiL-Bench (Human-in-Loop Benchmark): Do Agents Know When to Ask for Help?¹ The paper’s useful contribution is not merely another benchmark table. We already have enough tables making models look clever under clean conditions. The sharper point is mechanical: when a task contains hidden blockers, the agent must discover the gap, decide whether it is resolvable, ask a targeted question, incorporate the answer, and continue. Most frontier agents fail somewhere in that loop.

Adding an ask_human() tool does not make an agent collaborative. It only gives the agent a door. The paper asks whether the agent knows when to open it.

The failure begins at the moment of unresolvable uncertainty

A normal benchmark asks whether the agent can solve a problem. HiL-Bench asks a more operational question: can the agent tell when the problem, as given, is not yet solvable?

That difference matters because business workflows are rarely written like exam questions. They contain missing definitions, contradictory instructions, tribal knowledge, stale database descriptions, ambiguous policies, legacy exceptions, and phrases that sound precise only to the person who wrote them. “High-value customer,” “active account,” “urgent case,” “legacy API,” “approved vendor,” and “overcrowded school” all look like normal business language until someone has to turn them into executable logic. Then the fog arrives, wearing a badge that says “requirements.”

HiL-Bench turns that fog into a testable structure. It begins with tasks from two established domains: software engineering tasks derived from SWE-Bench Pro, and text-to-SQL tasks derived from BIRD. The authors then inject 3–5 blockers per task. A blocker is a piece of information that is necessary for correct completion but unavailable to the agent unless the agent asks a sufficiently targeted question.

The blocker types are deliberately ordinary:

The benchmark contains 300 tasks, split evenly between software engineering and SQL, with 1,131 blockers in total. The distribution is close to what one would expect from messy work rather than puzzle design: about 42% missing information, 36% ambiguous requests, and 22% contradictory information.

The important design choice is progressive discovery. The blocker is not always visible from the opening prompt. The agent may need to inspect code, query a schema, execute a tool, or follow the workflow before the gap becomes visible. This matters because real uncertainty usually appears mid-task. A developer does not always know at minute one that a requirement is underspecified. A data analyst may discover only after opening the schema that the requested business concept maps to five similar columns and none of them is obviously authoritative.

The paper validates this design with a useful ablation: in SQL, when Claude Opus 4.6 was given only the task description and the ability to ask, but no environment tools, blocker recall fell from 61% to 11%. That test is not the main result. It is a robustness check on the benchmark design. It supports the claim that blockers are discovered through work, not merely by reading the prompt and spotting suspicious wording.

That is the first business lesson. Escalation is not a pre-flight questionnaire. It is part of the work loop.

Ask-F1 makes human attention a scarce resource

Once a benchmark allows agents to ask questions, a lazy metric becomes dangerous. If the only goal is to find all missing information, an agent can ask twenty vague questions and hope one lands. That is not collaboration. That is outsourcing the confusion back to the user, now with extra tokens.

HiL-Bench handles this with Ask-F1, a metric built from two parts:

• Question precision: among the questions the agent asks, how many are actually relevant to a registered blocker?
• Blocker recall: among the blockers in the task, how many did the agent successfully resolve through relevant questions?

Ask-F1 is the harmonic mean of these two quantities. The choice is not cosmetic. It prevents both bad strategies from looking good. An agent that never asks has poor recall. An agent that asks everything has poor precision. A deployable agent needs both.

In business language, this is the difference between “human-in-the-loop” as a slogan and human attention as a costed operational resource. Asking humans is not free. It interrupts managers, analysts, engineers, compliance staff, and customers. A system that asks too little creates silent error. A system that asks too much becomes a clerical nuisance with an API key.

A useful production metric should therefore punish both silence and noise:

This is why Ask-F1 is more than a benchmark metric. It is a compact model of coordination cost.

The judgment gap is much larger than the capability gap

The paper evaluates frontier models under three conditions: blocked tasks without the human-asking tool, full-information tasks where all blocker resolutions are given upfront, and blocked tasks where the agent can use ask_human().

The full-information condition is crucial. It checks whether the models can solve the underlying task when the missing context is restored. If they cannot, the benchmark would merely be measuring ordinary capability limits. But the models do solve many tasks under full information. The collapse appears when they must decide when to ask.

The numbers are rude, which is helpful. In SQL, the best model in the main table reaches 39.3% pass@3 with ask_human() after exceeding 90% under full information. In software engineering, the best result with the asking tool is under 10% in the main table, despite full-information performance above 80% for some models.

This is the judgment gap: the distance between “can solve the task when told everything” and “can solve the task when it must recognize what it needs to ask.”

The gap is not simply that agents refuse to ask. It is more varied, and therefore more annoying. Some agents under-ask. Some ask but ask badly. Some notice that something is wrong and still submit. A simple “make the agent more cautious” instruction would not solve this. It may only move the failure from silent guessing to question spam. The metric decomposition is therefore doing real interpretive work: precision and recall expose different failure shapes.

The paper’s strongest evidence is the mechanism, not the leaderboard

Leaderboards tempt readers into asking which model won. That is the least interesting question here.

The paper’s failure analysis classifies more than 3,600 failure traces across tool use, logic, and alignment. The important finding is that model families exhibit stable behavioral fingerprints. The failures are not random splashes of incompetence; they are patterned.

This section of the paper is useful because it separates three skills that product discussions often collapse into one:

1. detecting that information is missing;
2. asking a precise question that can resolve it;
3. using the answer to complete the task.

A model can possess one of these and still fail the workflow. Claude’s pattern is the cleanest example: uncertainty awareness does not guarantee task recovery. Gemini’s SQL behavior shows another: a model can become more active when human help is available, while still making incorrect downstream moves. GPT-family behavior illustrates the most familiar enterprise failure: fast, confident completion built on a wrong premise.

This is also where the paper’s appendix matters. The failure taxonomy is not a decorative extra section. It is an implementation detail for interpreting the main result. The taxonomy explains whether a failure came from tool-use completion, wrong tool parameters, objective drift, fabrication, self-assessment failure, or logic errors. Without that breakdown, “the agent failed” would remain a black box. With it, the benchmark begins to resemble a diagnostic instrument.

The ask_human() tool changes failure topology, not automatically performance

One of the most practical findings is slightly uncomfortable: adding the asking tool does not uniformly improve agents. It changes how they fail.

For GPT-family models, the asking option often sits unused because the failure happens upstream. The agent forms a wrong belief before it reaches the internal state “I should ask.” For Claude, the tool can deepen exploration without forcing execution. For Gemini, access to human answers can shift behavior dramatically in SQL, but the shift is not always clean success; it can replace one kind of failure with another.

This is a useful warning for enterprise teams adding “approval” or “clarification” steps to agent systems. The existence of an escalation path is not the same as escalation competence. A workflow can have Slack approval, ticket comments, CRM notes, human review, and still fail if the agent does not know when the missing item matters.

The business analogy is simple. Installing an emergency exit does not train people to identify a fire. It only gives them somewhere to go after they know there is one.

RLVR shows judgment is trainable, but the result should be read carefully

The paper’s training experiment is important, but it should not be inflated into a miracle story. The authors fine-tune Qwen3 32B using LoRA and reinforcement learning with verifiable rewards. They train on 120 tasks and evaluate on 30 held-out tasks per domain, with separate experiments for SQL and software engineering.

The reward is shaped around the Ask-F1 objective. Instead of relying only on a sparse final Ask-F1 score, the training signal includes per-step feedback for ask_human() invocations and a terminal component for blocker coverage. In plain English: reward targeted useful questions, penalize noisy ones, and reward resolving blockers.

The likely purpose of this experiment is not to show that Qwen3 32B is suddenly the best business agent. It is to test whether selective escalation can be optimized at all. The answer appears to be yes. The paper reports improvements in both precision and recall on held-out tasks, and it reports positive cross-domain transfer: training on SQL improves help-seeking on held-out software engineering tasks, and vice versa.

That transfer result is the more interesting part. If the gains were only in-domain, one could argue the model learned task-specific quirks: SQL agents ask about schema definitions; coding agents ask about test behavior. Cross-domain transfer suggests the trained behavior is more general: detect unresolvable uncertainty, ask specifically, and continue.

Still, this is not yet a guarantee for enterprise deployment. The domains are SWE and SQL. The blockers are carefully constructed and registered. The human answer is simulated through a controlled oracle. That is exactly what makes the experiment measurable, and exactly why companies should not pretend it already covers procurement, HR, finance close, regulatory review, insurance claims, or customer support without further domain design.

The right takeaway is narrower and stronger: judgment is not merely an emergent side effect of bigger models. It can be specified, measured, and trained.

The appendix tests measurement quality, not a second thesis

A common problem in AI paper reading is treating every appendix table as a new headline. Here the appendix is better read as measurement infrastructure.

This matters because the paper’s central claim depends heavily on clean measurement. If blockers were contrived, the judgment gap would be a puzzle artifact. If the judge accepted vague questions too generously, Ask-F1 would reward question spam. If tasks were unsolvable even with full information, the benchmark would conflate judgment with raw capability. The appendices mostly exist to defend against those failure modes.

For business readers, that is a useful reminder: before measuring “agent performance,” decide whether the test environment actually contains the failure mode you care about. Most internal agent evaluations do not. They test whether the agent can complete a happy-path task under a cooperative specification. Then everyone acts surprised when production has clients, exceptions, legacy fields, and managers who write requirements like fortune cookies.

What companies should measure before calling an agent production-ready

Cognaptus inference starts here: HiL-Bench is not a plug-and-play enterprise evaluation suite, but its measurement logic transfers well.

A company deploying agents should not only ask, “Did the agent complete the task?” It should ask:

1. What information was unavailable to the agent but necessary for correctness?
2. Did the agent encounter the gap during work?
3. Did it recognize the gap as unresolvable from available tools?
4. Did it ask a targeted question?
5. Did it incorporate the answer correctly?
6. Did the escalation save rework, or merely move work back to the human?

That turns evaluation from output grading into workflow diagnosis.

A practical enterprise version might look like this:

This reframes ROI. The cheap version of automation says: replace human labor. The more mature version says: allocate human attention only where human context is actually required. HiL-Bench is valuable because it gives that second version a measurable shape.

There is a governance angle too, but it should be stated plainly rather than wrapped in compliance fog. In regulated or high-risk processes, silent assumption-making is worse than visible uncertainty. An agent that asks a precise question creates an audit trail: here is the missing policy, here is who resolved it, here is how the answer changed the output. An agent that guesses creates a mystery with formatting.

The boundary: HiL-Bench is a strong diagnostic, not the whole production problem

The paper’s evidence comes from software engineering and text-to-SQL tasks. Those are commercially relevant domains, but they are still structured technical environments. They have executable tests, database outputs, and clearer ground truth than many business functions.

That boundary matters. In a sales workflow, the “right” escalation may depend on relationship history. In procurement, it may depend on supplier politics. In legal review, the correct answer may be a risk posture rather than a single registry value. In HR, privacy and fairness constraints may limit what the agent is allowed to ask. The Ask-F1 logic remains useful, but the blocker registry becomes harder to define.

The paper also uses a simulated ask_human() oracle backed by a controlled judge. That is appropriate for benchmark reproducibility. Real humans are slower, inconsistent, occasionally wrong, and sometimes annoyed. A production system would need routing, permissions, answer validation, escalation ownership, and memory updates after resolution. The benchmark isolates judgment; production must operationalize it.

So the correct interpretation is not: “HiL-Bench solves enterprise agents.”

The correct interpretation is: “HiL-Bench identifies a missing evaluation dimension that enterprise agent programs ignore at their own expense.”

That is already enough.

The agent of the future is not fully autonomous; it is selectively dependent

The industry likes the word autonomy because it sounds clean. No human in the loop. No messy handoff. No manager answering annoying questions about what “active” means in the database this quarter.

But real work contains context that is not in the prompt, not in the repository, not in the schema, and not in the model’s weights. Some knowledge lives in policy decisions, team conventions, customer exceptions, and the mildly haunted spreadsheet maintained by the one person nobody remembered to invite to the automation meeting.

HiL-Bench makes this uncomfortable fact measurable. The best agents are not the ones that always continue. They are the ones that can distinguish three situations:

• I can solve this from the available environment.
• I need to explore further before deciding.
• I cannot infer this safely; I must ask.

Most current agents are trained to be impressive in the first situation and theatrical in the second. The third is where production breaks.

That is the ask gap. It is not a failure of intelligence in the usual sense. It is a failure of stopping rules. And in business automation, stopping at the right moment is not hesitation. It is competence.

Cognaptus: Automate the Present, Incubate the Future.