OpenAI Dots Agents Explained: Always-On ChatGPT Agents

Most AI agents still stop when the chat window closes. OpenAI Dots agents are built not to. Announced at DevDay 2026 in San Francisco on 29 September, a dot is a persistent ChatGPT agent powered by GPT-6 Astra that has its own cloud computer and browser, connects to the apps you approve, and keeps working towards the goals you set while you are doing something else.

This post separates what OpenAI has actually published, in its announcement, its safety write-up and two Help Center articles, from what launch-week coverage reported. It then looks at dots the way an engineer should: how they differ from a chat or a Codex task, which controls are real, and how a business with an ERP back-office could pilot one without handing it the keys.

What OpenAI Dots agents are, in OpenAI's own words

OpenAI describes dots as remarkably capable, always-on agents built to handle everything. Stripped of the slogan, the announcement commits to four concrete properties:

• Model and machine: each dot is powered by GPT-6 Astra and works from its own cloud computer and browser, which you can open at any time to inspect its work.
• Reach: through OpenAI's plugin ecosystem a dot can connect to over 4,000 apps, using the same plugin permissions you already granted to ChatGPT, ChatGPT Work and Codex.
• Persistence: a dot learns from feedback, carries context across every channel, runs several projects at once without separate threads, and works towards your goals 24/7.
• Surfaces: you message or call a dot in ChatGPT on desktop, web and mobile, and message it in Slack and Microsoft Teams. Texting is described as coming soon.

Getting one is deliberately narrow at launch. You create your first dot in the ChatGPT desktop app or a desktop browser, give it a name and connect apps; only after that initial setup can you message it from the mobile app. OpenAI calls this your primary dot, says it envisions teams of dots working together later, and is previewing specialist dots for organisations.

Confirmed facts versus launch-week reporting

Launch coverage moved faster than the documentation, and several claims drifted. The table sets OpenAI's published wording against what outlets reported, so you know which details are safe to plan around.

The pattern is consistent: coverage rounds up. Channels that are coming soon get reported as live, metered work gets reported as free, and a future vision of dot teams gets reported as a shipped feature. When a detail drives a decision, trust the Help Center wording over the headline.

How a dot differs from a chat, a Codex task and an Agents API session

The useful mental model is ownership of time. A chat answers while you are present. A Codex Cloud task runs in an isolated environment and then finishes. A dot holds a goal open indefinitely and decides for itself when there is something worth doing.

For developers this matters because a dot is a product, not a primitive. OpenAI announced no dots endpoint. If you need an always-on agent inside your own system, the DevDay additions to the Agents API, such as computer use and multi-agent orchestration, are the building blocks, and you own the scheduler, the state and the approvals yourself.

The control plane: Custom Rules, Auto-review and handoffs

Dots do not run on a single allow-or-deny switch. OpenAI's safety write-up describes three tiers of built-in action rules, and Custom Rules can only move actions inside the tiers that are not mandatory.

• Always handed back to you: changing a password or transferring money between financial accounts. The dot can prepare the surrounding task, but you complete that step yourself.
• Confirmed every time: permanently deleting data, installing or running software from an unrecognised source, and granting new security-sensitive access.
• Approvable in advance: sending recurring messages, or purchases with a card already saved on a merchant's website, provided the approval specifically covers the action.

Sharing has its own rule. Authorisation must cover both the information and the type of recipient: health data always needs a named recipient, while less sensitive data such as an email address defaults to a class of recipient, such as any airline, which a Custom Rule can widen. That authorisation stays tied to the task; continuing later or delegating work does not expand it.

Before an action such as sending an email or changing a file, a separate system called Auto-review checks the planned step against your instructions, your Custom Rules and OpenAI's safety requirements. If it blocks, it tells the dot why, and the dot asks you, tries a permitted alternative, hands the step back or stops. The enforcement sits outside the environment the dot can change, so the dot cannot switch the check off. Writing your rules down before you open the settings screen keeps them deliberate:

# dot-rules-worksheet.yaml: a planning sheet for ONE dot.
# NOT an OpenAI config format. Transcribe it into Custom Rules by hand,
# so every rule is a decision someone made, not a default nobody read.
dot: finance-assistant
owner: ar-team-lead@example.co.id
connected_plugins:            # read-heavy, and nothing the job does not need
  - accounting-mailbox
  - shared-drive/ar-reports

allow_without_asking:
  - read: accounting-mailbox, shared-drive/ar-reports
  - draft: payment-reminder emails      # drafting is not sending

require_approval:
  - send: payment-reminder emails       # every batch, until trust is earned
  - share: customer statements          # name the recipient, not "anyone"

block:
  - send: any email to a domain not already in the thread
  - share: anything from the payroll folder

# Built in by OpenAI, whatever you write above:
#   change a password, transfer money       -> handed back to a human
#   permanent delete, unrecognised software,
#   new security-sensitive access           -> confirmed every time
#   proactive research                      -> read-only, enforced in code

The worksheet is a planning document, not an OpenAI file format: you enter the result through Custom Rules in settings. A dot can help draft rules, but it needs your approval to change them, and no rule can remove a mandatory confirmation or handoff.

Proactive research and the prompt-injection problem

The feature that makes a dot feel always-on is proactive research. When you are not working with it, the dot starts background tasks that read permitted connected sources and save private notes for itself. OpenAI says the limits are enforced in code: research tools cannot send messages to other people, change content in connected apps or control a browser or computer, and any follow-up action goes through the normal rules and Auto-review.

That split is a sensible answer to the obvious attack. An always-on agent that reads your inbox will eventually read an email written to manipulate it. OpenAI's Help Center is candid here: its protections, including teaching the dot to distinguish your instructions from content it encounters, reduce the risk of malicious instructions causing an unwanted action but do not eliminate it.

What workspace admins can switch on and off

For Enterprise workspaces, OpenAI's admin article lists four dots permissions, and three of them are documented as off by default. That default is the most important fact for an IT team: nothing happens until someone opts in.

Separate cloud computer capabilities, namely cloud browser use, cloud network access and cloud computer use, plus a distinct password manager control, apply to dots and Work Cloud tasks alike, even when Work is disabled. Two details catch teams out. A dot's cloud computer does not inherit a member's VPN, browser sign-ins or device policies, so intranet systems behind a VPN are simply out of reach. And disabling custom rules does not make every action require approval, because the default action rules still apply.

Where dots fit in an ERP back-office, and where they do not

OpenAI's own examples point at back-office work. An early tester's dot noticed a forgotten invoice, prepared it and sent it after approval, and the specialist dots preview builds on internal testing across procurement, invoice processing, email marketing, customer support and commercial contracting. Specialist dots get their own identity, credentials and access to a company's systems of record, start as focused enterprise pilots run with OpenAI engineers, and are being integrated with Microsoft Agent 365 for governance.

Consider a mid-sized Indonesian distributor that runs its finance on an ERP. A personal dot fits the work around the ledger: watching the AR mailbox, drafting payment reminders in each customer's register, turning an exported aging report into a summary for the Monday meeting. It fits the ledger itself poorly. Posting journals, releasing payments and changing vendor bank details are exactly the actions the built-in rules hand back or confirm, and they belong in the ERP's own approval workflow, where the audit trail lives.

Data handling deserves the same scrutiny. A dot retains context from conversations and plugins for as long as the dot exists. You cannot currently view, delete or edit individual dot memories, disconnecting a plugin does not remove what the dot has already learned, and the only way to clear its context is to delete the dot. Business, Enterprise and Edu content is not used for training by default; on personal plans the Improve the model for everyone setting decides. For a company bound by Indonesia's personal data protection law, connecting a dot to customer data is a decision for whoever owns compliance, not a toggle to flip during a pilot.

How to pilot a dot in the first month

The included allowance has extended limits for the first month after launch. That makes the first month the natural pilot window, and also a misleading one for estimating long-run cost. A disciplined pilot looks like this:

1. Pick one recurring, read-heavy responsibility with a clear owner, such as daily AR follow-up or a weekly supplier price-change digest, and write down what good output looks like.
2. Connect only the plugins that responsibility needs, read-only where possible, and fill in the rules worksheet before you open Custom Rules.
3. Keep every send, share and edit behind approval for the first two weeks, and review the steps in Activity View rather than only the final result.
4. Log every approval and rejection. A falling rejection rate is the evidence for loosening a rule; one unexplained action is the evidence for deleting the dot and its context.
5. At month end, weigh the hours saved against the Codex or ChatGPT Work usage the dot consumed, because delegated work counts towards normal limits.

If the pilot holds up, the next question is whether the responsibility should stay with a personal dot or move to a specialist dot with its own identity, which is where OpenAI is steering organisational use.

Dots change who holds the goal. A chat waits for you; a dot keeps the goal open, reads your connected apps in the background and acts within rules you can inspect. Treat one like a new colleague with read access on day one: write its rules down, keep consequential actions behind approval, and widen trust only on evidence.