A chatbot normally stops being useful when the conversation stops. OpenAI’s new Dots push in a different direction: persistent AI agents that can keep working toward a goal, use connected apps, operate through their own cloud computers and return with progress after the user has moved on.
That sounds like a productivity upgrade. For infrastructure teams, it is a much bigger architectural change. Once an AI remains active between conversations, the hard problems shift from generating a good answer to maintaining identity, permissions, compute, context, network access and an auditable record of what the agent did while nobody was watching.
Dots Turn a Conversation Into a Running Workload
OpenAI introduced Dots on September 29 as always-on agents powered by GPT-6 Astra. Each Dot has its own cloud computer and browser, can work across connected applications and can continue pursuing ongoing responsibilities without requiring the user to direct every individual step.
The company’s always-on agent launch details describe systems that can monitor feedback, revise projects as requirements change, rerun analysis when new information arrives and prepare work for later human review.
That is a different workload from conventional chatbot inference.
A chat request has a clear beginning and end. The user submits a prompt, the model consumes compute, generates an answer and the interaction eventually goes idle.
A persistent agent can remain attached to a project for hours or days. It may need to preserve context, wake when new information appears, use external tools, delegate work to subagents and wait for human decisions before continuing.
The important infrastructure shift is from sessions to ongoing state.
OpenAI already moved in this direction earlier in September with its Agents API, which is designed to keep cloud agents running reliably for days while managing files, code execution, context and subagents. Dots bring that same general operating model closer to ordinary users.
“Own Cloud Computer” Does Not Mean a Tiny Dedicated Server
One phrase in the announcement deserves careful treatment: each Dot has its own cloud computer.
That should not automatically be read as one permanently running physical server or virtual machine reserved around the clock for every user. OpenAI has not publicly detailed the underlying tenancy, scheduling or resource-allocation architecture at that level.
What matters is the abstraction.
From the user’s perspective, the agent has an environment that survives beyond a single chat response. It can use a browser, interact with applications and maintain the working context needed to continue tasks later.
For cloud architecture, that creates a more demanding state-management problem.
The system must preserve enough information to resume work correctly without treating every pause as a brand-new interaction. It also has to manage temporary files, browser state, authentication sessions, task queues and potentially several projects running at once.
That makes persistent execution environments part of the AI product rather than an implementation detail hidden behind a text box.
The scale implications could become significant if always-on agents become common. Reuters’ DevDay launch coverage noted that OpenAI says Codex and ChatGPT Work already exceed 35 million weekly users. Even a fraction of that population adopting long-running agents would create a very different workload pattern from short consumer chats.
Permissions Become More Important Than Prompts
The biggest technical distinction between a chatbot and an agent is authority.
A chatbot can suggest sending an invoice. A Dot can potentially prepare one, work through connected systems and move the task toward completion.
That means the key question is no longer simply whether the model understood the user’s instructions. It is what the surrounding infrastructure actually permits the agent to do.
OpenAI says Dots can connect through an ecosystem spanning more than 4,000 apps. Users choose which applications are connected, while app-level permissions and agent rules determine whether actions can proceed automatically or require approval.
Enterprise administrators get another layer of controls. The current workspace control settings allow organizations to manage cloud browser use, network access, cloud-computer capabilities, password-manager access and whether a Dot can connect to a user’s local computer.
Dots are also disabled by default for Enterprise workspaces until an administrator enables them.
These details matter because an agent with excellent reasoning and excessive permissions can still create a serious operational problem.
HW Server has already seen this principle play out in AI containment failures, where ordinary infrastructure boundaries became critical once autonomous systems could interact with credentials, networks and external services.
The safe design principle is straightforward: capability should not equal authority.
Background Work Needs a Different Security Model
OpenAI has placed restrictions around what Dots can do while operating proactively.
When a user is not actively interacting with a Dot, OpenAI says its proactive research uses connected-app tools restricted to read-only behavior. Those background tools cannot send messages, modify app content or control the user’s browser or computer.
That is a meaningful architectural boundary.
Persistent agents create a problem that ordinary chatbots rarely face: they may act at a moment when the owner is unavailable to notice something unusual.
A system that can independently monitor apps should therefore have fewer privileges than the same system operating while a person is actively reviewing its actions.
OpenAI also uses rules and an auto-review mechanism to determine whether an action can proceed, needs approval or must remain under direct human control. Certain sensitive actions, including password changes, stay with the user.
This is effectively privilege separation for AI agents.
The agent does not receive one universal level of authority. Permissions can change depending on the tool, action and operating context.
That pattern is likely to become important well beyond Dots.
Persistent AI Agents Need Observability, Not Just Memory
Much of the marketing appeal of an always-on agent comes from memory: the system learns what the user wants and does not need every project explained from scratch.
But enterprises may care just as much about observability.
If an agent works for several hours without supervision, teams need to know which systems it accessed, which tasks it attempted, which approvals it requested and what changed as a result.
OpenAI provides an Activity View for following a Dot’s progress and says users can redirect work as needed.
For larger deployments, the infrastructure requirement will go further.
Security teams will want machine-readable audit trails. Finance teams will want usage attribution. Platform teams will need to distinguish a legitimate long-running job from an agent caught in a loop. Administrators will need ways to revoke access without waiting for the agent to finish what it is doing.
Persistent agents therefore create an operations problem as much as an AI problem.
A useful system cannot merely remember what it was doing. The organization needs to be able to reconstruct what happened.
The Next AI Infrastructure Race May Be About Persistence
Dots are currently rolling out to eligible Pro and Business Premium users, with Enterprise access available through an administrator-enabled beta. OpenAI says users start with one primary Dot, while its longer-term vision includes multiple Dots and specialist agents working together.
That is where the infrastructure story becomes more consequential.
One persistent agent managing a handful of applications is relatively easy to reason about. A company running hundreds or thousands of agents, each with an identity, permissions, cloud workspace, app connections and ongoing responsibilities, begins to look more like a distributed workforce platform.
Identity management becomes agent management.
Cloud cost management has to account for autonomous work rather than just employee-triggered sessions. Security policies need to govern non-human actors that can reason about the systems they are accessing. Monitoring has to understand tasks instead of merely processes.
And if multiple agents begin delegating work to one another, organizations will need clear limits on how far permissions and responsibilities can propagate.
That is the useful way to read the arrival of persistent AI agents.
OpenAI Dots are not significant merely because an assistant can keep working after someone closes ChatGPT. They mark a transition from AI as a request-response service toward AI as a continuously available software actor.
The difficult work now moves beneath the interface: maintaining persistent state without losing control of it, giving agents enough access to be useful without granting unnecessary authority, and making autonomous work observable enough that humans can still understand what happened.
The chatbot era was largely about serving inference quickly. The agent era adds a harder requirement: keeping intelligence running without letting persistence become uncontrolled access.
