OpenAI Dots are always-on agents in ChatGPT that can own an ongoing responsibility instead of waiting for a fresh prompt every time. A dot gets its own cloud computer and browser, can work with connected apps through plugins, can delegate work to ChatGPT Work or Codex, and can keep producing files and results for review.

The important distinction is continuity. A normal chat helps with a request. A dot is configured around a standing job such as monitoring a market, preparing a recurring report, organizing an inbox workflow, or coordinating research and implementation across tools.

Dots are rolling out gradually. Availability, included capacity, plugins, and administrator controls can differ by plan and workspace. Check the current ChatGPT product interface and official Dots documentation before designing a business process around them.

What an OpenAI Dot is

A dot is an agent with an ongoing responsibility, instructions, resources, and a place to work. It can use a cloud-hosted browser and computer, interact with connected applications where permitted, create files, and surface work for human review.

That makes Dots closer to a persistent digital worker than a saved prompt. The system can continue a defined responsibility across sessions and can hand specialized tasks to other OpenAI work surfaces. It is still bounded by available tools, permissions, approvals, and the quality of the instructions and data it receives.

OpenAI describes built-in safeguards, app permissions, approval flows, and custom rules. These controls matter because an always-on agent can encounter sensitive data and consequential actions repeatedly rather than during one isolated conversation.

Dots vs ChatGPT tasks and ordinary chats

An ordinary ChatGPT conversation is user-led. You ask, the model responds, and you decide what happens next. A scheduled task automates timing, but it is usually a bounded prompt executed on a schedule.

A dot is designed around ownership of a responsibility. It can gather information, work through multiple steps, use a browser or connected apps, delegate specialized work, and return an output for review. The goal is not merely to run the same prompt every Monday. The goal is to maintain enough continuity to handle a recurring operational outcome.

For simple reminders or deterministic reports, a scheduled task may remain easier to understand and audit. Use a dot when the work genuinely needs ongoing context, tool use, judgment, and multi-step execution.

Dots vs ChatGPT Work

ChatGPT Work is an AI-native work environment for carrying out tasks with business context and connected tools. Dots add an always-on ownership layer inside ChatGPT. A dot can delegate work into Work when a responsibility requires a more involved execution task.

This does not mean every Work task should become a dot. One-off analysis, drafting, and project execution remain good direct Work use cases. A dot makes more sense when the same business responsibility continues over time, such as collecting competitive updates, preparing a weekly operating brief, or checking whether a recurring process needs attention.

Dots vs Codex

Codex CLI is specialized for software engineering. It can inspect repositories, edit code, run tests, and work through implementation tasks. A dot can delegate a coding task to Codex, but the dot itself is not a replacement for the coding harness.

Think of the dot as the owner of the recurring outcome and Codex as a specialist that may execute a software change. For example, a dot could monitor documentation changes, identify a required SDK migration, and delegate the repository update. A human should still review the proposed change, test evidence, and deployment impact.

Cloud computer and browser

Each dot can use its own cloud computer and browser. This allows it to navigate web applications and complete browser-based work without taking over the user’s active device. Some workflows may also use an optional local computer when enabled and appropriate.

Browser access expands what an agent can do, but also expands risk. A browser session can expose authenticated accounts, customer information, financial data, or irreversible controls. Use separate least-privilege accounts where possible, require approval for consequential actions, and avoid giving a monitoring dot permissions it does not need.

For builders creating similar behavior in an application, compare the managed OpenAI Agents API and the broader AI Application Architecture hub. Dots are the ChatGPT product experience; the Agents API is the programmable infrastructure choice.

Connected apps and plugins

Dots can use connected applications through plugins, subject to available integrations and user or administrator permission. A useful plugin gives the dot a defined set of actions rather than unrestricted access to an entire account.

The safest design starts with the minimum data and actions required. Separate read access from write access. Keep deletion, payments, publishing, access-control changes, and external messages behind explicit approval unless the workflow has been carefully bounded and tested.

Connected apps do not guarantee that an agent understands a business policy. Encode important constraints in instructions and custom rules, then validate them with realistic failure cases. The AI Security hub covers API keys, OAuth, secrets, permissions, and agent credentials in more depth.

Good use cases for Dots

Dots fit responsibilities with recurring inputs, clear outputs, and a reviewable definition of done:

• Monitor a set of vendors and prepare a weekly change brief.
• Collect project updates from connected sources and draft a status report.
• Review a queue for missing information and prepare follow-up actions.
• Track a research topic and organize verified findings with source links.
• Coordinate recurring content maintenance without publishing automatically.
• Watch a technical dependency and delegate a migration task when evidence is strong.

The strongest use cases are not vague requests to “run the business.” They have narrow scope, explicit sources, clear escalation rules, and an output a person can check.

Weak or risky use cases

Avoid giving a new dot broad authority over payments, account deletion, production deployment, legal decisions, hiring, or unsupervised customer communication. These activities combine high consequence with context that may be incomplete or ambiguous.

Also avoid using a dot where a deterministic automation would be safer. If a fixed rule can move a record between two systems reliably, an automation platform or small program may offer better predictability, observability, and cost control.

A dot should not be treated as an infallible background employee. It can misunderstand a page, follow a stale instruction, encounter a changed interface, or produce a plausible but incorrect summary. Approval controls and review are part of the product design, not optional cleanup.

How to set up a dot safely

Start with one responsibility and write a measurable outcome. Define the sources it may use, the applications it may access, the actions it may take, and the situations that require approval or escalation.

Then run the workflow on historical examples. Include missing data, conflicting instructions, login failures, changed web pages, and cases where the correct action is to do nothing. Review outputs before increasing permissions or frequency.

Use named rules for sensitive boundaries. Record which accounts and plugins the dot can access. Revisit permissions when a team member changes role or an integration gains new capabilities. For production agent controls, see OAuth for AI agents and MCP servers and managing AI API keys and secrets.

My take

Dots make the most sense as a coordination layer for recurring knowledge work. The cloud computer, browser, connected apps, and delegation paths can remove a great deal of manual handoff. The value depends less on calling the agent “always-on” and more on whether the responsibility is narrow, observable, and safe to repeat.

Start with read-heavy workflows and reviewable deliverables. Add write permissions only after the dot behaves reliably on representative cases. A well-designed dot can own a queue; it should not quietly own every decision around that queue.

FAQ

What is an OpenAI Dot?

An OpenAI Dot is an always-on agent in ChatGPT that can own an ongoing responsibility, use a cloud computer and browser, work with connected apps, delegate tasks, and return results for review.

Are Dots the same as scheduled ChatGPT tasks?

No. A schedule controls when a task runs. A dot is designed to maintain responsibility across ongoing, multi-step work, although timing can still be part of its workflow.

Can Dots use Codex?

OpenAI documents delegation from Dots to Codex and ChatGPT Work. Codex remains the specialized software-engineering environment rather than becoming the dot itself.

Can a Dot use my apps and accounts?

It can use supported connected apps through plugins when permissions allow. Limit access to the minimum required and keep consequential actions behind approvals.

Are OpenAI Dots available to everyone?

Dots are rolling out gradually, and availability can vary by plan, workspace, administrator policy, and region. Check the current product and official documentation for access.