After a task started, I could still receive repeated answers saying that it had not finished. Waiting with no new decision was becoming another model turn and another transfer of context. While reusing the cafe and YouTube plugins, I moved those status reads into a local orchestration program.
Waiting had become entangled with judgment
The content, destination and time were already settled, yet each status read brought the agent back through the surrounding workflow. A changed result can require judgment; repeatedly seeing running can follow a rule already chosen. Moving responsibility for normal waiting mattered more than merely shortening the wording of each model answer.
I did not need to replace the existing plugins. One start request returns a run ID that can be followed. A local cafe reservation may require finding that entry in a reservation list, so its adapter uses that specific read. Different execution forms need different adapters, while the rule against creating another submission during a wait remains common.
The existing run ID became the anchor
The plugin runner separates an initial execution from following an existing run. With a known resumeRunId, it does not start again; it reads that ID. A first start compares the prepared context with the current context and submits once to the existing plugin. A transport error is not handled by repeating the start call.
When context changes, the runner checks the project, profile and original run before continuing. A different project becoming visible does not justify retargeting the lookup. Convenience in reading status must not widen execution ownership. Waiting needs an anchor to the same work, just as dispatch does.
Keep detailed checks local and return a summary
Status reads, interval waits and final checking happen inside the same local execution. Detailed records and errors remain in an output folder, while the model receives a bounded summary such as run ID, state and verification. This reduces repeated transfers of whole intermediate screens into the conversation.
A shorter log is not itself verified work. A summary saying succeeded still depends on the original plugin's verification and the relevant service outcome. A cafe publication check and a YouTube private-visibility check cannot be collapsed into one meaning. The summary should be an entrance to retained evidence, not a phrase that conceals its absence.
Read measurements with their conditions and units
The historical final comparison records external model requests changing from nine to one. It separately records cache-inclusive total tokens and non-cached input plus output. Zero internal model calls in the normal plugin path explains the architecture but does not mean that the external Codex conversation consumed zero tokens.
Those sequential rounds had different accumulated conversation length and cache state; they were not a controlled experiment promising a fixed saving. I use the record to connect the changed execution path with the measured scope, not to price every future task. I did not republish an old cafe post or upload another video to reproduce the figures while writing this article.
Retain the original result after a wait timeout
When a waiting deadline is reached, the original run ID and receipt should survive. The program may have completed late, or only the status response may have been lost. Treating the end of local waiting as remote failure can create another upload or post.
The new shared module isolates that boundary. It accepts only a reader for an existing run and exposes no start operation. Stops, scope changes, unresolved outcomes and read errors each terminate waiting. It does not replace the stored plugin's recovery journal, but it makes the separation between waiting and resubmission something a reader can test directly.
Where I would start on another automation
I would first ask whether a wait needs a new decision. If it is only a status read, move it into code with explicit completion, stop and transport-timeout rules. A changed target or a state needing a human choice should return a precise question to the agent or person. Automatic retries should not conceal every stop.
I describe this as a specific improvement to waiting. Reducing request fields, discovering fewer schemas and managing accumulated conversation have different responsibilities. The aim is a shorter normal path while preserving the boundary between execution and judgment: fewer conversational steps to know accurately how far one requested job has progressed.