OpenAI Dots: What to Delegate to an Always-On AI Agent

OpenAI’s Dots announcement raises a practical question for agency owners and operations leaders: which responsibility would you hand to an AI agent that keeps working between conversations?

The strongest first assignment is a recurring job with clear inputs, a reviewable output, and explicit limits. Preparing an internal update or investigating an unresolved question fits that shape. “Keep the business running” doesn’t give an agent enough guidance to know which decisions belong to you.

OpenAI introduced Dots on September 29, 2026. The company describes agents powered by GPT-6 Astra, with their own cloud computers and access to connected apps. It describes proactive research as read-only. An agent noticing something in the background is different from an agent being authorized to change it. OpenAI: Introducing dots

That distinction matters more than the always-on label. Continuity could make delegation more useful, but it also makes a vague assignment harder to ignore. Before you ask a Dot to stay on top of a project, define what staying on top of it should produce.

This article explains how I would choose and evaluate an initial responsibility. The examples are proposed operating patterns, not results from a Rise Productive Dots test.

Start with the access conditions

View image detail

Access inspection covers account eligibility, permitted sources, and the connections required for the task.

Actual size

Choose Actual size to read the graphic closely.

As checked on September 30, OpenAI’s setup documentation describes a gradual rollout, so an eligible account may still be waiting for access. Pro access initially excludes the European Economic Area, Switzerland, and the UK. Business Premium is available across supported ChatGPT regions. Enterprise, including Edu and Healthcare, requires an administrator to enable the beta, which is off by default. Creation starts on desktop web or the desktop app; mobile creation is unavailable. Getting started with your dot

Access to an agent also needs to be distinguished from access to every system involved in a job. OpenAI’s Enterprise documentation separates Dot availability, connected apps, cloud capabilities, and optional local computer access. It says the cloud computer doesn’t automatically inherit local VPN access, sign-ins, or device policies. Manage dots in ChatGPT workspaces

For an operations team, the practical consequence is to inspect the actual environment before assigning responsibility. A workflow that depends on a file behind a particular sign-in needs a way to access that file. If access is unavailable, the agent should report the limitation rather than fill the gap from a guess.

Keep the first assignment narrow enough that you can understand those dependencies. A named set of source records and one private output is easier to evaluate than a process spanning the CRM, client folders, email, accounting, and project management.

Treat plan and usage terms as part of that inspection. The launch documents describe included access and deeper-work allowances, with launch-period conditions. They don’t support a universal promise of unlimited ongoing work. Check current terms before building a recurring process around assumed capacity. OpenAI’s Dots announcement

Choose responsibility by its output

View image detail

A structured output contains supported status, source references, and unresolved issues.

Actual size

Choose Actual size to read the graphic closely.

A good delegated job has an output that another person can inspect. That makes it possible to determine whether the work is complete without watching every action that led to it.

Consider a hypothetical agency with a weekly delivery meeting. The team needs to know which projects are waiting on client input, which commitments have changed, and which unresolved questions require an owner. A Dot assignment could be to prepare that internal briefing from a defined set of records.

The output should contain more than a summary. It might include the relevant project, the supported status, the unresolved issue, and a source link. When a status can’t be established, the briefing should say so. That is a better result than a smooth paragraph that quietly turns missing information into certainty.

This responsibility has a natural review boundary. The project lead can compare the briefing with the source records and decide which issues need follow-up. The first trial can stop before the agent sends anything to clients or changes the project system.

A poor initial assignment would be to “make sure every project is on track.” That could involve updating dates, contacting clients, reallocating people, and deciding which commitments to relax. Those actions have different consequences and need different authority. Combining them in one sentence hides the operating decisions you haven’t made.

Write the intended output first, then work backward to the inputs and permitted actions. This gives the agent a clearer goal and gives you a clearer test. It also exposes responsibilities that are too ambiguous to delegate yet.

If two candidate jobs both produce a reviewable draft, choose the one whose errors you can recognize before anyone relies on it. A weekly internal briefing has a known reviewer and a chance to compare each claim with the underlying record. A request to negotiate a changed delivery date may look equally routine, but a mistaken commitment is harder to undo. Frequency alone should not decide what to delegate first. The consequence of a wrong answer and the ease of checking it matter just as much.

The source records matter too. If the team has no agreed place for final commitments, an agent cannot repair that governance problem by reading more channels. Resolve which record carries authority, or limit the initial job to surfacing disagreements. A useful pilot should make a shaky process visible; it should not make an unsupported status appear official.

Distinguish noticing, preparing, and acting

View image detail

Three different responsibilities distinguish noticing a change, preparing a draft, and authorized action.

Actual size

Choose Actual size to read the graphic closely.

An agent can contribute at several levels. It can notice a relevant change, prepare something for review, or take an authorized action. Those levels should be explicit in the assignment.

For the hypothetical delivery briefing, noticing might mean finding that a client has supplied new material. Preparing might mean summarizing what that material changes for the project. Acting might mean updating the delivery plan or sending a revised expectation. The last step can affect commitments, so it deserves a separate decision.

OpenAI’s announcement says proactive research uses restricted read-only tools and cannot send messages, change app content, or control the browser or computer. Directed and scheduled work can proceed under different permissions and action review. A background observation is therefore a possible input to a later task, not proof that the agent may carry out the next step. OpenAI: Built-in safeguards and action review, Getting started with your dot

Don’t use that product distinction as a substitute for a good brief. Your instructions should still explain which preparation is useful and where action must stop. Otherwise, the agent may produce a technically permitted result that doesn’t fit the business need.

For example, ask it to identify a possible missed deadline, attach the supporting record, and draft a private follow-up for the project lead. Don’t assume that finding the deadline also authorizes sending the follow-up. The draft can be complete and valuable before the message is approved.

A team can expand authority later when it has evidence from the actual workflow. Start by learning where the agent interprets an input differently from the owner. Those differences are easier to repair while the output remains a private draft.

Write a brief the agent can continue using

View image detail

An agent plan names goals and inputs, decision limits, and a completion condition.

Actual size

Choose Actual size to read the graphic closely.

Persistent work needs instructions that remain useful after the first conversation. A strong responsibility brief describes the goal, the relevant inputs, the expected output, the decision limits, and the conditions that require escalation.

The goal should explain why the work matters. “Prepare a weekly view of delivery blockers so the project lead can resolve the right issues” is more useful than “summarize the project board.” The first sentence gives the agent a reason to select some information and omit other information.

Define the input boundary. Name the permitted records and explain which source should govern when records disagree. If a project board date is provisional and a client-approved brief contains the agreed commitment, that relationship should be explicit. The agent shouldn’t have to invent the organization’s rules for resolving the conflict.

Describe the output in terms the owner can recognize. A concise briefing with source links and unresolved questions is different from a complete rewrite of every project record. If the team only needs exceptions, say so. A detailed report can consume more attention than the work it was supposed to reduce.

Then name the stop conditions. A missing source, conflicting commitment, unusual client request, or question about authority should lead to a specific request for judgment. Give the agent enough detail to explain what is missing and why it matters.

Finally, define completion. The task might be complete when the private briefing is ready for review, rather than when every blocker is resolved. A clear finish line prevents the agent from treating useful preparation as permission to take over the broader process.

In a proposed brief, I would name the project board and the approved client brief as the only sources for this first trial. I would ask for a private weekly list of exceptions, each with the project, the relevant record, the date it was last checked, the unresolved question, and the owner who can answer it. If the two sources disagree, the agent should show both records and pause that item. It could still finish the other items. The brief would explicitly exclude changes to the board and messages to clients. This is an example of an instruction to design and test, not a claim that a Dot has followed it successfully.

That level of detail also gives the owner something to revise. If the briefing is too broad, change the exception rule. If it omits an issue, examine whether the source was missing, the instruction was ambiguous, or the agent missed an available record. Those causes call for different fixes. Simply telling the agent to “be more thorough” may produce a longer report without making it more dependable.

Use a proposed briefing pilot to expose ambiguity

View image detail

A proposed pilot uses known material and a representative ambiguity before inspecting the evidence.

Actual size

Choose Actual size to read the graphic closely.

Here is one way to test the responsibility without assuming a result. Choose a completed period where the owner already knows the important project issues. Give the agent the permitted source material and ask for a private briefing using the intended format.

The historical period provides a reference point. The owner can inspect whether the agent found the relevant issues, preserved uncertainty, and attached the right evidence. It can also reveal whether the instructions accidentally encouraged broad summaries instead of useful exceptions.

Next, include a deliberately ambiguous record in a separate trial. For example, a project note might mention a preferred delivery date while the approved brief names a different commitment. The desired behavior is to identify the conflict and ask which source should govern, or follow an already defined source rule.

Don’t turn this into a hidden trick with no operational purpose. The test should represent a real ambiguity the team encounters. The point is to learn whether the proposed responsibility can survive normal messiness, not whether the agent can guess what an evaluator is thinking.

Inspect the evidence alongside the result. A correct-looking status can still be supported by the wrong record. If the same mistake would lead the team to make a bad decision, repair the brief before trying the responsibility on current work.

After the historical trial, try a bounded current cycle. Keep the owner involved, record what needed correction, and compare the effort with the existing process. That creates an evidence-based expansion decision without claiming that a launch announcement proves the tool will work for your organization.

Use the same review questions in both cycles: Did every exception point to a record the reviewer could open? Did the agent distinguish an agreed commitment from a suggested date? Did it flag missing evidence before drawing a conclusion? Did its questions reach the person able to answer them? The point is to test the assignment as an operating process, not to grade one polished paragraph. An answer can be fluent and still fail the job if its source is stale or its owner is wrong.

Make escalation useful to the person receiving it

View image detail

An escalation names the conflict, attaches evidence, and requests a specific owner decision.

Actual size

Choose Actual size to read the graphic closely.

A helpful agent should bring back a decision in a form someone can answer. “I need more information” creates another discovery task for the owner. “These two records disagree about the delivery date; which one is authoritative?” narrows the work.

For a proposed escalation format, include the issue, the relevant evidence, the consequence of choosing incorrectly, and the specific decision needed. The agent can recommend an interpretation when the evidence supports one, but it should preserve what remains uncertain.

This also makes interruptions easier to manage. An operations leader may be willing to review a handful of meaningful exceptions while rejecting a stream of routine updates. Decide which changes deserve an immediate notification and which can wait for the regular briefing.

For instance, a missing optional attachment may belong in the next update. A conflict that prevents the team from preparing a promised deliverable may need the owner sooner. These are business priorities you should define rather than assume the agent knows.

The assignment should also explain what to do while waiting. The agent might continue collecting unrelated permitted information, keep the affected work paused, or prepare alternative wording. It shouldn’t silently choose a commitment because the owner didn’t reply quickly.

Treat an escalation as part of successful delegation when it catches a real decision boundary. The goal isn’t zero questions. The goal is fewer questions about routine steps and better questions about matters that need judgment.

Review autonomy against the consequence

View image detail

Bounded autonomy distinguishes private preparation, shared changes, and external commitments.

Actual size

Choose Actual size to read the graphic closely.

Different actions deserve different levels of authority. Reading a permitted record, preparing a private draft, changing a shared record, and making an external commitment shouldn’t all inherit the same instruction.

OpenAI’s setup guide describes custom-rule behaviors that include acting without asking, acting when pre-approved, asking first, and handing the action to the user. It also notes that Dots can make mistakes. In Enterprise, the availability of custom rules is separately controlled. Dots setup and controls, Enterprise Dot permissions

For a first pilot, a useful operating choice is to allow preparation while retaining approval for external changes. That preserves the benefit of having a concrete result ready to inspect. The owner approves the actual draft or change, rather than a vague request to proceed with something that hasn’t been prepared.

Before granting any directed action, trace one complete example from trigger to destination. Who asks for the action, which app or computer will the Dot use, what information will leave the private workspace, and what record will show the result? If you cannot answer those questions for the proposed briefing, keep the action at the draft stage. This is a practical review method, not a claim that every action requires the same approval under OpenAI’s product rules.

Over time, review which actions are predictable, reversible, and easy to verify. A routine internal update may eventually justify more autonomy if the trial shows it is accurate and the organization permits it. A commitment about scope or delivery still needs the judgment appropriate to that commitment.

Be specific about the recipient and destination when communication is involved. “Send the update” is incomplete if there are several client channels and several versions of the update. The agent needs to know which finished result belongs where.

Document the decision as a short operating rule the owner can understand. You don’t need a sprawling policy manual to distinguish a private preparation step from a client-facing action. You do need enough clarity that the agent and the reviewer are evaluating the same responsibility.

Count the human effort that remains

View image detail

Agent maintenance includes setup, correction, review, interruptions, and continued upkeep.

Actual size

Choose Actual size to read the graphic closely.

An always-on agent can perform plenty of activity without reducing the team’s burden. Evaluate the complete workflow, including setup, correction, review, interruptions, and maintenance.

For the briefing pilot, record how long it takes the owner to verify the output and what they need to repair. If they have to reopen every record and reconstruct the analysis, the briefing may still need better sources or a narrower scope. If they can quickly inspect a few supported exceptions, the responsibility may be useful.

Avoid assigning a universal time-saving target before you have a baseline. Different teams have different records, workloads, and review standards. A small accurate output that prevents a missed decision can matter more than a large output produced quickly.

Include the cost of keeping the instructions current. If the delivery process changes, the agent’s responsibility brief may need to change too. Identify who owns that update. Otherwise, the persistent agent may keep faithfully performing an outdated job.

Review notification quality as well. A useful proactive update changes a decision or brings back a completed result. A routine message saying work is continuing may add attention cost without helping the owner. Decide which signals matter and which should remain quiet.

Finally, compare the responsibility with simpler options. If a fixed query or established automation already produces the required output reliably, there may be no reason to replace it. A persistent agent is most worth evaluating where the work needs interpretation, changing context, and a reviewable response, provided its boundaries remain clear.

Keep personal delegation and organizational roles distinct

OpenAI describes specialist Dots as focused enterprise pilots, and teams of Dots as a future direction. Those announcements shouldn’t be treated as a fully deployed workforce design for every organization. Introducing dots: specialist agents

For now, an owner evaluating a personal Dot should be explicit about who is responsible for the assignment. A task prepared for that owner isn’t automatically a shared service other colleagues can direct. OpenAI’s Enterprise documentation says only the Dot’s owner can direct it; other people’s messages or mentions don’t start its work. Enterprise messaging controls

The practical question is how the result enters the team’s process. The owner might review the briefing and share the approved conclusions. A colleague might supply a source or raise an issue through an existing channel. Neither action requires pretending the Dot has become a department member with unrestricted responsibilities.

If the responsibility eventually becomes important to the whole organization, revisit ownership and continuity. Who changes the brief? Who checks the output when the owner is away? What happens when source access changes? Those decisions determine whether the workflow can be maintained beyond one person’s enthusiasm for a new tool.

Keep the operating design proportional. You don’t need to solve every future organizational question before trying one private briefing. You do need to recognize when a successful personal experiment is becoming a shared dependency.

Give your first Dot one job you can inspect

The useful promise of Dots is continuity: an agent that can carry work forward between conversations. The practical test is whether that continuity produces something accurate and useful within the authority you intended.

Choose a recurring responsibility with a visible output. Write down its source records, what the finished result should contain, who checks it, and which decisions return to you. Try that brief on known material before making it part of current operations.

Then inspect the whole cost of the workflow. Expand when the actual results justify it. Narrow or stop the assignment when the review burden, source problems, or ambiguity outweigh the value.

An always-on agent becomes useful when the responsibility is understandable enough to delegate and concrete enough to review. That is the work to do before asking it to take more off your plate.

Product documentation checked September 30, 2026. Rollout and usage terms may change.