OpenAI launched dots today. The useful part is not another place to type a prompt.
A dot is an always-on agent in ChatGPT that can take responsibility for ongoing work and make progress between conversations. It has its own cloud computer, can use connected apps, remembers the context of its work, and can return when it needs a judgment call.
That changes the unit of delegation.
I am no longer assigning only a prompt. I can define a role.
The shift is from requests to responsibility.
Most AI work still begins with a request and ends with an answer. Even a long agent session has a clear edge. The session stops. Context decays. The operator has to restart the loop.
A dot is designed around continuity. OpenAI describes it as an agent that keeps making progress between conversations, runs scheduled work, researches proactively, and maintains memory for its ongoing responsibility.
That sounds small until the work spans several days.
My own bottleneck is rarely producing one more draft. It is keeping the state of many moving projects clear: what changed, what passed a check, what is waiting for a decision, and what must not be touched.
An agent that can maintain that state has more value than an agent that only writes faster.
Codex becomes part of a larger operating loop.
OpenAI’s documentation says a dot can use a local computer when the user enables that access. It can create Work or Codex tasks, use local skills, and use a local browser when a cloud browser is blocked. Local access is optional and off by default.
This is the part that interests me most.
Codex is already useful for a defined build: inspect the source, edit files, run checks, and leave evidence. A dot can potentially sit above that work. It can notice that a check is due, create the task, retain the result, and bring the next decision back to me.
The dot does not make the build quality automatic. It changes who keeps the loop alive.
The cloud computer expands both ability and risk.
A dot can work across apps connected to ChatGPT. OpenAI also says it may review connected information proactively and form memories from it.
That is powerful. It is also the reason the first setup should be narrow.
I would not begin with “run my business.” I would begin with one responsibility, one set of sources, and a short list of actions that stay protected.
For example:
Maintain the state of one website or content pipeline. Inspect it, record changes, prepare drafts and checks, and bring decisions back for review. Do not publish, message, purchase, delete, or change access without approval.
That is enough scope to test continuity without handing over every account.
OpenAI gives users rules for this boundary: act without asking, act when pre-approved, ask first, or hand the action back. Those rules are not setup decoration. They are the operating model.
Memory should serve the role.
Persistent memory is useful when it reduces repeated explanation. It becomes a problem when the role has no edge.
A website operator needs the site source, deployment history, domain state, and QA rules. It does not need client mail, payment data, or every unrelated project. A content operator needs the approved source material and publishing checklist. It does not need broad control of the company.
The rule I would use is simple: connect the minimum information required to own the stated result.
OpenAI notes that disconnecting an app does not erase information already obtained from it. Deleting a dot resets its saved memories, conversations, and schedules. That makes review and retirement part of the setup, not something to consider later.
My first test would be deliberately boring.
I would give a dot one low-risk operating lane for 30 days.
It would maintain a current status, run a scheduled check, open a Codex task when work is required, and return a short report with evidence. It could prepare changes. Publication and external communication would remain behind approval.
I would measure four things:
- Did it preserve the correct state across days?
- Did it know when to act and when to ask?
- Did its work remain reviewable and recoverable?
- Did it remove coordination work instead of creating more supervision?
If it passes that test, the next responsibility can be larger. If it fails, the failure should point to a rule, source, or boundary that needs correction.
This is a launch-day thesis, not a review.
I have not run a dot long enough to claim that it delivers reliable autonomous operations. Access is also rolling out gradually, so some eligible accounts will not see it immediately.
OpenAI itself says dots can make mistakes and that important details should be reviewed. Its GPT-6 Astra system card also treats persistent, proactive work and changing permissions as safety problems that need evaluation.
The product claim is clear. The real evidence will be whether a dot can hold a bounded responsibility over time without losing context, crossing a protected line, or quietly lowering the quality of the work.
That is the test I care about.
The official setup guide explains the current rollout, connected apps, local computer access, rules, schedules, memory, and deletion behavior.
All build notes ↗