OpenAI dots: what to check before delegating one project

An assistant that can keep a project moving

OpenAI announced dots on 29 September: always-on agents with their own cloud computer, a browser and access to apps the user connects. The announcement describes conversations through ChatGPT, Slack and Teams, alongside work that can continue without directing every step. [1]

For a small team, the adoption question is whether handing over a bounded project produces work worth reviewing—not simply whether the assistant stays online. OpenAI’s example of turning customer feedback into tested fixes and reviewable pull requests suggests one possible use. It is a vendor example, not evidence that your repository or workflow will get the same result. [1]

Check access before planning around it

The launch says dots are rolling out to Pro and Business Premium users in eligible markets. Enterprise users, including Edu and Healthcare, can try the beta when their workspace admin enables it. That is a rollout announcement, not confirmation that a particular account has access. Check your plan, market eligibility and workspace settings before assigning a project. [1]

Specialist dots are a separate preview: dedicated organizational responsibilities, starting with focused enterprise pilots. Do not treat those pilots as generally available features of a primary dot. [1]

Background research is not the same as delegated action

OpenAI calls the background help performed when you are not actively working with a dot “proactive research”. It uses connected apps through read-only tools: those tools cannot send messages, change app content, or control a browser or computer. This restriction applies to that research mode—not to all dot activity. The same announcement describes dots doing work through their own computer and connected apps. [1]

The controls also have different jobs. You choose connected apps and their permissions. Custom Rules let you allow actions, require approval or block them; built-in safety requirements still apply. Separately, auto-review checks actions that could affect accounts or share information against instructions, rules and safety requirements. It is not a promise that every action waits for your approval. Sensitive tasks such as changing a password remain with you. OpenAI says to review consequential work because dots can still make mistakes. [1]

Included access is not unlimited project work

According to the launch, the first dot is included in Pro or Business Premium at no extra cost. Those plans also include an allowance for deeper work, with extended limits for the first month after launch. Conversations with a dot do not count toward ChatGPT usage limits, but tasks it starts or manages in Codex or ChatGPT Work count toward usage limits as usual. [1]

Before a trial, check both the deeper-work allowance and the limits of the task service you intend to use. The launch does not supply numerical allowances in the passages reviewed here. Do not budget from “24/7” or assume launch-period limits will persist. Account-specific availability and current usage terms remain checks for the adopter.

Proposed trial: one issue to a reviewable patch

If access and allowances fit, try one non-sensitive bug in a test repository before connecting a wider workload. This is PALANTHOS’s proposed evaluation, not a tested dots procedure or a claim that every integration supports it.

• Define the handoff: one issue, a reproduction, a proposed patch, test results and an explanation of remaining uncertainty. Name a human reviewer and stop before merge or deployment.
• Inspect the actual app permissions and action controls. Grant only the access needed for the test; do not proceed if you cannot establish the intended boundary. Keep unrelated accounts and production systems out of scope.
• Record the applicable allowances before starting, then inspect reported task usage, requests for approval and any assistance needed. Stop if access must expand beyond the agreed scope or usage cannot be understood.
• Have the reviewer reproduce the bug, inspect the diff and rerun relevant tests. Compare the accepted result and review effort with your existing issue-handling process; an activity log alone is not a successful fix.

Continue only if the patch is useful and the supervision and usage are acceptable to your team. If the task can already be handled well through your existing coding assistant, that remains a reasonable alternative. This announcement establishes a new option to evaluate, not a demonstrated productivity gain.