<MT />
Back to Blog
ai-agentsopenaichatgptsecuritybuildersproductivity

OpenAI’s Dots: What Builders Should Enable, Gate, and Monitor With Always-On Agents

T

Muhammad Tayyab

September 30, 2026·11 min read
Programmer coding at a desk with several monitors in a night workspace with RGB lighting — always-on AI agents

OpenAI’s Dots keep working after chat ends. A practical builders checklist for permissions, connected apps, approval gates, and monitoring.

At DevDay on 29 September 2026, OpenAI shipped Dots: always-on agents with their own cloud computer, a browser, and hooks into thousands of connected apps. The pitch is not “a smarter chat reply.” It is an agent that can keep researching, drafting, coding via Codex, and nudging you after you close the thread.

That is the product shift founders and builders need to design for. When the agent keeps working overnight, the real product surface is no longer the conversation—it is what you enabled, what still needs your say-so, and how you notice when it drifted.

This guide is a practical enable / gate / monitor checklist. It is not a feature dump, and it is not a security incident walkthrough. Treat it as the ops layer you should set before you let a Dot sit next to Slack, email, or your laptop.

What Dots actually change

Per OpenAI’s Introducing dots post, each Dot runs on GPT-6 Astra, gets a dedicated cloud machine, and can use plugins to reach more than 4,000 apps. You can message or call it in ChatGPT, reach the same agent in Slack or Microsoft Teams, and (soon) text it. Context is meant to travel with the agent across those channels.

Two details matter more than the mascot UI:

  1. Persistence. A Dot can run multiple projects and keep going when you are not in the chat. When idle, it may do proactive research—looking for useful updates using read-only tools only (no sending messages, no changing app content, no driving a browser or computer in that mode).
  2. Separation by default. The cloud computer is inspectable and separate from your laptop unless you explicitly connect local access. That is a better default than “share my whole desktop,” but the plugins and memories you attach still define blast radius.

Rollout at launch: Pro and Business Premium in eligible markets (with regional caveats—Pro access was reported as limited outside the EEA, Switzerland, and the UK at start), one included Dot, Enterprise/Edu/Healthcare as admin-gated beta. Conversations with the Dot do not burn ChatGPT message limits; work it kicks into Codex or ChatGPT Work still counts.

Dots vs Muse (agent model, not a security postmortem)

Meta’s Muse landed a few weeks earlier as a consumer-leaning personal agent: plans, forms, shopping, travel, a dedicated app/WhatsApp surface, and its own secured cloud VM. Dots sit closer to work continuity—ChatGPT plus Slack/Teams, research and document loops, Codex for software, and (for companies) a preview of specialist dots with provisioned identity and systems access.

Both products sell the same structural idea: an agent with a computer that keeps going after you leave. If you already evaluated Muse as a product shape, Dots is OpenAI’s answer in that category—with a different home surface and a heavier workplace skew. For a security-oriented Muse checklist, see the earlier post on this site; this piece stays on how to operate an always-on agent day to day.

Builders checklist: enable, gate, monitor

Use this as a go-live pass. Defaults are not a strategy.

1. Permissions: start narrow, remember they are shared

Plugin permissions apply across Dots, ChatGPT, ChatGPT Work, and Codex (privacy & safety FAQs). Granting a write-capable email or CRM connection for “one chat experiment” also arms the always-on agent.

Do:

  • Audit the Plugins tab before creating a Dot.
  • Prefer read scopes for research, calendars, and analytics.
  • On Enterprise, treat workspace toggles as a control plane: Use dots is off by default; so are local computer access and custom rules until an owner turns them on (workspace admin guide).

Don’t:

  • Flip on broad “send / edit / delete” plugins because a demo looked cool.
  • Assume disconnecting a plugin erases what the Dot already absorbed—OpenAI is explicit that disconnect stops new access; prior context can remain until you delete the Dot (or manage ChatGPT Memory separately).

2. Connected apps: map write paths before you map ideas

Connected apps are how Dots become useful—and how quiet mistakes become public. OpenAI’s own examples include drafting an invoice from an email thread and sending it after approval, or watching feedback and preparing PRs. Those workflows only stay safe if write destinations are intentional.

Prioritize connections in this order:

  1. Read-only sources the Dot should watch (docs, tickets, analytics, calendar).
  2. Draft destinations you will always review (docs, PR drafts, staging).
  3. Outbound messaging (email, Slack, Teams) only with hard approval rules.
  4. Anything that moves money, rotates credentials, or touches production last—or never.

Slack/Teams deserve a special note: enabling channel presence means the Dot can post with its own identity, and channel members can see those messages. Only the Dot’s owner directs it; other people’s DMs do not start work. Still, a visible agent in a shared channel is an organizational surface, not a private notepad.

3. Approval gates: Custom Rules + Auto-review are the product

Dots ship with defaults for independent action vs confirmation. Custom Rules let you allow, require approval for, or block supported actions. They cannot override core takeovers (for example, changing a password), Auto-review, or the read-only limits on proactive research.

OpenAI’s ladder is useful to internalize:

  • You take over: password changes, transferring money, and similarly sensitive steps.
  • Approve each time (or carefully in advance): installing software, permanently deleting data, purchases with a merchant-saved card, some messaging patterns.
  • Advance approval is scoped: approving one message is not a blank check to contact people forever. Be specific—who, what, when.

Practical rule for founders: write Custom Rules before the first overnight run. Examples worth encoding early:

  • Never send email or calendar invites without approval.
  • Never merge to main / deploy / change billing without take-over or explicit approval.
  • Allow drafting docs and PRs autonomously; require approval to publish or open externally.

Auto-review sits in front of actions that can affect accounts or share information (OpenAI cites checking email recipients and body before send). Treat it as a seatbelt, not a chauffeur. OpenAI’s own line is blunt: Dots can still make mistakes—always review consequential work.

4. Monitoring: Activity View is part of the job

Always-on without inspection is just unattended automation with better branding.

Build a habit:

  • Open Activity View in the desktop app for ongoing and delegated tasks.
  • Periodically open the Dot’s cloud computer while it works—same as glancing at a contractor’s screen share.
  • Watch Codex / ChatGPT Work usage separately; those tasks still consume plan limits.
  • On personal plans, review whether “Improve the model for everyone” is on; Business/Enterprise/Edu default to no training on workspace content.

Enterprise operators should also review cloud capabilities (browser, network, computer use, password manager) independently of “Use dots.” The cloud machine does not inherit a member’s VPN or browser sessions—sign-ins on the agent machine are their own policy problem.

5. What not to leave always-on

If you only remember one section, make it this.

  • Leave gated or off — Why
  • Broad email / SMS send — Proactive research is read-only; task mode is not. Wrong recipient + confident tone is a classic failure mode.
  • Payment methods & purchases — Approval exists; advance approval for purchases is easy to over-scope.
  • Local computer access — Off by default on Enterprise for a reason—files, shell, camera/mic/screen expand the trust boundary.
  • Production credentials & deploy keys — Prefer draft PRs and staging; keep production as take-over.
  • Unscoped Slack/Teams posting — Shared visibility + autonomous drafts = brand and compliance risk.
  • Memory + training without review (personal) — Dot ↔ ChatGPT memory sharing is bidirectional until you turn Memory off.

Proactive research is fine for “watch this inbox / calendar / dashboard.” It still means the agent may pull more of your connected world into private notes and later conversations. Enable the watch list deliberately.

A sane first week with Dots

  1. Create the Dot on desktop/web, name it, connect two or three read-only apps only.
  2. Write Custom Rules for send / publish / spend / delete.
  3. Run one bounded project (research brief, draft docs, staged PR)—not “run my company.”
  4. Check Activity View twice a day for three days; open the cloud computer at least once.
  5. Only then add a single write path with mandatory approval.
  6. If you use Slack/Teams, start in a private channel or DM-style surface before any company-wide channel.

That sequence is boring on purpose. Persistent agents reward boring ops.

Soft close

Always-on agents are no longer a lab demo. With Dots, OpenAI put a cloud computer and a plugin graph behind a teammate-shaped interface. The builders who get leverage will be the ones who treat permissions, connected apps, approval gates, and monitoring as first-class product decisions—not afterthoughts.

If you are wiring agents into a real product or team workflow and want a second set of eyes on the enable / gate / monitor design, get in touch.

About the author

Muhammad Tayyab builds consumer and AI products, including DripScore and projects under dawnapps.co. He writes for founders and builders shipping AI-native apps—practical systems, not hype decks.

Sources

Back to all posts
Thanks for reading 🙏