OpenAI Dots: Always-on agents with fine print on spending

OpenAI has taken a step far beyond just another chatbot on steroids. Dots presents itself as a persistent agent, with a friendly avatar, that continues working even after the user closes the conversation. It can monitor ongoing tasks, use connected software, and return when a human decision is needed. The underlying idea is to stop treating AI as a question-and-answer window and start seeing it as a delegate who can maintain the thread for hours or even days.

However, the friendly side hides a complex web of consumption and permissions that warrants closer examination. During the launch, the main Dot appears free and available 24/7, but if it starts outsourcing work to Codex, the bill can change dramatically. For IT teams and SMEs, the promise of always-on agents is appealing, although the pricing model and task allocation can transform a seemingly innocuous tool into a source of unexpected expenses.

What is Dots and why is the unit of work changing?

OpenAI's proposal changes the fundamental aspect of interaction: from a one-off conversation to continuous engagement . Dots, presented at the developer event in San Francisco, breaks with the classic chatbot model. The agent receives objectives, learns preferences from feedback, and continues working in the background. It runs on GPT-6 Astra and has its own cloud-based computer and browser, so it can operate independently of the user's physical device unless the user grants a direct connection.

This separation is important because closing ChatGPT doesn't mean the engagement is over . The agent can continue reviewing authorized information, maintain open projects, or prepare material for later review. Furthermore, it connects with over four thousand applications via plugins and can communicate through ChatGPT, Slack, and Microsoft Teams. Voice is available in ChatGPT, and more channels are expected. Initially, it's available to eligible ChatGPT Pro and Business Premium customers; in enterprise, education, and healthcare organizations, administrator-controlled access is planned.

The first examples point to a professional audience: software development, research, sales, product, and content operations . A programmer might ask their Dot to monitor customer feedback, detect recurring defects, narrow down a fix, submit the code to Codex, test the result, and return a pull request. A researcher might commission an analysis that updates as new evidence emerges, monitoring approved sources, recalculating, and creating updated charts. A sales team could compare a potential client's requirements with product documentation and account history, keep a proposal active, or indicate which technical tests are still pending.

This goes far beyond a scheduled reminder. The agent must detect changes, preserve context, choose its next action, and know when it needs approval . OpenAI calls some of this background work proactive investigation: the Dot can inspect information in connected applications and locate new content, but this mode is read-only. While searching on its own, it cannot send messages, edit content, or manage the user's computer. When it needs to modify data or communicate externally, another permissions decision comes into play: allowing, blocking, or requiring approval through custom rules. The Activity View shows what the agent is doing, and there's an automated review step for relevant actions; sensitive operations, such as changing passwords, remain reserved for humans.

The interface may seem bouncy, but the underlying product resembles a managed cloud worker . Its identity, memory, tools, permissions, and computing environment all travel together. The avatar makes the persistent software accessible; the cloud computer gives it a place to operate. That combination is what sets Dots apart from a chatbot with a mascot.

The fine print of consumption: free yes, but with asterisks

Thibault Sottiaux, OpenAI's lead product manager, explained that each user's primary Dot is included in the plan and available 24/7 without affecting their usage allocation . However, if that Dot delegates a task to Codex, the usage is deducted as usual. Simply put: the agent can be on all day at no cost, but as soon as it starts creating Codex tasks, the bill can increase.

The published terms are somewhat more restrictive than the marketing message. Using Dots will not count toward eligible allocations during the first month after launch ; after that, plan-specific conditions will be published. This leaves unclear what will happen to the included quota once that window closes. For developers planning Dots-based workloads, this uncertainty is significant.

On launch day, OpenAI halved the usage included in its $200 Pro plan and added a $500 premium tier . This move suggests an adjustment to the business model to recoup the enormous cost of maintaining millions of agents online. Sottiaux expects several million active Dots within days, which represents a considerable expense even if they don't call on other products.

For any team evaluating autonomous agents, the distinction between included work and metered usage is key . The promise of always-on agents is appealing, but the underlying billing model can turn a seemingly free tool into a source of unexpected expenses if task routing isn't controlled.

Implications for SMEs and IT teams

In an SME, always-on agents are a double-edged sword . On the one hand, they automate repetitive tasks and maintain a constant digital presence without human intervention. On the other hand, the agent's decision-making process—whether to perform the work itself, use an included tool, or outsource it to Codex—introduces an element of unpredictability into spending. Without proper oversight, we might find that the monthly quota has been consumed on coding tasks that could perhaps have been handled differently.

That's why clear usage policies and cost control mechanisms are essential . Just as software development measures token consumption or chooses models based on budget, it's now time to add an agent management layer that decides which tasks are routed to metered services and which aren't. The lack of alerts before a Dot transitions from included work to metered consumption is a risk that teams must mitigate with proactive monitoring.

The sensible approach is to start with limited pilot projects, define spending limits, and regularly review usage patterns . This isn't about abandoning automation, but rather integrating it with the same financial discipline applied to any cloud service. Experience with other AI tools shows that unchecked efficiency can backfire.

This launch fits into a broader trend toward autonomous agents that perform tasks continuously . We've already seen how AI accelerates exploits and how a defensive mindset is no longer sufficient; in this context, managing always-on agents adds a new dimension of operational and financial risk. There are also alternatives on the market, such as AWS's open-source agent, which, according to the company, costs 45% less than Claude Code or Codex. The choice of platform and pricing model becomes a strategic decision.

OpenAI Dots versus Meta Muse: distribution, trust, and habits

The most direct competition pits OpenAI's advanced-user deployment against Meta's broader, consumer-first approach . Meta's Muse had already established a clear benchmark for an assistant with persistent identity, connected applications, memory, and its own compute environment. Various analyses have interpreted Dots as OpenAI's answer to Muse, and the comparison clearly highlights the different launch strategies.

Meta can position an assistant in front of a vast audience of consumers and familiar social products. OpenAI can start with people who already use ChatGPT and Codex for demanding work. These advantages lead to different adoption paths : Meta can make persistent assistance feel like a mass communication product; OpenAI can present it as an extension of professional workflows. The distinction isn't permanent, because Meta has added enterprise integrations, and OpenAI describes Dots as customizable personal agents contactable through various channels.

The initial paths determine what each company needs to demonstrate. Meta needs to show that broad availability generates sustained utility beyond mere curiosity ; OpenAI needs to demonstrate that more limited professional access produces reliable economic value. OpenAI's examples emphasize work products: returning code, updating analytics, reviewing release materials, preparing sales documents, and maintaining shared project information. Muse places more emphasis on accessibility and everyday usability because a widely distributed personal agent can establish habits before enterprise deployment matures.

Competition depends on more than just benchmark intelligence. Persistent agents must earn permission to observe information and act across services . This transforms trust into a distribution advantage: the company that already owns a user's conversations, files, contacts, or work context encounters less friction when requesting another connection. It also turns accumulated context into a switching cost. A mature personal agent learns how a person writes, which approvals matter, and how recurring work moves between applications. Replacing it requires rebuilding rules, integrations, memory, and exceptions. The winning interface can become difficult to abandon because it understands operational habits, not because its avatar has a distinctive appearance.

OpenAI's connection to Codex strengthens its position among developers. A Dot can detect a small engineering problem, coordinate programming work, and return something a programmer can inspect . ChatGPT Space extends that advantage to teams, because the work can remain in a shared environment instead of residing solely in the memory of a personal agent. Meta's approach has another strength: distribution among consumers can generate frequent and varied interactions that teach users when persistent support is worthwhile.

Both companies face the same fundamental problem. An agent that rarely acts offers limited value; an agent that frequently acts increases the likelihood of a costly or embarrassing mistake . The balance will depend on the permissions design. Broad authorization reduces disruptions but increases exposure; narrow authorization protects users, though it can turn an autonomous agent into an approval notification system. Personality complicates the calculation: a friendly avatar can facilitate delegation, especially when the agent asks questions or reports progress like a colleague, but anthropomorphic design can encourage overestimating its judgment. Software doesn't acquire human responsibility simply because it remembers preferences or uses a familiar voice. OpenAI must make the boundaries as clear as the personality: users need to know what the Dot observed, why it chose a particular action, and which system will record the outcome.

A live demonstration of the event included moments of delay alongside successful interactions. That small imperfection matters because persistent agents will encounter uncertainty outside of carefully staged demonstrations. The competitive winner won't simply complete the most impressive staged flow; they will recover smoothly from missing information, expired credentials, ambiguous instructions, and unexpected application changes. For developers and enterprise buyers, measurable reliability will matter more than the charm of an avatar: completion rates, intervention frequency, rollback options, and audit quality will determine serious deployments. For consumers, the calculation may seem simpler, but it remains relevant: a personal agent with access to email, calendars, purchases, and messages can have real consequences from a misinterpreted request. In a market where friendliness can attract attention, the lasting advantage will come from demonstrating that continuous access doesn't require constant anxiety.

From co-pilot to agent: more context, more responsibility

A Dot is best understood as an ongoing relationship with delegated software , not as a single response from a model. Traditional chat assistants rely on explicit turns: the user asks a question, the model responds, and the exchange pauses. Even the most sophisticated tools are often still tied to an active session. Dots are structured around continuity: the person defines a goal and its boundaries; the agent maintains multiple projects and returns with work, questions, or approval requests.

This changes what users need to communicate. A good indication may no longer be enough . They need to express enduring standards, priorities, and boundaries that remain valid despite changing circumstances. Consider a product launch: a typical assistant might draft an advertisement from notes; a Dot could monitor changes to product specifications and review related materials when those changes affect positioning. The difference isn't just speed, but the accountability to recognize when further action is required.

This responsibility also explains why Dots must operate independently of a device or interface. The agent belongs to an account and its authorized context , not to a specific laptop or chat thread. A person can assign work in ChatGPT, answer a question in Slack, and inspect the same project later from their phone. The interface changes, but the delegated objective remains the same.

This design follows a broader shift from co-pilots to agents. A co-pilot assists during an activity controlled by a person; an agent is given a goal and selects intermediate actions within an approved range . The distinction isn't absolute: Dots still relies on human instructions, connected tools, and review. OpenAI also acknowledges that it can make mistakes and recommends verifying relevant work. Even so, the product asks users to monitor outcomes rather than direct every step—a more substantial behavioral change than simply adding another model to ChatGPT.

It also places greater emphasis on organizational knowledge. An agent can't effectively maintain a project if important decisions remain scattered across messages, documents, meetings, and private memories . OpenAI addresses this problem with ChatGPT Space, a collaborative environment where employees, ChatGPT, Codex, and Dots work with shared project material. Reports on this space describe Pages, files, and other artifacts that individuals and agents can update together. Space gives persistent agents a visible destination for their work and prevents team artifacts from disappearing into an employee's private chat history. For knowledge workers, the model resembles a continuously maintained project room: goals, source material, drafts, and decisions remain available as different people and agents contribute.

Continuity introduces a new mode of failure. An incorrect response in a chat might be discarded; an incorrect assumption stored within a continuous workflow can shape many subsequent actions . That's why teams will need to distinguish lasting instructions from temporary preferences and decide which sources have authority when messages, databases, and documents conflict. This governance work underlies user-friendly design. Giving a Dot a name might encourage adoption, but a name doesn't resolve conflicting permissions or outdated context. The practical answer to what these agents are is that they combine a model, a cloud computer, connected applications, memory, and approval rules around continuous goals. This package is OpenAI's attempt to make delegation the default AI interaction; whether users embrace it will depend on how often it produces useful work without creating new supervisory burdens.

Autonomy versus resilience

Dots becomes valuable when it operates without constant supervision, but that same independence makes errors harder to contain . A chatbot failure typically appears as text. A persistent agent failure can manifest as a modified record, an external message, a submitted form, or a cascading workflow. This difference shifts the focus of security from content filtering to operational control. The central questions become who authorized an action, what information supported it, and whether the outcome can be reversed.

The controls proposed by OpenAI address parts of the problem. Users select connected applications, create custom rules, inspect activity, and approve sensitive actions . The company also separates a Dot's cloud computer from the user's device by default. A deeper connection can be granted, but the product does not require unrestricted access to a personal computer. Saved credentials can allow access to websites without revealing the underlying password, reducing an obvious risk, although authenticated access still grants significant authority. The agent does not need to know a password to send incorrect information through an approved account. Credential protection and action correction are related, but they are not the same problem.

Proactive read-only investigation offers another useful boundary: a Dot can search for relevant updates without modifying the systems it examines . However, useful work often ends with a write action. The agent will need to edit a document, update a record, send a message, or activate another tool. At that point, the quality of the approval design becomes critical. A vague confirmation request can obscure the scope of an action; repeated requests can also train users to approve without reading. Effective monitoring requires concise previews: intended action, objective, data involved, and likely consequence before granting permission. Post-execution logs are also necessary. An Activity View is only valuable when it provides enough detail to reconstruct what the agent did and why.

Enterprise administrators face an additional identity challenge. A personal Dot operates using a user's login credentials, but OpenAI is also showcasing specialized Dots with organizational identities and assigned responsibilities . These agents could perform purchasing, invoice processing, customer service, marketing, or contract-related tasks. Each role would require credentials, access policies, monitoring, and an offboarding process. This resembles service account management, but the agent selects actions using probabilistic reasoning. Traditional automation follows a defined path; an agent can adapt its path as circumstances change. Adaptation creates value, but it complicates testing: a team cannot validate every future sequence because the agent responds to new information and changing application states. Organizations will need bounded environments, phased permissions, and clear escalation rules. They might also require spending limits, recipient restrictions, and protected data categories.

OpenAI acknowledges that Dots can make mistakes. Approval safeguards indicate that some sensitive tasks always remain in the user's hands . This is a sensible starting point, not a test of generalized reliability. Hard cases typically fall below the obvious danger threshold. Sending a routine document to the wrong client might not resemble a password change; updating a project plan with outdated data might not trigger a security alarm. A reliable system should detect contextual errors, not just prohibited actions. This requires robust source tracking and an awareness of uncertainty. Persistent memory introduces another risk: learning from feedback can improve consistency, but an incorrectly inferred preference can influence subsequent work. Users need ways to inspect, correct, and remove what the agent believes about them; otherwise, convenience can turn misunderstandings into default behaviors.

Shared spaces raise their own boundary issues. Private context shouldn't be silently made visible to a team simply because an agent copied it into a shared document . OpenAI states that sharing a collaborative Page doesn't directly expose private conversations or personal memory. However, information written to that Page becomes visible according to the Page's permissions. This means that the final artifact matters more than the source boundary alone. A Dot can maintain technical separation while still transferring sensitive information through generated content. Knowledge workers already grapple with this problem when combining notes from multiple sources; a deliberate workflow can clarify what belongs to private memory and what belongs to shared work. Persistent agents operationalize this distinction: they don't just retrieve information; they can move it between contexts while pursuing a goal. Controls demonstrate awareness of these risks; the unanswered question is how they function during messy, everyday use. A reliable Dot must do more than avert disasters: it must reveal uncertainty, call for help at the right time, and empower users to fix their mistakes. That standard is demanding, but also unavoidable, because the core promise of the product depends on reducing supervision without eliminating accountability.

First use cases: Do they reduce work or transfer it?

The decisive metric isn't how long a Dot remains active, but how much verified work it completes before human intervention is required . The launch examples are well-chosen because they involve recurring changes: customer feedback accumulates, research evidence evolves, sales requirements shift, and launch materials need synchronization. These are tasks where continuous attention adds value, but they also contain enough ambiguity to reveal weaknesses in planning, source selection, and escalation.

An initial example involved an outstanding invoice from a freelancer that had gone unnoticed. Dot identified the unfinished task in an email thread, gathered the relevant details, and prepared the invoice before sending it after receiving approval . This scenario reflects the product's appeal: the user didn't have to remember the task, reconstruct its context, or manually prepare the document. It also illustrates the permissions boundary. Drafting from existing information is different from delivering a financial document to an external recipient. Early adopters will discover whether such boundaries remain clear in more complex cases. A missing tax field, a disputed amount, or an ambiguous recipient could turn a helpful intervention into additional correction work.

Software development offers another telling example. Agents already write code, run tests, and prepare pull requests; Dots adds oversight and project continuity . The useful metric isn't the number of patches generated. Teams should examine how many changes pass review, avoid regressions, and address real user needs. A Dot that opens many weak pull requests can increase the developers' workload. Persistent activity doesn't equal productive autonomy.

Research workflows present a similar challenge. Recalculating an analysis when new data emerges seems valuable, but the agent must recognize whether that data is comparable . They must also preserve the methodology and explain why the results changed. Without traceability, faster updates can reduce confidence rather than enhance it. Sales and marketing scenarios test factual discipline. A persistent agent can keep proposals and pitch materials synchronized, but small inaccuracies can affect customer expectations. Organizations will need authoritative sources for product capabilities, commitments, and legal language. The agent should not resolve contradictions by choosing the document that is easiest to retrieve.

These limitations explain why shared knowledge matters. Persistent agents need structured access to current decisions, approved terminology, and identifiable stakeholders . They also need expiration signals: a document that was authorized six months ago may now be misleading. For individual users, adoption will depend on the quality of notifications. An always-on agent that reports every minor finding can become just another noisy inbox. The product must learn which new developments warrant an interruption and which can wait for a summary; that criterion varies by person, project, and consequence. OpenAI says that Dots learns from feedback over time. The value of that learning should manifest as fewer unnecessary interruptions and more accurate escalations. Users should be cautious about assuming personalization equates to understanding: behavioral patterns can improve recommendations without giving the system complete knowledge of intent.

Organizations should start with reversible and easily assessable workflows. Drafting, monitoring, categorizing, and running tests offer clearer checkpoints than unconstrained external actions . The most robust implementations will likely combine broad observation with limited execution. An agent can monitor many sources while receiving restricted authority to modify them. This structure preserves much of the time-saving potential and creates visible moments when a person can verify work with relevant consequences. Dots will face a basic productivity test: Does it reduce coordination effort or shift that effort to permissions, corrections, and monitoring? The answer will vary depending on the workflow. Repetitive tasks with stable rules offer a better starting point than politically sensitive or poorly documented processes. The release clearly defines the product category but doesn't establish the intervention rate, the cost of errors, or the long-term value of a persistent agent. Those results will emerge from everyday use, not from presentation demonstrations. Buyers should look for evidence of complete workflows, rather than isolated examples of impressive actions.

What to observe from now on

The next phase will be defined by reliability testing, competitive distribution, and the expansion of delegated authority . The first indicator is the frequency of intervention. Users need to know how often a Dot completes a significant task without repeated clarifications, corrections, or approvals. A declining intervention rate would support OpenAI's claim that the agent learns useful preferences. A high or unpredictable rate would suggest that the ongoing operation primarily offloads management work. Relevant evidence should distinguish between innocuous inquiry and execution with consequences. Success in gathering information does not demonstrate reliability when editing records or contacting other people.

The second signal is how Meta responds through Muse. Meta can extend enterprise integrations, strengthen workplace controls, or use its consumption distribution to more quickly normalize personal agents . OpenAI can respond with Codex, ChatGPT Space, and deeper professional workflows. Increasing competition would confirm that persistent agents have become a core interface category. It's worth noting how both companies describe trust. Detailed auditing tools, constrained permissions, and recovery controls will carry more weight than claims of personality or constant availability.

The third indicator is whether organizations are deploying specialized Dots beyond limited pilots. These agents would have their own identities, credentials, and defined organizational responsibilities . Wider deployment would strengthen OpenAI's argument that persistent agents can become managed participants in enterprise systems. Slow adoption would indicate unresolved concerns about security, accountability, or cost. Specialized deployments will also reveal who is responsible for an agent's mistakes. Accountability must remain identifiable when the software operates across departments and makes intermediate decisions independently. Regulatory attention will follow the same issue: persistent agents blur the familiar lines between a software tool, an automated decision-making system, and a delegated representative. Key disclosures will cover permissions, data movement, monitoring, and human review. Buyers should also look for clear incident reports when an agent behaves outside of expectations.

OpenAI's vision goes far beyond another ChatGPT feature: it wants AI to maintain continuous work across devices, applications, and conversations . That vision is concrete enough to be put to the test. Ask whether the agent completed a real workflow, whether its actions were auditable, and whether errors remained recoverable. If Dots consistently meets these standards, persistent agents can become a normal layer of knowledge work. If they require constant checks, the bubbling avatar will mask a known problem: automation that creates more work for its owner.