What Is OpenAI’s Dot Doing When You’re Not Prompting It?

OpenAI describes dot as an always-on assistant that can pursue goals, research connected information, and work across projects around the clock. That promise also raises practical questions about what runs in the background, what information is gathered, and how users can retain meaningful control.

In reviewing OpenAI’s product description alongside testing reported by AI governance company Geordie, I found a clear theme: dot is designed to take initiative. Users should approach it as a persistent, connected system with its own activity cycles, permissions, records, and resource use. The available public reporting answers part of the picture, while several important details about data retention, token billing, and background-agent controls remain unclear.

OpenAI introduced dots in September 2026 as proactive assistants powered by GPT-6 Astra. A dot has a cloud computer and can keep working toward a goal 24/7, according to OpenAI. It can carry context between ChatGPT, Slack, and Teams and can connect through plugins to thousands of applications.

That architecture gives dot a different operating pattern from a standard chat session. After I give it a goal, relevant context, and access to selected services, it can research, organize material, check on work, and prepare follow-up actions during periods when I am not sending messages. OpenAI presents this as a way to move complex projects forward without requiring a new prompt for every step.

The degree of activity will depend on the goal, connected apps, rules, available context, and service limits. I would assume that any persistent assistant can create a larger operational footprint than a one-off chat because it has time, access, and an incentive to keep gathering useful context.

OpenAI’s dot is built to operate beyond a normal chat session: it has a cloud computer, can work toward goals around the clock, and can use approved connected applications. Geordie’s testing illustrates what that autonomy may look like, reporting 155 activity traces and more than 300,000 tokens of use in roughly a day even in a read-only environment. The central issue is not that background work is inherently harmful, but that persistent agents require equally persistent oversight of permissions, data collection, actions, costs, and measurable value.

OpenAI says that content from Business, Enterprise, and Edu users is not used for model improvement by default. Personal users can control the corresponding data-use setting. That addresses one major data-governance question, though users should review the current setting within their own account and read the applicable privacy terms before connecting sensitive material.

A model-training preference and a data-retention setting address different issues. Training controls concern whether content may contribute to improving models. Retention controls concern how long content, logs, journals, files, and other records remain available within the service. Access controls determine which connected systems dot can read or use. I would review all three areas, because each governs a different part of the data lifecycle.

For highly sensitive material, I would also consider whether the task needs an always-on agent at all. Confidential client records, credentials, regulated data, private source code, and personal financial information call for a specific review of organizational policy, contractual requirements, and the agent’s available controls.

Geordie’s 300,000-token finding measures model usage in a test; it does not establish a universal bill charged directly to every dot user. Geordie estimated that about 200,000 Astra tokens could cost roughly $5 to $10 under certain assumptions, while emphasizing that token costs vary by location, subscription tier, commercial discounts, and other terms.

OpenAI’s getting-started information says a first dot is included at no additional cost and includes an allowance for deeper work, with extended limits during the first month. It also says dot conversations do not count against ordinary ChatGPT usage limits, while Codex and ChatGPT Work tasks have separate treatment. That describes availability and allowances, rather than a public, universal per-token invoice for autonomous background activity.

The materials provided here do not spell out a user-configurable dollar cap, a per-dot token ceiling, a real-time burn-rate alert, or a billing guarantee that stops background work at a chosen spending threshold. I would avoid assuming that an included allowance equals unlimited background compute. Before relying on dot for sustained work, I would check the current plan terms, usage dashboard, administrative settings, and any notices that describe what happens when deeper-work allowances are exhausted.

The right mental model is not a chatbot that happens to be available overnight; it is a junior digital operator with continuous access to a defined workspace. Its initiative can be valuable when the goal, data boundary, and approval rules are clear. But convenience should not substitute for governance: users and organizations should demand understandable activity records, least-privilege access, rapid revocation, and a clear connection between background compute and a useful result.

OpenAI says users choose which applications their dots can access. Its Custom Rules can permit, pre-approve, require approval for, or block actions. OpenAI also says proactive research through connected apps uses read-only mode, local-computer access requires opt-in, and action review plus safety monitoring can pause or stop risky work.

Those controls create a useful starting point. I would use read-only access during an evaluation period and grant only the minimum data sources necessary for a defined goal. I would set approvals for consequential actions, including sending messages, changing records, running code, making purchases, or sharing files. I would also create rules that explicitly block credentials, payment methods, sensitive repositories, human-resources data, and personal communications unless a specific project requires them.

The Geordie report highlights an open visibility issue: a user may not realize that sub-agents are active, what tasks they received, or what inherited access they used. Public details supplied here do not establish whether dot offers a complete live sub-agent dashboard, a per-sub-agent approval screen, or a detailed export of every background tool call. I would look for activity history and audit-log functions in the product, then use a restricted test workspace if granular visibility is unavailable.

Based on Geordie’s description, dot can gather data points from the systems and access permissions available to it and collect them into a continuously updated journal-like record. OpenAI says dots can retain context across channels and use connected applications to work toward goals. Together, those capabilities suggest that the working record may include project facts, documents, task status, application metadata, research findings, feedback, and prior conversation context.

The exact contents will depend heavily on what I connect. An assistant with access only to a project folder sees a limited working environment. An assistant connected to email, calendars, chat systems, documents, repositories, and business applications can potentially assemble a far broader picture of my work, relationships, schedule, and organizational activity.

Public material summarized here does not specify a field-by-field schema for dot’s journal, its physical storage location, its retention period, or whether users can selectively delete individual journal entries. It also does not clearly describe whether a user can view the entire evolving profile as a single exportable record. Those are important questions for OpenAI to answer with product documentation and controls.

Until those details are clear, I would connect data sources gradually. I would start with a narrow, low-sensitivity project and inspect the assistant’s resulting summaries and activity history before providing access to broader systems.

Organizations should expect consumer-style agents to enter the workplace through employees who want help with projects. The practical response starts with inventory and governance. Security and IT teams need to know which agents connect to company resources, which identities they use, what tools they can call, and what data they can access.

The UK National Cyber Security Centre recommends treating agent activity as user activity for 24/7 security monitoring and incident response. It also recommends sandboxing agents to control local and network resources and ensuring that operators can immediately halt autonomous activity. These are useful principles for dots and other proactive agents.

I would begin with a controlled pilot. Give the agent a narrow objective, a dedicated identity, read-only permissions, a small set of approved tools, network restrictions, and a defined data boundary. Log activity, review outputs, test revocation, and establish an owner who can stop the agent quickly. A pilot should also measure value alongside consumption: time saved, quality of outputs, errors prevented, resources used, and incidents or near misses.

I would give dot a clear project goal and the smallest practical set of permissions. For example, a low-risk use case might involve monitoring a shared project folder for documents relevant to a research brief, then preparing a draft summary for my review. That gives the assistant a bounded source set, a meaningful deliverable, and limited authority.

I would keep financial tools and personal payment cards out of the initial setup. Geordie’s Darley recommends using a limited-value gift card where an agent genuinely needs to make purchases. The same principle applies to credentials and sensitive data: give the assistant a limited, revocable capability rather than broad standing access.

Finally, I would make background work visible to myself and my team. I would schedule regular reviews of its activity, check connected-app permissions, remove integrations that no longer serve the goal, and ask for concise reports that link work performed to outcomes delivered. Dot’s promise comes from sustained initiative. Safe use depends on matching that initiative with sustained oversight.