OpenAI Dots: What Always-On Agents Mean for Operations Teams

At its DevDay event on September 29, 2026, OpenAI introduced Dots. It describes a dot as an always-on agent that keeps work moving across your tools and projects, works between conversations, and reaches out when a decision needs a person. Dots are rolling out gradually to eligible accounts, so not every team can try one today. Source Source

The launch is worth reading closely even if you never use the product. It shows where agent design is heading: away from a chat window you open and close, toward a worker that holds a goal, keeps state, and acts over days. That shift changes what operations teams have to manage. This post separates what OpenAI has documented from what is still a plan, then turns the documented parts into a practical checklist for any always-on agent.

What OpenAI actually announced

OpenAI's documentation says a dot is powered by GPT-6 Astra, lives in the cloud, and has its own computer and browser. It keeps working when your own computer is off. It can research, analyze data, prepare documents and build software, using context from past conversations and your preferences. Source

A few design points matter for operations:

• One dot, many channels. You reach the same dot in ChatGPT, Slack, Teams or a call, and changing channels does not reset its memory. Before sharing information from a private conversation with other people, the dot checks that you have allowed it.

• Work between conversations. The dot tracks progress, decides what needs to happen next, and can pause and wake itself up to continue, so you do not need a fixed schedule for every follow-up.

• Parallel work. It can use background agents to handle several things at once while you keep talking to it.

• Its own notes. It saves notes about your preferences, decisions and ongoing work, which carry across conversations. Source

OpenAI's developer recap adds two items that are easy to miss. Specialist dots, agents assigned specific responsibilities within an organization, are an enterprise preview. Teams of dots working together are described as a future plan, and a Microsoft Agent 365 integration for managing specialist dots is planned, not shipped. Source

TechCrunch's coverage makes a useful point about novelty. Much of this was already possible through Codex and similar agent harnesses; Dots bundles those features into one package focused on independent action. Source

Why "always-on" is a different operating problem

A chat assistant fails in a visible way. You read a wrong answer and you ignore it. An always-on agent fails differently. It may take a wrong action at 2 a.m., repeat it on a schedule, or build on its own earlier mistake because it saved a bad note.

Here is an illustrative example, not an OpenAI scenario. An operations lead asks an agent to watch a shared support inbox, draft replies, and chase suppliers who are late on orders. In a chat tool, every draft passes through the lead. With an always-on agent, the lead has handed over a responsibility. The questions change:

• What can it send without asking, and to whom?

• What does it remember from last week, and who can correct that memory?

• How would anyone know it stalled, looped or went off scope?

• What happens to its work if the lead goes on leave?

None of these are model-quality questions. They are operating questions, and they are the core of what we call AgentOps. If you are new to the term, our AgentOps services page explains how we approach monitoring, evaluation and controls for production agents.

The controls OpenAI documents

To its credit, OpenAI's documentation spends real space on control. Its description of action review is a good template for what any team should ask of an agent platform.

Before a dot takes an action that could affect your accounts or share information, an automatic review checks it against your instructions, permissions, custom rules and built-in safety requirements. The review decides whether the action can proceed, needs your approval, or includes a step you must do yourself. The documentation's example is changing a password, which you must do yourself. Source

Two details stand out. First, scope matters: the documentation says asking a dot to draft replies does not give it permission to send them, and that a specific instruction can cover future actions within its scope, while an action outside that scope needs another decision. Second, custom rules come in four settings: take action without asking, take action when you say so, ask before taking action, and hand off to you. The documentation adds that rules are instructions the dot tries to follow and that it can make mistakes. They do not grant access to an app or computer and do not override built-in safety requirements. Source

That last sentence deserves a pause. A rule is a boundary the agent tries to respect, not a technical guarantee. For low-stakes work that is fine. For anything that moves money, contacts customers or changes records, you still want enforcement outside the agent: scoped credentials, approval steps in the systems themselves, and logs you control.

Separate the connections

One of the clearest parts of OpenAI's documentation is a table of connection types. A messaging channel lets you talk to your dot and receive updates. A connected app or plugin lets it use that service within its permissions. A local computer lets it work with that machine's files and apps while the machine is available. Connecting a messaging channel does not connect your inbox, other apps or your computer. Source

This separation is a pattern worth copying in your own agent designs. Teams often give an agent one broad service account because it is faster to set up. Splitting access by purpose, so that "can talk to the team" never implies "can read the finance folder", limits the damage when an instruction is misread.

OpenAI also notes that a dot's cloud computer is separate from your devices and their signed-in browser sessions, and that logging in to a website happens through a private sign-in flow outside the conversation. Using a saved login for a new sign-in requires your confirmation. Source

What admins get

For companies, the workspace documentation is the more interesting page. Dots access is off by default for Enterprise. Separate permissions cover joining Slack or Teams, using local files and commands on a member's computer, and letting members add or edit rules. Cloud computer settings control browser use, internet access for code run on cloud computers, and desktop interaction, with a separate control for the password manager. Source

The same page says enabling dots does not grant access to every app or website, and that only a dot's owner can direct it: other people's direct messages or mentions do not start work for that dot. In a channel, though, other members can see what a dot posts. Source

Those are sensible defaults. They also show the shape of the work ahead for admins: decide who gets access, which capabilities each group gets, and what the agent may see in shared spaces.

A readiness checklist for any always-on agent

Whether you test Dots or build on another platform, the same questions apply. This is our checklist, based on the controls above and our own practice, not an OpenAI requirement.

1. Write the job as a scope. State who the agent can contact, what it can change, and what needs a person. "Handle supplier follow-ups" is not a scope. "Send reminder emails to suppliers on our approved list; never agree to price or date changes" is.

2. Start read-only. Let the agent research and draft for a week. Compare its drafts with what your team would have done before granting any send or write access.

3. Enforce outside the agent. Use scoped API keys, spending limits and approval steps in the target systems. Treat the agent's own rules as a second layer.

4. Make memory reviewable. If the agent keeps notes, someone should be able to read them, correct them and delete them.

5. Log actions, not only messages. You need a record of what it did, with timestamps and the inputs it used, to investigate an incident.

6. Define a stop procedure. OpenAI's documentation distinguishes pausing a dot, stopping a delegated task and canceling a schedule, and says they have different effects. Know the equivalent for your agents before you need it. Source

7. Name an owner. A specific person should be responsible for each agent, including when they are away.

Where this fits for Codesprint clients

We see two common situations. Some teams want an always-on agent for internal operations, such as reporting, triage or document preparation. Others are embedding agents into products, where an agent's behavior becomes part of a customer's experience. The checklist above applies to both, but the stakes differ. Internal agents need clear scope and review. Product-facing agents also need evaluation sets, regression tests when the underlying model changes, and a plan for incidents.

It is also worth being honest about what a launch like this does not tell you. OpenAI's documentation describes capabilities and controls. It does not tell you how a dot will perform on your suppliers, your tickets or your data. The only way to learn that is to run a small, bounded pilot, measure outcomes against your current process, and decide from the results. If you want help designing that pilot, get in touch.