An email had been sent. That did not yet mean dot had received the result. Those are two different checkpoints, and using AI agents has made me more careful about the gap between them.
On October 19, 2026, I had existing Codex tasks send two approved tool suggestions, then followed their reported results through to ChatGPT’s dot. There were human approvals along the way, including one extra notification to prompt result collection. This was not an unattended workflow that carried itself from an initial idea to a finished business outcome.
What I wanted to establish was smaller: who did the work, what they checked, and what dot actually received.
The result has to make the return trip
I have already written about using dot for ongoing work. That article covers starting out, overlapping proposals, and the limits of connecting existing tasks. Here I want to stay with one later case rather than retell the connection tests.
In my setup, an existing task does the work, a coordinator collects its report, and a relay prepares a result for dot. These are roles in my own operation, not a ready-made organisation that comes with the product.
That division creates intermediate states that are easy to call “done” too early. A task may have finished and saved a report without the coordinator having read it. The coordinator may have collected the result without dot having received it.
Neither state means the work has vanished. It means the return trip is still incomplete. If I collapse all of them into a single completion flag, I lose the place from which to continue.
I approved the external actions first
The suggestions concerned Evidence Gate, a tool I build to organise evidence and verification status before publishing technical writing. It works with recorded information; it is not a machine that guarantees a piece of writing is true.
The destinations were Console, a developer-tools newsletter, and Python Bytes, a Python news podcast. Each received a separate suggestion with its own approved recipient and final text.
I approved the Console message at 09:12 JST and the Python Bytes message at 09:35. An existing Codex task carried out the sends. This was not a campaign conceived and autonomously directed by dot.
The permission covered one message to each destination, not reminders, further pitches, or changes to the offer. Researching a destination, drafting a suggestion, and sending it were separate decisions. Approving the draft did not silently approve the external action.
Work on the product’s landing page happened through a different request path around the same time. I am not adding that release to this story as though dot directed the whole project.
Sent, acknowledged, and featured are different outcomes
The executing task did not rely only on a successful send response. It read back the same sent message, checked its SENT status, and compared its recipient, subject, and body with the version I had approved. The Console send was confirmed at 09:15 JST; the Python Bytes send at 09:36. Each was sent once.
Console also returned an automated acknowledgement. The task checked that the reply belonged to the original message and was marked as an automatic response. That supports a narrow statement about the acknowledgement, not a claim that an editor personally reviewed or selected the tool.
For Python Bytes, the record established that the approved message had been sent. It did not establish that someone opened it, replied, accepted the suggestion, featured it, or used the tool.
| Recorded result | What it did not establish |
|---|---|
| Sent mail matching the approved text | The recipient opened it |
| Console’s automated acknowledgement | An editor reviewed or accepted the suggestion |
| A saved task report | Dot read the report |
| Dot’s receipt of the relay’s answer | Dot directly inspected the original email or file |
I find this distinction more useful than describing every visible response as progress. It leaves the next decision attached to something that was actually checked.
Saving a report was not the final handoff
The task saved its results, and the coordinator collected the task’s answer and supporting records. That was a completed collection step. It was not yet proof that dot had read the result.
At 10:02 JST, I explicitly permitted one notification to the existing dot conversation, limited to collecting these saved results. One notification was sent under that permission. It did not ask the task to send either email again.
The relay then checked the saved execution records and returned a detailed answer. At 10:05, dot explicitly stated that it had read that answer in full. The receipt response was subsequently checked as well.
What dot read was the relay’s answer. It did not claim to have opened the original emails or directly read the original files. Its receipt covered the reported Console acknowledgement, the confirmed Python Bytes send, and the limited follow-up already attached to that work.
The extra notification belongs in the account of what happened. Leaving it out would make a human-assisted return path look automatic. The case does not demonstrate that every completed task will always find its way back to dot without intervention.
It also changed where I would look when a result seems missing. Before repeating the original action, I want to know whether the work already exists and which part of the return path has not been confirmed. A missing report is not permission to send another email.
What the official documentation says, and what I added
OpenAI’s Assigned work documentation describes continuing an existing local Codex task on a connected computer. Connecting a computer does not grant access to every existing conversation. For tasks dot created, the documentation says to check results and send follow-up instructions through the original computer or cloud environment where the task was created.
The same documentation warns that a completed run does not by itself confirm that the requested result was achieved or delivered. That warning is a useful way to read this case.
Control your dot describes reviewing progress, files, results, and requests for input through Activity. It distinguishes permission to draft from permission to send, and says custom rules do not grant app access or remove required safety checks. These are documented capabilities and boundaries; I did not test every screen or review path for this article.
My coordinator and relay arrangement sits on top of that. It is not evidence that every reader has the same tools, connections, or access to an existing task. I would establish the available reader, executor, and return path before depending on a similar workflow elsewhere.
Ask for the return format before the work starts
I previously moved agent task management away from conversation logs and into a single source of truth. The same principle mattered here: return to the current result rather than assuming the conversation contains everything.
For a small first test, I would use a read-only check rather than an external action. This is a suggested template for readers, not a quotation from my messages that day:
Purpose: establish the current state of the specified work.
Scope: this one item and its saved result only.
Executor: the existing task responsible for the work.
Limits: read and compare; do not modify, publish, or send anything.
Return: who checked what, the result, unknowns, and the next decision.
Stop: if the target is wrong or unreadable, report where you stopped.When the answer comes back, “finished” is not the only word I look for. Who inspected the evidence? Did they inspect the original object, or read another task’s report about it? Both can be useful, provided the report keeps the difference visible.
A short report should still say who checked what
I do not want every handoff to become another long audit. The useful version is a short answer with enough context to return to the evidence when needed. For this case, I would reconstruct it like this:
Action: each approved suggestion was sent once.
Checker: the task that executed the sends.
Evidence: the same sent messages, their SENT status, and matching text.
Return: dot confirmed reading the relay’s detailed answer.
Unknown: publication by the recipients and third-party use.
Next: no further sends; continue only the already-approved limited checks.That is an explanatory reconstruction, not private correspondence. Removing the checker or the object they read would make the report shorter, but less useful. I would rather keep those two details than add a general assurance that everything went well.
Close the loop without enlarging the claim
This case reached a specific end: human-approved suggestions were sent, the task checked those sends, and dot received the relay’s account of the results. An automated acknowledgement did not become an editorial acceptance. A received answer did not become direct inspection of the source emails.
Before delegating, I want to say both what may be done and what should come back. Afterwards, I want the result, its evidence, its checker, and its remaining unknowns. That is the small loop I intend to keep testing, rather than treating task completion as the end of the job.
If you are defining similar handoffs for your own work, you can contact me about the workflow and its boundaries.
References
Official documentation checked on October 21, 2026. The case is based on saved records from October 19, 2026; dot’s receipt covers the relay answer it acknowledged at 10:05 JST that day. This is not evidence of publication by the recipients, third-party adoption, or measured time, usage, or revenue improvements.