Every Dot Gets a Computer: What That Actually Means

The line in OpenAI's announcement that's easy to read past is also the one that explains the most: every dot gets its own cloud computer and browser, kept separate from your actual machine unless you explicitly connect the two. It sounds like an infrastructure footnote. It's actually the design decision that makes everything else about dots — the always-on behavior, the background research, the multi-hour tasks — possible without immediately being reckless.

Why a separate computer, and not just a smarter script

A chatbot that answers questions needs a model and a context window. An agent that's supposed to keep a launch deck updated, watch a feedback channel, or file pull requests over the course of a day needs somewhere to actually do that work — a place to open a browser, click through a UI, run a search, hold state between one action and the next. OpenAI's answer is to give each dot a persistent machine of its own rather than borrowing yours.

That has an immediate practical consequence: a dot's work happens in parallel to whatever you're doing, not by hijacking your session. You can be editing a spreadsheet while your dot is, in a completely separate environment, testing a fix or compiling a report. VentureBeat's coverage frames this as agents that "keep working after an employee closes the chat window — monitoring projects, using software, responding to changing information and bringing completed work back for approval." None of that is possible if the agent only exists for the duration of a chat session on your device.

The security logic underneath the convenience

There's also a containment argument here, and it's the more important one. If a dot's default environment is its own sandboxed machine, then a task that goes sideways — a confused navigation loop, a misread instruction, an action taken against the wrong record — is contained to that sandbox by default. It can't reach your local files, your other browser tabs, or your desktop unless you've deliberately granted that bridge. MacRumors notes that this setup functions "much like Muse," Meta's competing agent, which we cover in more architectural detail in The Muse Secure VM: How Meta Isolates Your Agent's Work — both companies converging on the same instinct: an agent that acts on your behalf shouldn't, by default, run on the same machine as everything you actually care about protecting.

This is a genuinely different trust model from the one xAI has chosen with Grok Bot, which — per xAI's own announcement — signs into your existing tools using your own credentials, including tools with no API or MCP support at all. That's a higher-convenience, higher-exposure design: instead of isolating the agent from your accounts, it hands the agent the keys. We compare the two philosophies directly in Dots vs Grok Bot vs Muse, but the short version is that "your own computer, kept separate" and "your own credentials, handed over" solve the same problem — an agent needs to act somewhere, using something — from opposite directions.

What the browser inside that computer can and can't do

Inside its own machine, a dot's browser is how it reaches the world when a native plugin integration doesn't already exist — OpenAI's plugin ecosystem covers more than 4,000 applications, but the open web is bigger than any plugin catalog, and browsing is the fallback for everything else. That combination — plugins where they exist, browser automation where they don't — is what lets a dot plausibly claim to handle "research a competitor's pricing page" and "pull the latest ticket count from our CRM" with the same underlying architecture.

A dot doesn't operate on your desktop. It operates on a desktop OpenAI gave it, and asks your permission before it's allowed to reach into yours.

It's worth being precise, though, about what OpenAI has and hasn't disclosed here. The exact specifications of the cloud computer — how much it can run concurrently, how long a session can persist unattended, what happens to state between tasks — aren't detailed in the sources available as of this writing. What is confirmed is the architectural principle: separation by default, connection by explicit choice.

Why this matters for how you'd actually deploy one

If you're evaluating whether to hand a dot a real job — say, the developer workflow described in The Developer's Dot — the cloud-computer architecture is the thing that should shape your risk assessment more than any feature list. A dot reading your feedback channel and drafting a fix in its own environment, then returning a pull request for your review, is a fundamentally lower-exposure setup than an agent editing files directly on a machine that also holds your SSH keys and your personal email.

That's also the frame worth applying when comparing a dot to something like a Claude Code Skill. A skill runs inside an agent environment you already control and have already configured with whatever boundaries you've chosen — it doesn't introduce a new, separate always-on computer into your stack at all. A dot's isolation is provided for you, by OpenAI's infrastructure; a skill's isolation is whatever you've already built. Neither is strictly safer in the abstract — they're just different points on the same spectrum of "where does the agent actually run, and who's responsible for that boundary." Understanding that distinction is more useful than treating "it has its own computer" as either a reassurance or a red flag on its own — it's neither, until you know what you're actually connecting it to.

What "connecting the two" probably looks like in practice

OpenAI hasn't published a detailed technical walkthrough of how a user actually bridges a dot's cloud computer to their own machine, but the shape of the feature is implied by the products it needs to support. A developer's dot filing pull requests, for instance, doesn't need access to your literal laptop — it needs write access to a specific repository, which is a scoped, revocable grant rather than a blanket connection to your desktop. The same is likely true for most of the concrete use cases OpenAI has highlighted: a sales dot pulling from a CRM, a content dot pulling from a meeting-transcript tool, a product dot editing a shared Page. In each case, "connecting" almost certainly means authorizing access to a specific service or account, not opening a tunnel into your actual operating system.

That distinction matters because it reframes the risk conversation. The interesting question for most users isn't "should I let my dot touch my computer" — for the vast majority of use cases, the answer is simply no, and the architecture doesn't ask that of you. It's "which specific accounts and services am I granting this dot access to, and does the scope of that grant match the job I actually gave it." That's a more tractable question, and it's the same question worth asking before authorizing any third-party integration, agent or otherwise — the always-on nature of a dot just raises the stakes of getting the answer wrong, since a scoped-too-broadly grant stays open indefinitely rather than expiring at the end of a single session.

Part 3 of 30 in the ChatGPT Dots series. Previously: Inside GPT-6 Astra: The Model Powering Dots. Next: Dots vs Codex: Two Very Different Kinds of Autonomy. Browse more builder insights or explore AI skills at aiskill.market.