OpenAI’s dots combines persistent project work with user-managed app access, review, and the ability to pause or redirect the agent. That makes the practical test less about a connector count and more about whether people can safely delegate real tasks.
Summary
OpenAI presents dots as a ChatGPT agent that can continue project-oriented work between conversations using memory, Codex, and connected tools. Users choose which apps it can access, can inspect work and change direction, and may need to approve actions that affect accounts or share information through an Auto-review flow. The product page describes intended capabilities, not independent performance results; its excerpt does not verify the discovery post’s claims of 4,000 connectors or universal messaging access. The consequential design choice is to make access and approval part of delegation itself.
What happened
The official dots page describes agents running on their own cloud computers and carrying project work forward between conversations. Users can choose which connected apps the agent may access, set Custom Rules, review details, provide feedback, change direction, or pause it. OpenAI says actions that could affect accounts or share information pass through Auto-review, with some requiring approval. The page says dots uses ChatGPT memory, Codex, and connected tools, and is powered by GPT-6 Astra; that is OpenAI’s product description, not an independent capability assessment. The source excerpt does not establish a supported connector count, broad messaging availability, or public API endpoints for configuring approvals. Its illustrative workflows therefore show the intended product shape, not verified reliability in deployment.
What the archive adds
The archive shows that always-on assistants have also been explored outside this announcement. Its Hermes Agent item describes a self-hosted assistant for a VPS or local machine, with messaging connections and scheduled tasks; its Clawdbot item describes a local-first assistant with a Gateway architecture and familiar messaging channels. These are different deployment choices, not evidence that dots has equivalent features or that any one approach has solved safe delegation. The archive’s DevDay 2026 recap also places dots within OpenAI’s own product coverage, but adds no independent performance evaluation.
Trend signal
Agent products are moving from answering a prompt to retaining work, using tools, and returning for review. That shift changes the engineering problem: capability is only useful when the system can determine which data and actions are in scope, and when a person can understand and interrupt what is happening. Traditional identity and access management grants permissions to people and services; an agent adds a harder question of how to bind a permission to a particular task, duration, and consequential action. Dots makes that governance problem visible in the product interface rather than treating tool access as an invisible implementation detail.
Why now
Three drivers are plausible, with different evidence strength. First, the archive shows prior public clues about an always-on OpenAI agent: surfaced build strings about the Dots name (finding d1) and a report anticipating an always-on agent at DevDay (d2), suggesting product development and positioning predated this page. Second, according to the Axios report summarized in finding d3, dots launched as a competitive response to Meta’s Muse; this is a reported causal account, not confirmation from OpenAI. Third, the product page itself bundles persistent work, connected tools, and explicit review controls, suggesting OpenAI sees permission management as necessary to make delegation usable. The dossier does not substantiate a safety-related rollout halt or establish that GPT-6 Astra specifically enabled persistent agents.
Connections to other events
The hidden constraint is not simply whether an agent can reach an app; it is whether its access remains legible and appropriately narrow while work persists between conversations. Dots’ app selection, Custom Rules, review controls, and Auto-review approval path are OpenAI’s stated answer to that problem. Compared with familiar IAM systems such as Azure AD or Okta, which govern identities and resource access, delegated agents also need task-level boundaries, understandable action previews, and a way to pause ongoing work. That comparison is an engineering inference, not a claim that dots integrates with either system or exposes an API for these controls.
Why it matters
Builders should treat permission UX and auditability as core workflow features: distinguish reading from writing, limit access to the task, show consequential actions before execution, and make interruption easy. Buyers should test whether people can predict what an agent is authorized to do and whether approvals arrive at useful moments, not just whether a demo completes a task. For teams with existing IAM, dots does not remove the need to map organizational access policies onto agent actions; the product page excerpt does not explain how that mapping works. A permission prompt that users cannot interpret will either slow work or invite habitual approval.
What happens next
- We expect OpenAI’s public dots materials to clarify supported integrations or availability before the broad connector claims become dependable planning assumptions. (3 months, 65%). Watch for: An official page or release note listing supported integrations or concrete availability details.
- We expect the next wave of discussion about dots to focus on approval friction and user control, not only task demonstrations. (6 months, 60%). Watch for: Product updates, user reports, or enterprise evaluations that describe Auto-review behavior, approval rates, or pause and review controls.
- We expect persistent-agent evaluations to include permission scope and interruptibility alongside task completion. (12 months, 55%). Watch for: A published evaluation or buyer checklist that measures authorization boundaries or human approval alongside task outcomes.
Limits and uncertainty
This take rests on OpenAI’s product page, which describes intended design and illustrative workflows rather than independent results. The excerpt does not disclose a verified connector inventory, general availability details, team-level administration, or API endpoints for building approval flows. The research dossier’s Axios finding says OpenAI launched dots as a competitive response to Meta’s Muse, but that is a reported explanation of timing, not proof of internal motive. The page also does not establish how often Auto-review intervenes, how users experience the friction, or whether the controls prevent mistakes in sustained use. If those controls are cumbersome or opaque, persistence may increase oversight burden rather than reduce it.
Skill to build now
Practice task-scoped authorization. First exercise: for an agent handling a weekly project update, make a four-row matrix—read project files (allow), draft a message (allow), send the message (approval required), share files externally (deny unless explicitly re-authorized). Add an expiry and a stop condition, then ask a colleague to decide from the action descriptions what should require approval. This tests the permission design without assuming dots exposes a custom schema or API.
Reader takeaway
This week, map one real delegated workflow into a permission table before connecting an agent: list the data it may read, actions it may take, actions needing approval, and a clear stop condition. Test whether a reviewer can understand each proposed action from its preview. Do not plan around the discovery post’s 4,000-connector figure until OpenAI publishes a verified supported-integration list.
Open question
Can a persistent agent make approval requests specific and understandable enough that users remain attentive, rather than clicking through prompts until the oversight layer becomes ceremonial?