OpenAI dots' Four Action Rules: When to Ask and Who Acts

dots keeps working after the conversation ends

On September 29, 2026, OpenAI announced dots, an always-on agent.

According to OpenAI’s official documentation, dots runs on GPT-6 Astra and has its own computer and browser in the cloud.

Work in the cloud can continue while the user’s computer is turned off. Work that uses a computer the user has connected, on the other hand, requires that computer to be online with the ChatGPT app open.

Availability is being rolled out in stages, and conditions differ by plan and region.

Even when you use a chat answer in your work, you still need to check it. An agent that operates external systems goes further: it may send or update something before a person has had a chance to reread it. And it works during hours when no one is in front of the screen.

That is why deciding which actions are permitted, when approval is required, and who actually performs each action becomes the central task when adopting such an agent.

OpenAI’s official documentation page “Control your dot” turns these decisions into a setting called custom rules.

This article assumes a scenario in which an employee delegates work to their own dot, using accounts and connected services the company has approved. It focuses on deciding when each action requires approval, who performs it, and how to review those choices over time.

What the documentation says: action review and four choices

An automatic review runs before actions

According to OpenAI, before dots takes an action that could affect your accounts or share information, an automatic review takes place.

The review checks the action against the user’s instructions, permissions, custom rules, and built-in safety requirements, and determines whether the action can proceed, needs approval, or includes a step the user must do themselves. In the documentation’s example, the user must change a password themselves.

The documentation also gives concrete guidance on instructions. It recommends giving ongoing instructions a clear scope: who is involved, what should happen, and when. It states explicitly that asking dots to draft replies does not give it permission to send them.

A specific instruction can cover future actions within its scope; actions outside that scope need to be assessed separately.

The four custom-rule choices

Custom rules are an optional setting for specifying how recurring actions are handled.

Under Settings > Personalization > Custom rules, you describe an action in text and choose how dots should handle it. There are four choices:

Rule	Intended behavior as described in the documentation
Take action without asking	Take the specified action without asking for approval
Take action when you say so	Proceed when you explicitly request the action; otherwise ask immediately before acting
Ask before taking action	Ask for approval before taking the specified action
Hand off to you	Ask you to take the action yourself

As examples, the documentation suggests “Ask before taking action” for sending messages to customers and “Hand off to you” for deleting shared project files.

It also says you can start with clear instructions in your conversation, and that you don’t need to create a rule for every approval.

Note that even if you choose “Take action without asking,” built-in safety requirements and required confirmations, such as approval to use a saved login, still apply.

How MIF reads the four choices

The following is MIF’s interpretation of the four choices.

The four choices are not a scale on which safety increases step by step. Even when the user performs an action themselves, problems can occur if the information or judgment behind it is wrong.

We look at the four choices through three questions:

• What permission has been given: whether a standing permission or an explicit instruction covers the action.
• When additional confirmation is required: whether dots may proceed without additional approval under the selected rule or must ask before acting.
• Who actually performs the action: dots, or the user.

The difference between “Ask before taking action” and “Hand off to you” is especially easy to overlook. With the former, dots performs the action after the user approves it. With the latter, the user performs the action themselves.

We use these three questions to choose an appropriate rule for each action, based on its impact and the company’s business requirements.

We favor delegating suitable tasks to AI while keeping people involved in judgment and accountable for outcomes. The scope of delegation can change as a company’s work and circumstances evolve.

Check custom rules and connected-app access separately

The documentation explains that custom rules can give dots permission for particular actions, require it to check with you, or prevent it from taking an action.

At the same time, it states that saved rules are instructions dots tries to follow, and that dots can make mistakes. Custom rules do not grant access to an app or computer, and they do not override built-in safety requirements.

In other words, the distinction that matters is between permission to proceed with an action and the scope of information and actions actually available in connected services.

The same documentation says app actions are controlled separately from custom rules, through plugin permissions. A related page gives the example that you can allow dots to read email without allowing it to send email.

Custom rules are also referenced when the automatic review evaluates an action. So what you need to check is the combination of the rule’s wording, the product’s review, and the permissions in connected services.

We do not think rules are meaningless because they are written in natural language, nor that the review makes everything safe.

For app permission settings, too, it is worth confirming whether a setting blocks an action or requires confirmation before execution.

Plugins are not the only route

Besides app connections, dots may work through signed-in sessions in its cloud browser, or through a computer the user has connected. The admin documentation likewise advises reviewing the permissions of a connected account and the cloud browser’s sign-in separately.

When restricting an action, check each route dots can use: app connections, signed-in browser sessions, and connected computers. Confirm which settings govern the action on each route rather than assuming that a restriction on one connection applies to all of them.

A planning template for specific actions

The examples below are MIF’s recommendations, not mandatory product settings or a guarantee of safety. Adapt them to your workflows, business relationships, applicable laws, and the potential impact of errors.

Action	Example approach	What else to define or check
Create a personal draft from specified materials	Take action without asking	Limit the source materials and the location where the draft is saved. This does not include sharing or sending it.
Send a scheduling message to specified internal recipients	Take action when you say so	Check the recipients, content, dates, and sending account. If the task includes calendar invitations, check that operation separately.
Send a message to a customer	Ask before taking action	Check the recipients, message body, and attachments. Follow any required internal approval process as well.
Delete a shared file	Hand off to you	Keep deletion as a user-performed action and check which actions are permitted in the connected service.
Finalize the amount on a quote or invoice	A person decides and finalizes the amount in this example	Use dots only to organize the figures. Decide separately how the finalized document will be sent.

Password changes are a separate case: the documentation says the user must perform them.

Check product confirmations against internal approval requirements

“Hand off to you” asks the user to perform the action themselves. It is not a feature that routes approval to a manager or a finance lead.

So a user approving something on the dots screen is not necessarily the same as meeting the company’s approval requirements.

Compare the product’s confirmation prompts with your organization’s approval requirements. For actions the user is not authorized to approve, check what separate internal approval is needed.

What to decide before filling in the table

Three things are worth deciding before you fill in the table:

• Inventory of actions: Break the work you want to hand to dots into individual actions such as “read,” “draft,” “send,” “update,” and “delete.” For quotes, treat “organizing the figures,” “finalizing the amount,” and “sending the finalized document” as separate actions.
• Scope of instructions: In ongoing instructions, state who is involved, what should be done, and when.
• Estimating impact: Treat how easy something is to restore or correct as one factor among several, and also consider the information involved, who is affected, the number of items processed, and how long it would take to notice a mistake.

Restoring something and undoing the effects it had in the meantime are different things. For example, even if you can restore a shared document that was overwritten by mistake, if a colleague has already read it and moved ahead with their work, restoring the file does not erase that effect.

An action that is easy to fix once can carry a very different checking and recovery burden when it is applied repeatedly across many records.

Design setup, testing, and review as a single process

We recommend treating the initial setup, a check of actual behavior, and ongoing review as a single process.

Test behavior before you start

Before putting dots to work, test the following in an environment where the impact of errors is limited:

• When asked for a draft, does it stop short of sending?
• Does it ask for confirmation when an action goes beyond the specified scope?
• If you deny approval for an action, does dots refrain from carrying it out?

Of course, passing these checks does not by itself guarantee all future behavior.

Separate stopping active work, canceling schedules, and correcting results

How to stop work is another thing to decide at the design stage.

The documentation explains that different stop actions have different effects. “Pause” stops your dot’s current main task, but it doesn’t stop every delegated task or cancel future scheduled runs. You inspect and stop delegated tasks individually in Activity, and disable or delete recurring tasks in Scheduled.

Stopping or deleting a dot does not, by itself, undo actions it has already completed. According to the documentation, deleting your dot doesn’t undo changes already made in connected apps or recall messages already delivered to other people.

Define separate procedures for stopping tasks, reviewing completed actions, and reversing or correcting their effects where possible.

Decide who reviews Activity, and what they look at

As a way to check, the documentation points to the Activity view. When you open your dot’s profile in the desktop app, you can review the progress, files, and results of tasks, and respond to requests waiting for approval or input. In Scheduled, you can review the instructions, timing, and destination of recurring tasks.

Review the task’s outcome, not just its completion status. The documentation itself notes that a completed run doesn’t by itself confirm that the requested result was achieved or delivered.

Assign someone to review unexpected actions, the reasons for approval requests, and task outcomes. Keep a record of changes to custom rules and connection settings.

Triggers for review

Possible triggers for review include:

• When approval requests pile up: Rather than dropping confirmations simply because there are many, revisit the scope of requests, duplicate confirmations, how notifications are delivered, and how the work is divided. If you reduce the number of confirmation prompts, check that required approvals are still obtained.
• After unexpected actions or rejected approval requests: Record the reason for rejecting a request and use it to revise the wording of rules or the scope of instructions.
• When connections are added or changed: For example, when you add an app, Slack, or a computer. Because app and computer connections are managed separately from custom rules, each new connection can widen the range of available actions.
• When people change roles or leave: According to the admin documentation, disconnecting an app does not delete information already obtained. The handover procedure needs to include checking what deletion and reset options are currently available and what they cover.
• When the product is updated: The admin documentation labels the dots permission as “Use dots (Beta).” It is safer to assume that settings and behavior may change.

On records, the admin documentation says Compliance API records can be used to investigate users’ messages and dots’ replies, while cautioning that you should confirm record coverage before relying on it for an audit.

Having conversation records is not the same as having a complete audit trail of every action. Each company should decide which records to retain, what they need to cover, and who will review them and when.

Summary

MIF recommends breaking delegated work into specific actions. For each action, define its scope, the instructions that permit it, when additional confirmation is required, and who performs it. The four custom-rule options in dots provide one way to specify how those actions should be handled.

Consider the information involved, who may be affected, the volume and frequency of actions, and how readily errors can be corrected. Translate these decisions into custom rules and connected-service settings. Check that product confirmations align with internal approval requirements, then test whether the setup behaves as intended.

Review the setup as workflows, connected services, or admin settings change. Keep separate procedures for stopping active tasks, canceling scheduled runs, and reviewing and correcting the effects of completed actions where possible.

Start by listing the actions you plan to delegate and the potential impact of each.

Sources and scope

This article draws primarily on OpenAI’s announcement “Introducing dots” and the official documentation page “Control your dot” (ChatGPT Learn), based on information confirmed as of October 3, 2026.

We also referred to “Tasks and memory” and “Connect computers and apps to your dot” in the same documentation, and to the admin page “Manage dots permissions and capabilities.”

The availability of dots (plans, regions, and whether admin enablement is required), its features, and the wording on screen may change.

Descriptions of rule behavior are based on OpenAI’s published documentation. MIF has not independently tested how those rules work in practice.

The interpretation of the four choices, the example table, and the testing and review recommendations are MIF’s own analysis and proposals.

If you are considering adoption, please check OpenAI’s official information and your own environment for the latest status.