Most AI assistants disappear operationally when the conversation stops. OpenAI’s Dots are designed around the opposite idea: give an agent a continuing goal, let it work in its own cloud environment and have it return when it needs input or has something useful to report.2
OpenAI’s Dots are positioned as always-on agents that can keep pursuing goals across connected applications rather than waiting for a new prompt each time. That changes the operating model: persistence, app permissions, background work and approval boundaries become central product features. Early availability and reliability still limit what can be concluded from launch-day demonstrations.1, 2
| Prompt-response assistant | Always-on dot |
|---|---|
| Waits for the next user message | Can continue pursuing an assigned goal |
| Works inside the current interaction | Can operate in a persistent cloud environment |
| App access is invoked for a task | Connected-app permissions become an ongoing control boundary |
| Completion usually ends the interaction | Monitoring and follow-up can continue over time |
Persistence is the product change
A persistent agent can notice that a dependency changed, revisit a task and continue work without reconstructing the entire assignment from scratch. That makes memory and state operational rather than merely conversational.2
What Dots add to the assistant model
Permissions matter more when the agent keeps working
A one-off assistant can ask for access at the moment it needs a tool. A persistent agent makes the permission boundary longer-lived. Users and organizations therefore need to know which apps it can reach, which actions require approval and how to stop or change the work.2
Background work changes the failure mode
A bad answer in a chat is visible immediately. A background agent can instead take a sequence of steps before the user returns. That makes logs, approvals and reversible actions more important as the system becomes more autonomous.
Four controls to watch
- Which connected applications and data the dot can access.
- Which actions require an explicit approval before execution.
- How the user can inspect what the dot did while working in the background.
- How persistent goals, memory and permissions can be changed or stopped.
Launch-day capability is not reliability evidence
OpenAI’s announcement establishes the product architecture and intended controls. It does not establish error rates across every connected application or prove that unattended work is appropriate for every consequential task. Those questions require operational evidence after deployment.2
The shift is easy to summarize: chatbots wait, persistent agents continue. If that model works reliably, the important interface may become less about what you ask an assistant right now and more about which goals you are comfortable leaving with it.
Sources and methodology
Sources checked September 29, 2026. Dates and periods for individual figures are stated beside them.
- OpenAI API: Agents guide ↗Accessed 2026-09-29
- The Next Web: OpenAI launches Dots always-on agents ↗Accessed 2026-09-29
Scope and assumptions
Dots are newly launched, so availability and product behavior can change quickly.
Launch materials establish intended capabilities and controls, not real-world reliability across every connected application.
Continue reading
Meta’s AI Can Send Emails and Make Purchases. What Should You Let It Touch? →
86% Agreement Can Still Miss Half the AI Failures →
70,000 Employees Use Salesforce’s Internal AI Agent. The Hard Part Was Cleaning the Knowledge Base →