Answer
What should an agent report when it finishes?
What it changed, what it could not do, what it assumed, and how much of the input set it covered.
What changed, what it could not do, what it assumed, and how many items it covered out of how many exist. An account of what it did is the natural shape and answers none of those questions.
The natural shape of a completion report is a narrative of the work, and it is the least useful shape available. The reader is not trying to follow the run; they are trying to decide what needs their attention and whether they can accept the result. Four items answer that and a narrative answers none of them, which is why the report should be specified rather than left to arrive in whatever form the run produces.
Changes come first and should be enumerated rather than described. Which files, which records, which fields, which messages — a list a reader can check against, rather than a sentence saying the records were updated. This is also the item most likely to reveal something unexpected, since incidental changes appear in a list and disappear in a description.
Failures come second and are the section most often absent. What could not be done, what was attempted and abandoned, what returned an error, what was ambiguous. A report of unbroken success on a substantial task is a report nobody has looked at closely, because substantial tasks contain obstacles. Requiring this section explicitly is what makes it appear.
Assumptions come third. Every run fills gaps in the brief, and those fills are invisible in the output and consequential downstream. Listing them converts a hidden decision into a visible one, and the reader who disagrees with an assumption learns it now rather than from the consequence. This is consistently the most useful section and the one nobody asks for.
Coverage comes fourth and is the one that detects partial completion. How many items existed, how many were handled, how many were skipped and why. No amount of checking the work performed reveals work not attempted, and a coverage line is the only thing that does. It is also two numbers, which makes it the cheapest item on the list to produce and to read.
The report should be short enough to read in full, because a long one is skimmed and a skimmed report creates the impression that the result was reviewed. Detail belongs in the artefacts and in the log; the report is a decision aid. If it runs past a page, the run probably did several things and should have been several runs.
Nobody reads a completion report to find out what happened; they read it to find out what to check.
Siddharth Sharma, Context Theory
Related questions
Should it include what went well?
Only as the coverage figure, which is the useful form. Narrative reassurance about successful portions consumes attention that belongs on the four items and makes the report longer, which reduces the chance it is read properly. The absence of failures in a section that exists is already the good news.
Who should the report be written for?
Someone who was not watching and needs to decide whether to accept the result. That framing settles most formatting questions: no references to earlier context, no assumption that the reader knows what was being attempted, and every item stated rather than implied. It is the same standard as a handover.
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 | A completion report is read to decide what needs attention and whether the result is acceptable, and a narrative of the run answers neither, which makes the report's contents something to specify rather than to receive. | Taking a past agent report and attempting to decide from it what requires checking. |
| Response | Enumerating changes rather than describing them reveals incidental modifications, which appear in a list and vanish in a sentence such as the records were updated. | Comparing an agent's described changes against the enumerated file or record list from the same run. |
| Constraint | A report of unbroken success on a substantial task indicates unexamined execution rather than a clean run, because substantial tasks contain obstacles, so the failure section must be required explicitly. | Comparing the failures section of a report against the error entries in the runtime log for the same run. |
| Software | Coverage stated as items handled against items existing is the only element that detects work never attempted, since no examination of completed work reveals its absence, and it costs two numbers. | Comparing the coverage figure in a report against the size of the input 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