Glossary
Failure to ask for clarification
Failure to ask for clarification is the multi-agent failure mode in which an agent meets an ambiguous brief, settles the ambiguity silently with a guess, and passes the guess downstream as a fact, so no agent after it learns that a question was ever open.
Failure to ask for clarification is the failure mode in which an agent receives a brief that admits more than one reading, picks one of them without saying so, and carries on. What travels downstream is the conclusion the agent reached, formatted exactly like a conclusion it had grounds for. The receiving agent gets a fact where a question should have been, and nothing in the message marks the difference, which is what separates this mode from an ordinary wrong answer: a wrong answer can be checked against the brief, and a silently resolved ambiguity leaves the brief looking satisfied.
The missing signal is the whole defect. An agent that guesses well produces the same message as an agent that knew, and an agent that guesses badly produces a message that is wrong in a way no downstream check can attribute, because the choice it made is not in the record. By the time the error surfaces, the reconstruction has to run backward through however many hops treated the guess as settled, which is a failure attribution problem with the key evidence absent by construction.
MAST, the empirical taxonomy of multi-agent LLM failures, files the mode as FM-2.2 under inter-agent misalignment, describing it as proceeding with wrong assumptions instead of seeking clarification (Cemri et al., Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657, v3, NeurIPS 2025 spotlight poster). It puts the mode at 6.80% of annotated failures, third of the category’s six, behind reasoning-action mismatch at 13.2% and task derailment at 7.40%. Those are descriptive shares of a machine-labeled corpus. MAST developed the taxonomy from 150 execution traces read by expert human annotators at kappa 0.88, then scaled the labeling across seven frameworks with an LLM-as-judge pipeline, and the published distribution rests on an analysis of 1,642 execution traces with no confidence interval on any figure. The counts differ by revision as well, since the April 2025 version described over 200 tasks and the October 2025 one reports 1,642 traces. The percentages here are from the October 2025 revision.
This mode and reasoning-action mismatch, the category’s largest, are both failures of a single agent’s own discipline, so the typed handoff that catches a malformed message between agents does not reach either of them. The lever for this one is different, and our taxonomy pillar names it.
Clarification gates
A clarification gate requires an agent to resolve a flagged ambiguity before it commits, turning a silent guess into an explicit question. The gate sits between the agent’s plan and its first irreversible act: the tool call that writes, the message that hands off, the answer that returns. Ahead of that point a question costs a round trip. Past it, the guess has been read by something else and the cost is a retraction.
Making the gate real takes three pieces. The first is a way for the agent to raise a question as a first-class output rather than as prose inside an answer, since an ambiguity mentioned in a paragraph the next agent summarizes away has not been raised at all. The second is somewhere for the question to go: a human, an orchestrator with the missing context, or a resolution step with access to the source the brief was drawn from. An agent that can ask and has nobody to ask will answer its own question and the gate becomes a formality. The third is a default for when no answer arrives in time, and the honest default is to return the ambiguity alongside a marked provisional reading, which is a degraded response that says so rather than a confident one.
Every gate is also a stall, and this is the cost worth stating plainly. An agent that asks about everything is as useless as one that asks about nothing, and in a pipeline of any depth the questions compound: five agents each asking two questions is ten interruptions on one task. The tuning knob is the threshold at which an ambiguity is worth raising, and it is a product decision more than an engineering one. Where the pipeline is long and the hops are cheap to redo, a permissive threshold costs little. Where a hop commits an external side effect, the threshold should be low enough that the gate fires on anything the agent cannot resolve from what it was given.
How to measure it
The count you can get is the count of questions asked. The count you want is the count of ambiguities that should have produced a question, and no instrument reads that off a production trace, because an ambiguity nobody flagged looks identical to a brief that was clear. This asymmetry is the measurement problem and it should be stated rather than papered over.
The tractable version replaces observation with a labeled set. Build a suite of briefs in which specific ambiguities are planted deliberately, each with a record of what is underspecified and which readings are available. Run the system and score, per brief, whether the ambiguity was surfaced before commitment. The rate is surfaced ambiguities divided by planted ambiguities, and the denominator is honest because you wrote it. That is fault injection with the fault placed in the brief rather than in a tool, and it gives the one number a production log cannot: a false-negative rate. Report it as a proportion with an interval, since a suite of thirty planted briefs produces bounds wide enough to change how you read a difference between two builds, which is what any eval confidence interval exists to show, and the pass-rate interval calculator takes the two counts directly.
Two things belong beside that rate. One is the false-positive side, measured on unambiguous briefs, because a system tuned to surface everything scores perfectly on the planted set and is unusable. The other is where in the run the question arrived, since an ambiguity surfaced after the agent already wrote to shared state was surfaced too late to count as contained.
Failure to ask for clarification vs information withholding
Both modes leave a downstream agent working from less than it needed, and they sit on opposite sides of the boundary. Withholding is a sender-side omission: the agent had the item, and the message it composed left it out. Failing to clarify is a receiver-side omission: the agent lacked the item, knew or should have known that it lacked it, and did not ask.
The distinction survives contact with a real system because the two can occur independently in the same run. A sender can transmit a complete brief to an agent that still guesses at something genuinely underspecified in the original task, where nobody upstream had the answer either. A sender can also hold back a detail its peer needed while the receiver asks no question, since nothing in its input suggested a detail was missing. That second case is the common one and it explains why the pair is hard to separate in a post-mortem: the visible evidence in both is a downstream agent acting on an incomplete picture. What separates them is whether the missing item existed upstream at the moment of the handoff. Their repairs live in different components, one in whatever composes the outgoing message and the other in whatever decides an agent may proceed.
The related transport failure sits elsewhere again. When the item was sent and did not arrive intact, what gets dropped between agents is the term for it, and a system audited only for silent guesses will score clean while its summaries shed a constraint at every hop.
An ambiguity that reaches production unflagged is cheap to catch at the agent that met it and expensive to unwind from a finished run, which is the argument for spending a round trip. The rest of this vocabulary is indexed in the term-by-term guide to multi-agent failures, and the fuller account of which lever bounds which category is in the multi-agent failure taxonomy.