OpenAI gave ChatGPT agents a computer of their own. The hard part is still the toggle.

OpenAI began rolling out Dots, an always-on ChatGPT agent with its own cloud computer, to Pro and Business Premium subscribers on 29 September 2026. The computer is not the risk. The risk is that a goal and a one-time limit are the only policy standing between a dot and whatever system you connect it to, including a CRM.

That gap is not unique to OpenAI. Every agent platform ships a permission setting, because a permission setting is a product decision. Deciding what should sit inside it is an operator's decision, and it is the part nobody ships for you.

What OpenAI actually shipped on 29 September

OpenAI began rolling out Dots on 29 September 2026: an always-on ChatGPT agent with its own cloud computer, running between conversations.

Per OpenAI's own setup guide for dots, a dot is powered by GPT-6 Astra, keeps working on a goal between conversations, and can be connected to the apps a user chooses to give it access to. Access to a user's local computer is a separate, optional toggle that starts switched off. TechCrunch's coverage of the rollout and OpenAI's own article agree on the shape of the release: Pro subscribers get it first, outside the EEA, Switzerland and the UK; Business Premium subscribers get it everywhere ChatGPT already operates; Enterprise, Edu and Healthcare workspaces can turn on a beta, administrator by administrator, and it is off by default. For the first month, usage does not count against any plan's existing limits.

Credit where it is due: a goal, a stated limit and an escalation path is more structure than most agent rollouts bother shipping on day one. The problem is not that OpenAI built the wrong thing. It is that what it built is a setting, not a policy.

A goal and a limit is not a policy

OpenAI's setup flow asks for a goal and a limit on what the dot can do alone, then escalates anything else back to you.

That is the right shape. Most agentic tools collapse into exactly two states in practice: do it without asking, or ask first. The question that setting cannot answer is which tasks belong in which state, for your systems specifically, and that question does not have a default answer OpenAI, or any vendor, can set for you.

We made this same argument about agents generally in what you should never hand an agent: competence is no longer the constraint on what an agent can do. A dot with a cloud computer, a browser and a connected CRM is easily competent enough to update a field, draft a sequence or move a deal stage. Competence was never the question that mattered.

The decision rights matrix is the layer OpenAI did not ship

Reversibility and blast radius, not a vendor's default setting, should decide what a connected agent is allowed to do alone.

Reversibility is whether the action can be undone before anyone outside the system notices. Blast radius is how many records, people or pounds are touched if it cannot. A task that is easy to reverse and touches one record is a reasonable default yes for a dot. A task that cannot be undone and touches a named account, a quoted number or a signed term is a default no, regardless of how capable the underlying model is.

On every revenue orchestration engagement we run, that test sits inside a four level decision rights matrix, built out in full in the Revenue Orchestration Field Manual. OpenAI's setup flow gives you two levels: alone, or ask first. Our own clients' CRMs need at least four, because “ask first” still has to specify who gets asked, within what time bound, and what happens if nobody answers.

Where this bites first: a CRM write, not an email draft

A dot connected to a CRM can now act between conversations, which means the record that gets corrupted is the one nobody was watching when it happened.

A drafted email that is wrong costs a rewrite. A CRM field changed by an agent with standing access, while no human was in the loop, costs something else: a forecast nobody trusts, a stage advanced on a false signal, or an owner field overwritten with no way to prove what it said an hour before. We have written before about why that write needs one identity behind every agent write, never a shared service account, precisely so a mistake like this can be traced and undone rather than discovered three weeks later in a pipeline review.

This is the same failure mode we described in the control room problem: a dozen tools each capable of acting on a CRM, and no single place where someone decided, in advance, which of them is allowed to act alone. A dot with connected-app access is simply the newest tool capable of acting on that CRM. The control room problem does not get smaller because the agent got a friendlier name.

Before you connect a dot to anything that writes

Classify every connected system by reversibility and blast radius before you grant a dot access, not after the first mistake has already landed.

In practice, that means doing three things before the connection step, not after:

• List every system a dot would touch, and rate each one by what happens if a wrong action cannot be caught in time.
• Write down, per system, what the dot may do without asking, what needs a named human first, and who that human is.
• Confirm the system itself can show who, or what, made a given change. A permission setting upstream does not help if the system of record cannot answer that question on its own.

None of this is a reason to avoid connecting a dot to a revenue stack. It is the reason to do it with a written answer to “what is this allowed to do alone” that exists before the first connection, not one improvised the first time it asks.

OpenAI shipped a genuinely useful default: a goal, a limit and an escalation path, which is a sturdier starting point than most agent launches bother with. What it could not ship is the judgement about where your limit should sit for your CRM, your pricing table and your signed contracts. We built the vocabulary for that judgement because platforms keep shipping the lane; deciding who drives in it is still the operator's job.