Dots (OpenAI Always-On Agents)

Dots are OpenAI’s always-on personal agents, introduced at DevDay on September 29, 2026. Where a chatbot waits for you to type, a Dot has a standing goal and keeps working on it: each one runs on its own cloud computer with its own browser, connects to the apps you allow, and comes back with finished work, sometimes before you think to ask. Dots are powered by GPT-6 Astra, OpenAI’s frontier model built for sustained computer use, and they are reachable from ChatGPT on desktop, web, and mobile, and from Slack and Microsoft Teams. They are the most visible commercial example so far of what the field calls an ambient agent: an agent that listens to a stream of events and acts on its own, instead of being driven turn by turn.

From Chat to Ambient

A normal assistant has a simple lifecycle: you send a message, it responds, it goes idle. All initiative sits with the human, which means the human is the bottleneck. LangChain’s “ambient agents” framing, published well before Dots, describes the alternative: agents that listen to an event stream, act on multiple events at a time, and only pull a person in when a decision genuinely needs one. The interaction patterns it names are notify (flag something important without acting), question (ask for missing information), and review (propose an action for approval).

The practical shift is from prompting to delegating. You describe an outcome and the boundaries around it, and the agent decides when to act.

How a Dot Works

Reporting on the launch describes the same components that most agent harnesses share, packaged as a product:

• A cloud computer per Dot. Dots operate on isolated cloud machines unless you connect your own apps, and users can optionally connect personal machines for extended reach. This is the same computer-use idea behind a computer-use agent: the model sees a screen and clicks, types, and browses.
• A large connector surface. OpenAI says the plugin ecosystem behind Dots covers more than 4,000 apps, plus Slack and Teams.
• Standing goals and triggers. A Dot monitors for changes, such as new data or a scope update, and takes corresponding actions like rerunning an analysis or flagging an item for review.
• Feedback that sticks. Dots are described as learning from feedback over time, which makes durable AI memory part of the product, not an add-on.
• Delegation to coding agents. Work a Dot hands to Codex (for example bug triage or pull-request review) runs as its own task.

%%{init: {'theme': 'base', 'themeVariables': { 'edgeLabelBackground': '#FFFFFF', 'lineColor': '#818CF8' }}}%%
graph LR
    subgraph TRIG["Triggers"]
        A["Standing goal"]
        B["New data or message"]
        C["Schedule"]
    end
    A --> D["Dot on its own<br>cloud computer + browser"]
    B --> D
    C --> D
    D --> E["Proposed action"]
    E --> F{"Your rules:<br>allow / ask / block"}
    F -->|allow| G["Runs in the app"]
    F -->|ask| H["Approval request to you"]
    F -->|block| I["Refused"]
    H -->|approved| G
    G --> J["Activity View"]
    J -->|your feedback| D

    classDef default fill:#ffffff,stroke:#4338CA,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef data    fill:#EEF0F7,stroke:#0D9488,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef process fill:#F7F8FC,stroke:#6366F1,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef output  fill:#4338CA,stroke:#4338CA,stroke-width:2px,color:#ffffff,rx:8px,ry:8px;
    class A,B,C data;
    class D,E process;
    class G,J output;

The Permission Model: Allow, Ask, Block

An agent that acts unprompted is only usable if you can bound what it does. The Dots design centers on user-defined rules in three tiers: actions the Dot can take on its own, actions that need your approval first, and actions it must never take. OpenAI also describes an automatic review step that checks proposed actions against your instructions and safety rules before they affect accounts or share information, and an Activity View that shows progress, including background work. Reporting on the launch says sensitive tasks such as changing a password always stay with the user.

The central design tension is a trade-off a reader would otherwise have to take on faith. Set the autonomy bar low and the Dot interrupts you constantly, so you stop reading the approvals and click through them (approval fatigue). Set it high and the Dot acts on your behalf in ways you never saw. The widget below lets you feel that trade-off with a day’s worth of sample actions.

Building the Same Pattern Yourself

Dots are a hosted product, but the underlying architecture is one you can reason about (and build) with any agent framework. The core is an event loop that wakes on triggers, asks the model for a proposed action, routes it through a policy, and parks anything uncertain in a queue for a human.

# Scenario: a support-ops agent that wakes whenever a new ticket arrives, drafts
# work on its own, and only escalates the actions your policy marks as ASK.
# (A pattern sketch; it uses the decide() policy from the example above.)
import asyncio

approval_queue: asyncio.Queue = asyncio.Queue()

async def handle_event(event, agent, executor):
    proposed = await agent.propose_action(event)       # model decides what to do
    verdict = decide(proposed)                         # allow / ask / block
    if verdict == "allow":
        result = await executor.run(proposed)
        await log_activity(proposed, result)           # your "Activity View"
    elif verdict == "ask":
        await approval_queue.put(proposed)             # human reviews later, in batch
    else:
        await log_activity(proposed, "refused by policy")

async def main(event_stream, agent, executor):
    async for event in event_stream:                   # webhooks, inbox, schedule ticks
        asyncio.create_task(handle_event(event, agent, executor))

For teams building their own ambient agents, OpenAI’s DevDay announcements also included an expanded Agents API for managed computer use, tool selection, multi-agent orchestration, and context management, alongside a Decisions API that returns fast multiple-choice classifications for routing. That second piece is a close cousin of JEV and decision models: a cheap model that answers a bounded question can sit in front of the expensive agent and decide whether it needs to wake up at all.

# Scenario: don't wake the expensive agent for every inbox event. A small
# classifier answers one bounded question first. (classify_cheap is a
# placeholder for any fast, low-cost model call.)
async def should_wake_agent(event) -> bool:
    answer = await classify_cheap(
        question="Does this message need action from the agent?",
        options=["ignore", "notify_only", "act"],
        state=event.text,
    )
    return answer in ("notify_only", "act")

Security: Autonomy Raises the Stakes

A chat assistant that gets tricked produces a bad paragraph. An always-on agent with a browser, a logged-in session, and 4,000 connectors that gets tricked can act. The risks to design around:

• Prompt injection. A Dot reads email, web pages, and documents it did not write. Any of them can contain instructions aimed at the agent. OpenAI says Dots include security monitoring against malicious instructions, but the safest posture assumes injection will sometimes succeed and keeps blast radius small through the allow / ask / block tiers.
• Confused authority. An action can look routine (“send this file to this address”) while the recipient was chosen by an attacker. Review-before-send for anything that leaves your accounts is the standard defense.
• Silent drift. A background agent that gradually changes how it works is harder to audit than a one-shot chat. Activity logs and periodic review are part of the product for a reason.
• Shadow AI. Employees connecting personal always-on agents to work apps creates ungoverned access. Business, Enterprise, and Education workspaces get admin-controlled availability, and OpenAI states their Dots content is excluded from model training by default.
• Honest limits. OpenAI itself cautions that Dots can still make mistakes and that consequential work should be reviewed, which is why human-in-the-loop checkpoints remain the core design, not a temporary crutch.

What’s New (2025-2026)

• Launch (September 29, 2026). Dots ship at DevDay for ChatGPT Pro and Business Premium in eligible markets, with a beta for Enterprise, Education, and Healthcare. Each user gets one Dot at launch, included in the subscription, with multiple Dots and Microsoft Agent 365 integration described as roadmap items.
• Usage accounting. A Dot’s own conversations do not count against ChatGPT limits, but tasks it starts in Codex or ChatGPT Work do.
• A wider agent platform. The same event introduced an expanded Agents API, a Decisions API running on a smaller model for fast classification, shared Spaces and Pages for human-agent collaboration, and a B2B marketplace that lets enterprises apply OpenAI compute commitments to open models.
• The local-first alternative. Open-source agents such as OpenClaw and Hermes Agent offer the same always-on shape on your own hardware, trading managed convenience for control over where data and credentials live.
• Governance catches up. Enterprise tooling for inventorying agents, tracking their KPIs, and tiering them by risk (for example Dataiku’s Agent Management, announced September 24, 2026) is arriving alongside products like Dots.

When a Dot Is (and Is Not) the Right Tool

Dots fit work that is recurring, interruptible, and tolerant of review: triaging an inbox, keeping a tracker current, monitoring a data source, drafting first-pass responses. They are a poor fit for anything irreversible and high-stakes where a wrong action cannot be undone, or where the approval overhead exceeds the work saved. A useful rule of thumb from the widget above: start with a low auto-run threshold, watch the Activity View for a week, and only raise autonomy for action types that you have never once needed to correct.

# Scenario: you are giving a background agent access to email, Slack, and a
# billing tool. Every action it proposes is classified into one of three
# tiers BEFORE it runs. This is the pattern Dots expose in product form;
# it is a generic sketch, not OpenAI's API.
from dataclasses import dataclass

ALLOW, ASK, BLOCK = "allow", "ask", "block"

POLICY = {
    "email.summarize":      ALLOW,
    "email.draft_reply":    ALLOW,
    "email.send_reply":     ASK,    # leaves your account, so a human sees it first
    "slack.post_message":   ASK,
    "sheet.update_cell":    ALLOW,
    "purchase.create":      ASK,
    "account.change_password": BLOCK,
    "bank.transfer":        BLOCK,
}

@dataclass
class Proposed:
    kind: str
    args: dict

def decide(action: Proposed) -> str:
    # Unknown actions default to ASK, never ALLOW: new capabilities start supervised.
    return POLICY.get(action.kind, ASK)

assert decide(Proposed("email.summarize", {})) == ALLOW
assert decide(Proposed("bank.transfer", {"amount": 500})) == BLOCK
assert decide(Proposed("calendar.delete_all", {})) == ASK