Answer
How do you know when an agent has understood the task?
When it can say what it will not do and where the brief was ambiguous. Confirming it understood proves nothing.
When it can name what falls outside the task and where the brief was ambiguous. A confirmation that it understood is produced whether or not it did, so the demonstration has to be something a misreading could not produce.
Asking whether it understood returns yes, which carries no information because the same answer is produced either way. The question has to be one whose correct answer requires understanding, and there are three that work: what is out of scope, where was the brief ambiguous, and what will the finished thing look like. Each of these has a right answer that a misreading would get wrong in a visible way.
The exclusions question is the strongest and the least used. Stating what falls outside a task requires knowing where its edges are, which is precisely what a partial understanding lacks. A system that has misread the brief will produce exclusions that reveal the misreading immediately — naming as out of scope something central, or failing to exclude the thing you were most worried about. This takes one line to ask and a moment to read.
The ambiguity question is the second. A brief that seemed clear to you contains readings you did not notice, and a system that names them has engaged with the specifics rather than with the general shape. An answer that reports no ambiguities on a brief of any complexity is itself informative, and usually means the general shape was understood and the particulars were not examined.
The finished-state question is the third and the most practical. Describe what will exist when this is complete: which files, what content, what will have changed. A description that matches your intention is a strong signal, and one that describes activity rather than an end state — I will review the records and handle any issues — indicates the completion condition was not understood, which predicts the stopping failures.
None of these establish that the work will be done well, only that the task was read correctly, and that distinction is worth keeping. Correct understanding is necessary rather than sufficient, and it is the cheap thing to verify: a misread task wastes the entire run, while a correctly read one that goes wrong halfway wastes half.
The corresponding habit for the person is to read the answer for what surprises you rather than for whether it agrees. A restatement that matches your intention is easy to skim and the value is in the item you did not expect, which is precisely the item a quick read passes over. If nothing in the response is surprising, either the brief was very clear or the response was not examined.
Ask what it is not going to do, because getting that right requires having understood what it is.
Siddharth Sharma, Context Theory
Related questions
Is a plan the same as understanding?
Related and weaker. A plan can be produced from a general reading of the subject and will look reasonable, whereas exclusions and ambiguities require engagement with your specific brief. Ask for both if the task is substantial, and read the exclusions first, because a wrong plan built on a correct reading is easier to fix than the reverse.
What if it names an ambiguity you had not noticed?
That is the technique working and the answer is to resolve it rather than to let it proceed on its stated resolution. An ambiguity you did not notice is one where your intention was never expressed, so whatever it decided is a guess at something only you know, however sensible the guess looks.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A confirmation of understanding is produced identically whether or not understanding occurred, so the demonstration must be a question whose correct answer a misreading would visibly fail. | Asking a deliberately misbriefed run whether it understood, and comparing with its answer to what is out of scope. |
| Response | Stating what falls outside a task requires knowing its edges, which partial understanding lacks, so exclusions reveal a misreading immediately by naming something central or omitting the concern that mattered. | Reading the exclusions a run proposes against the brief it was given. |
| Software | A finished-state description that names activity rather than an end condition indicates the completion condition was not understood, which predicts premature stopping and unbounded continuation. | Comparing stopping behaviour of runs whose finished-state description named an artefact against those that named an activity. |
| Constraint | A response reporting no ambiguities on a brief of any complexity indicates the general shape was understood while the particulars were not examined, which makes the absence of ambiguities itself a signal. | Submitting a brief with a known ambiguity and checking whether it is reported. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one