Approval rules decide how much work OpenAI's new Dots agents can finish alone

A customer reports a bug in a Slack channel after the engineer who owns that code has logged off. In OpenAI's version of events, a Dot starts investigating as soon as the bug is mentioned ^[7], builds and tests a fix, and leaves a pull request waiting for human review ^[5]. The engineer's first job the next morning is reviewing code they did not write.

That is the example to plan around, because a person signs off at the end of it. The launch language goes further. At DevDay 2026 ^[2], OpenAI described Dots as "remarkably capable, always-on agents built to handle everything" ^[16], and Altman, its chief executive, said they are "more ambitious" than ChatGPT and could bring a "whole new way to work with AI" ^[17]. The company's own guidance is that users should remain responsible for reviewing work and approving commitments ^[12].

The enterprise product in the pitch is a set of specialist Dots holding their own credentials for jobs such as procurement and invoice processing ^[14]. For now it is a preview. OpenAI plans to build it through pilots, setting each Dot's role, tools and approval process with the customer, and is working with Microsoft to connect it to the governance and security controls in Microsoft Agent 365 ^[15].

OpenAI has not published usage figures, or a price for Dots beyond the one included in a plan ^{[9] [18]}. Teams will tell themselves the reviewer reads every pull request and every proposal change closely. I'd expect the pressure to run the other way. Each action set to require approval becomes a message to a person ^[8], and the Dot finishes work only as fast as that person answers. Set too many actions to approval and the user is back to prompting, in reverse. Set too few and the agent changes accounts and customer-facing material before anyone has read it.

OpenAI's three rule settings ^[3] give teams a way to sort this. Ask two questions of every action a Dot could take: can whoever spots a mistake undo it, and does it reach anyone outside the company. Internal and undoable, such as rerunning an analysis when new data arrives or revising launch materials ^[13], can be allowed. Internal but permanent, like merging code or deleting records, needs approval, and so does external but correctable, like updating a proposal a customer will read. External and permanent, such as sending an invoice or agreeing contract terms, belongs in block. OpenAI has already filled two corners itself, keeping idle research read-only ^[10] and leaving password changes to the user ^[4].

I'd start with one Dot on the pull-request workflow, where a review step already exists and nothing ships until someone merges it. The tradeoff is pace. A Dot behind one reviewer will finish less than the launch examples suggest, and the tasks it runs through Codex or ChatGPT Work still count against usage limits, even though chatting with it does not ^[19]. Before connecting any other app, name the person who will read its approval requests and how many a day they can clear. If nobody can be named, the action goes in block.