Our agent marked twelve unsent briefs as complete.
In one of our client projects, an agent was supposed to write and send briefs. From 2 July 2026, it had written twelve. The briefs were fine. The log showed the work as complete. Yet none of them had been sent.[S1]
We found out when the client’s programme sponsor asked what “0 sent” meant. Until then, we had relied on a status the agent had entered itself. The send call had returned neither an error nor a confirmation. The agent had moved to the next step and closed the task.[S1]
That is how a detailed log can still leave the most important question unanswered. We could read what the agent believed it had finished. We could not use that record to check whether the work had reached the client. For the team waiting for those briefs, that was the part that mattered.
A “sent” record needs a message from the mail system.
Take the same task again: a brief needs to go to a particular person. A saved file shows that the text exists. A message in the sending system shows that a send took place. Check its recipient and time as well. You can then establish whether that message belongs to this task.
The mail service’s response can help. After a successful send, for example, the Gmail API returns a message that can be found again using its identifier.[S3] Keep that identifier in the record. It still does not tell you whether the recipient read the message or used the work.
For your team’s view, keep the stages separate: written, sent, delivered and reviewed by a person. If you cannot observe a stage, leave it open. This turns a blanket “complete” into a sequence someone else can follow. Agent evaluation makes the same distinction between an account of an action and its actual result in the environment.[S2]
If the record says “sent”, you should be able to find the message.
Ten details connect the task to its result.
The delivery record is one part of the story. When something goes wrong, your team also needs to know what the task was, which access was allowed and who checked the work. We suggest keeping the ten details below. They need to connect: from the task, you should be able to find the agent’s run and then its result.
| Detail | What it lets you check |
|---|---|
| Agent and version | Which agent did the work, using which model and settings? |
| Task and start | What was due, by when? What started the run? |
| Task boundaries | What was in scope, and what could the agent decide for itself? |
| Allowed access | Which systems could it use? Who had authorised that access? |
| Steps taken | What did it call or change, and what response came back? |
| Information used | Which data and versions did it work from? |
| Result and recipient | Where is the file, message or record? Who is it for, and when was it created? |
| Time and cost | How long did the task take, what did it cost, and were there further attempts? |
| Human review | Who checked or approved the result, when, and with what decision? |
| Handover | Did the work arrive and get accepted? What do we still not know? |
A shared task identifier helps connect these entries. You do not need to copy every piece of content into another system. A reference to the relevant message or file version may be enough. Sensitive information stays where the responsible people have appropriate access to it.
Someone also needs to act when a result is missing. Our answer on accountability for agent mistakes explains how to assign that responsibility. The credentials answer covers who gives the agent access to its tools.
Matching each task to its message reveals missing and duplicate deliveries.
You can look for this gap in an agent already at work. Choose one week and a clear task, such as sending briefs. List the briefs that were due that week. Then look in the sending system for the messages that actually exist. This second list needs to come from something other than the agent’s own completion status.[S1]
Match each expected brief to its message. Are the recipient and time right? Is anything missing? Was something sent twice? Comparing totals alone is not enough: one missing message and one duplicate can cancel each other out. This task-by-task check extends the two-list comparison in our published account.[S1]
If a send is uncertain, look for the message before trying again. The send may have worked even though its confirmation is missing. An immediate retry would then create a second message. Give anything you cannot resolve to a named person, with a time to check it.
The handover to the recipient belongs in the acceptance test.
For the next agent, include the final handover in the test from the start. In a controlled setting, try an ordinary task, a failed action and an unclear response. Can another person explain afterwards what happened and what remains open? Our acceptance checklist covers the other questions to ask before release.
We are also working on a separate check of file changes, independent of what the agent says it did. Whether it catches this kind of incident before a person notices has not yet been demonstrated.[S1] You do not have to wait for that to start: take one task already running and try to follow its work all the way to the intended recipient.
What this answer draws on
The twelve briefs come from one client project from July 2026, described in our publication The Hybrid Company.[S1] The project records are private; this case does not establish a general failure rate. The ten details and task-by-task check are our proposed practical method. The responsible teams need to decide retention, privacy and access for their own task.
