I started using ChatGPT’s dot on September 30, 2026.
Since its arrival, I have been using it to discuss the state of the media sites I operate and what to work on next.
An analysis report came back. But a report alone left me asking what was different from an ordinary chat.
The useful question became what responsibility would remain after that answer—not whether the answer looked more impressive.
I have continued using it, but continued use is not the same as verified results.
A proposal that duplicated earlier work helped me clarify what to delegate and what to check myself.
The examples below come from September 30, alongside product conditions checked that day. The question is how to assign work that continues beyond an answer.
I began with work I already had

The opening screen showed a green ring-shaped character and a greeting.
This screenshot records the beginning of the conversation. It is not evidence of completed work or measured impact.
OpenAI describes dot as an always-on agent powered by GPT-6 Astra, with its own cloud computer and browser. It can continue work between conversations and return with results or decisions that need the user.
I approached it as a way to assign ongoing responsibility, rather than as another model to select.
I already have AI-assisted production workflows for writing and site improvements.
Instead of immediately adding another implementation worker, I asked dot to review the portfolio and help organize the next decisions.
From the state of the sites to the next job
Running media sites involves maintaining existing articles as well as writing new ones.
What should come next, and has it already been done? Those are the decisions I have been discussing with dot.
The September 30 discussion used saved reference material and records of earlier improvements.
It was not a workflow that fetched fresh information from every service each time.
A reading task can run successfully while its source data remains stale.
I need to know when the source was prepared and what it covers. A missing value must not become zero: “nothing happened” and “we do not know yet” are different states.
An overall trend does not necessarily justify changing a particular article.
I want missing evidence reported as missing. Before deciding what to change, I need material that supports the decision.
One proposed improvement had already been made
An initial proposal suggested updating a travel article.
Checking the published page and implementation history showed that the relevant changes were already in place.
There was another gap: the query aggregate could not establish those search results for that specific page.
The proposal was withdrawn and the decision material corrected before another production request or public edit was made.
That matters more to this record than a polished list of ideas.
Dot did not remember every earlier intervention and choose a flawless next step. Comparing the proposal with existing records prevented unnecessary work.
I have previously written about moving AI task management from conversation logs to a single source of truth (in Japanese).
The same principle applied here: return to the current decision and implementation record instead of assuming that conversational memory contains everything.
I did not replace all the existing roles
In my setup, dot handles portfolio analysis and priority review.
An existing management role checks whether work has already been done and routes bounded production requests. The production roles implement and verify the assigned changes.
Deciding who may analyze something is not the same as deciding who may change it.
Adding an analyst does not automatically authorize publishing, advertising-setting changes, or external messages.
This arrangement belongs to my local setup and the particular contacts and actions I authorized.
It is not a standard organization included with dot, nor a promise that dot can freely message arbitrary Codex conversations. Connections, task scope, and permissions need separate checks.
For my operation, preventing duplicate work is part of the result—not an administrative detail after the “real” work.
A saved schedule is not an executed job
I also requested an ongoing check.
On September 30, I confirmed on screen that a schedule had been saved.
That established the saved plan, not successful recurring execution.
That scheduled scope covers reading saved material and reporting an analysis only.
It does not include site or ad-setting changes, publication, external posting, contacting other roles, or starting work on my PC. The separately authorized coordination earlier in the day is not part of this recurring scope.
The September 30 check did not establish execution results or report quality.
A saved schedule, an executed run, and a useful recurring report are three different things to verify. A displayed schedule is not an execution guarantee.
OpenAI documents multiple responsibilities and changes of priority within the same conversation.
It also describes relevant context, ChatGPT memory, and dot’s own notes—not a complete, permanently accurate transcript of every conversation.
I still want each responsibility to identify its current sources and stopping point.
Closing my PC depends on where the work runs
According to OpenAI’s computer-access documentation, cloud-only work can continue while my devices are off.
Steps using files or apps on my own computer require that connected computer to be online with the ChatGPT app open. Only one personal computer can be connected at a time.
The cloud browser does not inherit the login sessions in my personal browser.
App connections, permission for local-computer access, and a Codex connection are also separate.
I have not verified that every step of this particular workflow will run with my PC closed.
Before delegating a job, I want to know where it will run, not just what result it promises. A “Connected” label is not proof that all required information is accessible.
Costs make more sense when I separate execution paths
As checked on September 30, 2026, access was rolling out gradually to eligible Pro plans for users over 18 outside the EEA, UK, and Switzerland. Eligibility does not guarantee immediate access.
Business Premium is also rolling out worldwide. Enterprise access requires administrator enablement and is off by default.
OpenAI’s Help page says the first dot is included at no extra cost in Pro and Business Premium. That statement does not establish an individual Enterprise agreement.
Included is not the same as unlimited. I separated the current explanation as follows.
| Path | What was established on September 30, 2026 |
|---|---|
| Conversation with dot | Official documentation says it does not count toward ChatGPT usage limits |
| Direct work by dot | The employee clarification says direct work does not draw down existing plan usage; exact dot-specific limits remain unconfirmed. |
| Work or Codex tasks started or managed by dot | Official pricing documentation says the normal shared Work/Codex usage limits apply |
| Dot’s deeper-work allowance | Included in the plan, with extended limits for the launch month; exact quantities and reset periods were not established here |
The direct-work clarification comes from OpenAI employee Tibo’s post on September 30 at 10:07 JST.
I treat that as a dated, attributed clarification, not as an equivalent to a contractual pricing guarantee.
Future ways to increase speed or output are described, but I have not established their prices, detailed personal-account remaining-balance displays, or the ordinary allowance quantities.
None of this means every delegated task is free for the first month or that Astra use is unlimited.
I have not measured the usage consumed by this request.
Two jobs requested through dot may need different accounting if one is handled directly and another becomes a Work or Codex task. For the broader distinction, see monitoring AI quotas versus planning a week.
A small test should have a clear end
Continuing to use dot does not mean expanding every responsibility at once.
The September 30 analysis, correction of a duplicate proposal, role clarification, and saved schedule gave me a starting point for bounded delegation.
This is not a measured record of time saved, usage reduced, business impact, or recurring execution quality.
For an initial test, I would start with bounded read-only work. This is an illustrative request, not a quotation from my conversation:
Read the specified aggregate report and implementation history. Return no more than three candidates for the next review.
Include the evidence period, missing information, and any overlap with completed work.
Stop after the analysis. Do not change documents, send messages, publish, create a schedule, or start another task.
If I later want recurring work, I would separately specify its frequency, time zone, end date, and notification conditions.
I would check the saved schedule and permissions rather than treating an acknowledgment as setup completion.
Stopping also has separate scopes. OpenAI’s Controls documentation distinguishes pausing dot, stopping a delegated task, and canceling a recurring schedule.
Stopping does not undo completed changes. I want to understand the stop boundary before expanding the work boundary.
Keep the responsibility after the answer clear
The conversation moved from asking for analysis to deciding what should remain after it: the next source to read, the work already completed, the person or role making the decision, and the changes that are permitted.
A new AI does not automatically organize an existing operation.
In the September 30 example, checking history stopped a duplicate improvement before implementation.
Rather than ending at a reply, I want to decide what carries forward and where to verify it. As I continue using dot, I will keep assigned work separate from verified results.
Sources
Product conditions checked September 30, 2026. Specific examples come from that day’s records; continued use reflects my situation as of October 1.
This is not evidence of long-term impact or successful recurring execution.