OpenAI Dots: The Chat Ends, the Work Continues
Persistent agents are designed to accompany bug reports all the way to pull requests. The decisive factor is how teams control context, approvals, and ongoing tasks. Published on 29 September 2026 • AI translated
OpenAI describes Dots as proactive assistants capable of continuing their work even after a conversation has ended. Dedicated cloud computers, browsers, and persistent memory are intended to ensure that tasks and context do not vanish alongside the chat.
For development and operations teams, one aspect stands out in particular: fewer handoffs. A bug report in Slack does not need to be re-explained at every subsequent step if the same agent oversees the investigation, code change, and feedback. Whether this actually saves time in day-to-day operations and functions reliably cannot be substantiated with the available material.
1. Triage bug reports
A Dot is designed to ingest feedback from connected applications and detect recurring errors. The team must define which information the agent is allowed to read and which reports require human attention.
2. Investigate the root cause
The agent is meant to examine failed builds and narrow down potential changes. Shared context can eliminate repetitive explanations. Even so, the diagnosis remains something that must be verified.
3. Submit changes for review
Using Codex, Dots are intended to generate changes, run tests, and return them as a pull request. This serves as preparation for review, not a direct pass to production. Code, test results, and potential side effects must be inspected before merging.
The critical boundary lies between reading and acting. According to the available information, proactive background research is restricted to read-only access within authorized applications. Making changes or sending out information requires appropriate permissions or explicit approval.
This does not mean that every single write operation must be manually confirmed. Custom rules can permit actions, require prior approval, or mandate a confirmation prompt. Setting up such rules means distributing operational leeway. That is an operational decision, not a trivial setting.
Memories require boundaries as well. Dots can draw on context from ChatGPT and their own stored notes, which remain effective across multiple channels. Teams must therefore clarify what can be stored, who has access to it, and how obsolete decisions can be corrected or deleted.
The described deletion options carry consequences: according to the available documentation, removing a Dot's own stored memories requires a full reset. Doing so also deletes its conversations and scheduled tasks. Persistent context is valuable, but maintaining it comes at a cost.
And then there is the stop button. Halting an assignment does not undo actions that have already been executed. The material does not clearly indicate whether all delegated work and scheduled runs terminate immediately.
For deployment in production systems, simply showing "paused" is not sufficient proof of safety. Administrators must be able to see what is still running, what has already been modified, and where a task was only partially completed. The described safeguards do not replace this oversight, especially since Dots can still make mistakes despite approval rules.
For Switzerland, an additional practical limitation applies: according to current launch details, Dots for Pro will initially not be available here. Enterprise is expected to be available globally once workspace administrators enable its rollout.
Fewer handoffs, not less responsibility
Dots could shorten the path from a bug report to a reviewable pull request. A sensible starting point is a bounded workflow with clear read permissions, verifiable approvals, and visible task statuses. An agent should only be allowed to work persistently if the team can also persistently trace what it is doing.