ChatGPT Dots: Hand Off an Outcome, Not Another Conversation

TL;DR: Dots launched September 29, 2026 as agents that keep working between conversations.^[1] The useful handoff specifies an outcome, evidence and a finish line; OpenAI’s documentation explicitly warns that a completed run does not establish that its requested result was achieved or delivered.^[3] Define what deserves an update, review the artifact and close the relevant work rather than assuming the conversation ended it.

Cover: AI-generated editorial concept. The relay baton and work trays illustrate a bounded handoff, not a real product interface or a measured productivity result. Analysis dated October 5, 2026.

The weakest way to use a persistent agent is to keep asking it what to do next. That leaves the human carrying the project in their head while the software supplies fragments. The conversation gets longer; the responsibility stays where it started.

Dots make a different offer. OpenAI’s getting-started guide recommends describing work to keep track of, relevant sources and decisions that need your input. Ending the conversation does not necessarily stop that assignment.^[2] The strategic question is therefore how much coordination a user can hand over while retaining a clear standard for accepting the result. This is a workflow argument, not a claim that Dots have eliminated supervision.

The Handoff: Replace Activity With An Acceptable Result

“Look into our launch” describes effort. It does not say whether the user expects research, a decision memo, updated files or communication with customers. Each outcome entails a different evidence requirement and a different moment for human judgment.

OpenAI’s long-running-work guide asks for an outcome, constraints and verification. Its Codex best-practices guide adds context and an explicit definition of done.^[6][5] We recommend applying that structure to a Dot assignment while keeping product controls and eligibility separate. A useful brief is a small working agreement, not a ritual of increasingly elaborate prompts.

Here is an illustrative handoff:

Prepare a launch-readiness memo from the release checklist and customer-feedback files I attached. Identify unresolved blockers, link each finding to its evidence and suggest a next decision. Save an editable memo for my review. Finish when each checklist item is either supported by current evidence or explicitly marked unresolved. Bring missing access or conflicting requirements to me. Keep external communication for a separate decision.

That brief makes the artifact, source set, acceptance rule and escalation path visible. It allows routine investigation without requiring the owner to narrate each step. It also avoids treating a beautifully written paragraph as proof that the launch is ready.

The Evidence: Give Delegated Work A Portable Brief

A persistent agent can coordinate several responsibilities, but coordination is not universal context. OpenAI says a newly created task receives instructions and context for that work; it does not automatically inherit every conversation with the Dot.^[3] Assuming otherwise can produce an apparently competent result based on an incomplete brief.

Put decisions that affect the result into the handoff itself. If mobile checkout is the priority, state that priority alongside the relevant issue. If the desktop behavior must remain, identify it as a constraint. If a pricing table changed yesterday, provide the current source instead of relying on a remembered discussion about an earlier version.

For file deliverables, OpenAI recommends specifying source data, expected file type, structure and review criteria. Preview tools differ across desktop, web, CLI and the IDE extension.^[7] Our practical addition is to ask for the output location and a short statement of what was checked. A file you cannot locate or inspect has not become useful simply because the agent mentions it.

This is where persistent assistance can earn its keep: translating a messy stream of decisions into a brief that another task can execute. The owner should still be able to inspect that translation. A material omission in the handoff is a defect in the workflow, not a reason to add more unrelated context indiscriminately.

The Update: Reserve Attention For Changed Decisions

A good handoff also defines when the user should return. Routine narration can overwhelm the attention an agent was supposed to save. Our recommendation is to request updates when the result is ready, a blocker needs judgment or new evidence changes a decision. The desired notification is a consequence, with its supporting facts.

Dots can continue across contact methods without resetting memory. OpenAI’s messaging guide distinguishes that continuity from monitoring: adding a Dot to a channel does not establish a monitoring schedule.^[8] A useful request must therefore identify the source and the condition it should follow, then ask it to confirm the setup. Do not infer an operating workflow from the presence of an avatar.

Keep the delivery destination explicit too. A private review memo and a team-channel update are different outputs. OpenAI’s controls guide says drafting replies does not grant permission to send them.^[4] Decide which result you want before the agent approaches the last step. That boundary avoids a common handoff failure: producing the correct content for the wrong audience.

The Review: Judge The Outcome, Not The Status

The most consequential sentence in the tasks documentation is its distinction between a completed run and an achieved or delivered result.^[3] A status can describe the execution lifecycle while leaving the business question unresolved. The owner needs evidence of the outcome.

For the launch memo, sample its claims against the source files. Check whether unresolved items are visible, whether contradictory evidence was acknowledged and whether the recommendation follows from the findings. For a code change, review the intended behavior and relevant validation. For a spreadsheet, inspect formulas and units. The appropriate test depends on the artifact, not on how confidently it is described.

Do not mistake longer work for better work either. OpenAI says Dot conversations do not count toward ChatGPT usage limits, while tasks started or managed in Work and Codex count toward their usual limits.^[9] A handoff can initiate substantial underlying work even when the conversation is brief. Measure accepted outputs, review time and rework against the capacity spent. We have not measured a universal productivity or cost saving.

The Finish Line: Close Responsibility Deliberately

Completion criteria should include what happens after acceptance. A one-time memo ends when its agreed review is satisfied. An ongoing responsibility needs a separate duration or stopping instruction. Otherwise yesterday’s helpful assignment can become tomorrow’s unclear obligation.

OpenAI’s controls guide distinguishes three actions: pausing the Dot’s current main task, stopping a delegated task and disabling or deleting a recurring schedule. Pause does not stop every delegated task or cancel future runs.^[4] Ending a voice call can also leave assigned work continuing.^[8] These are practical limits to account for, not reasons to avoid delegation.

Before closing the project, inspect active work, retain the accepted artifact and identify any continuing assignment that no longer serves the goal. Then stop that work through its relevant control. A finish line should be as deliberate as the initial handoff.

The durable advantage of Dots will depend on how much coordination they remove from useful work. More conversation is an easy metric to accumulate. An outcome that survives review is the harder standard, and the one that matters.

Last updated: October 5, 2026