Answer
How should an agent know when a task is finished?
By running a test it did not write, against a condition stated before it started. Self-assessment produces agreement, not completion.
By checking against a condition that was stated before it started, using a test it did not author. Asking an agent whether it has finished returns yes, because a plausible account of completion is what it is best at producing.
There are three ways a system can decide it is done, and they are not equally reliable. It can compare the result against a stated condition. It can run something that passes or fails. Or it can assess whether the work looks finished. The third is the default when nothing else is available, and it is the mechanism behind nearly every complaint about agents stopping in the wrong place, because looking finished is precisely the property these systems produce most reliably.
So the design question is which of the first two you can afford. A stated condition is the cheap version: the reconciliation balances, every row has a category, the list covers all outstanding items. It works when the condition is checkable by inspection and the agent has to describe how it was met rather than merely assert it. Requiring the evidence rather than the claim is what converts a stated condition from a slogan into a test.
A runnable check is the strong version and it is worth engineering where the work justifies it: a test suite, a validation script, a query whose result must be empty, a comparison against a known-good output. Its property is independence. It was written before the run, it does not consult the agent, and it produces the same verdict whether or not the agent believes the work is complete. Anything that can be moved from prose judgement into a runnable check should be.
There is an important asymmetry between the two directions of error. An agent that stops too early and says so is a nuisance; an agent that stops too early and reports success is a defect, because the work then enters the business as complete. That argues for completion tests that are hard to pass accidentally — an empty result set, a passing suite, a matching total — rather than tests that are satisfied by the presence of output.
The failure that survives all of this is the partial completion: the agent did the part it looked at, and what it did is correct. No check on the work performed will catch it, because that work is fine. Catching it requires a check on coverage rather than on quality — every record, every file, every case accounted for, with the ones deliberately skipped named and counted. Coverage is the specific thing agents do not track for themselves and the specific thing a completion condition should demand.
Finally, distinguish finished from good. A completion test says the work meets the condition, which is not the same as saying it should be shipped. Where the second question matters, it belongs to a separate review with different criteria, and conflating them produces either a completion test so demanding that nothing passes or a review so mechanical that it approves anything that ran.
Completion is a measurement, and an agent asked to measure its own is being asked to grade an exam it wrote the answers to.
Siddharth Sharma, Context Theory
Related questions
What if the task has no runnable check?
Then the completion condition has to be stated as an inspectable claim and the agent has to show its working: what it covered, what it found, what it skipped and why. That is weaker than a test and much stronger than an assertion, and where the work is consequential it usually indicates the job should be scoped down until a check does exist.
Should the agent write its own tests?
It can write them and it should not be the only party to have seen them, because a test authored after the work tends to encode what the work does rather than what was required. The cheap discipline is to write the completion condition before the run and to read any test the agent produced against that condition rather than against the output.
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 |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Three completion mechanisms exist — comparison against a stated condition, a runnable pass-or-fail check, and an assessment of whether the work looks finished — and the third becomes the default whenever the first two are absent, which is the mechanism behind agents stopping in the wrong place. | Examining a stopping decision in an agent log for which of the three it rested on. |
| Software | A completion check written before the run is independent of the agent's belief about the work, so it returns the same verdict regardless of how the run described itself, which is the property that a post-hoc test written by the agent does not have. | Comparing the verdict of a pre-written validation against the agent's own completion statement on the same run. |
| Response | Stopping early with a report of success is categorically worse than stopping early and saying so, because the first delivers incomplete work into the business as finished, which argues for completion tests that cannot be satisfied merely by the presence of output. | Checking whether a completion condition would still pass if the agent produced output covering only part of the input set. |
| Constraint | Partial completion escapes every quality check because the work actually performed is correct, so detection requires a coverage condition naming every record, file or case accounted for, including those deliberately skipped and the reason. | Comparing the count of items in the agent's report against the count in the source set. |
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