OpenAI Dots carries maintenance tasks between conversations

A dependency update can appear finished while its most important check still concerns the old dependency. The patch exists, a test command passed, and the person reviewing it still needs to establish what was actually installed. That small gap captures both the promise and the evaluation problem of an agent that carries maintenance work between conversations.

OpenAI announced Dots on September 29, 2026 as a persistent agent experience powered by GPT-6 Astra. Each dot has a cloud computer and can use connected apps. OpenAI describes more than 4,000 apps in its ecosystem and is previewing specialist dots for focused enterprise pilots. The catalog figure does not establish that any particular integration can perform your intended operation. OpenAI’s launch announcement

For SRE and platform teams, continuity could remove repeated briefing and routine handoffs. The useful test is whether it delivers a change a colleague can assess with less effort. A hypothetical dependency update provides a way to follow that work from context gathering to a checked patch without assuming that a broad maintenance request grants authority to release it.

The workspace determines which tests can run

For the dependency update, the model interprets the requested change, the working computer holds files and installed software, and connected apps provide permitted operations. Continuing context can keep the assignment available across conversations. The GPT-6 Astra documentation describes reasoning, coding, computer use, research and document creation, but that range cannot establish which dependency was installed when this task’s tests ran. The workspace supplies the conditions needed to answer that question.

A dot can start tasks in an existing Codex cloud environment. That prepared repository environment is separate from the dot’s own cloud computer: one supplies configured conditions for coding work, while the other is its general working space. Access to a local computer is optional and initially disabled. Setup begins on desktop web or the desktop app, with mobile access available afterward. Getting started with your dot

For a dependency update, that distinction has an immediate consequence. A patch prepared where the team’s tests can run is easier to assess than a proposed fix made in an unspecified workspace. The Codex Cloud environment explainer explains how reusable setup is separated from individual task files. Choosing the environment is part of choosing what a passing test will mean.

Read-only research and action-taking tasks

OpenAI’s safety description separates proactive research from action-taking work. Research uses read-only tools against permitted connections; those tools cannot directly send messages, alter connected app content or control a browser or desktop. Acting on a finding must pass the normal rules and checks. How OpenAI describes Dots safeguards

An already authorized task can also continue between conversations and prepare changes. It may consequently do different work from read-only research even though both are described as happening in the background. A reviewer needs the actual assignment and allowed operations, not just a background status indicator.

For maintenance, the distinction can create a useful progression: gather the request’s context, prepare the authorized change, then let a reviewer decide whether it belongs in the release process. Each stage leaves a different artifact. A report naming the patch, tests or unresolved decision is more informative than a general statement that the agent is busy or finished.

A dependency patch tested against the old version

Consider a hypothetical platform-team pilot updating an outdated dependency in a non-production repository. This example illustrates an evaluation, not a reported Dots deployment or measured productivity result. The goal is to hand a colleague a proposed change whose evidence is straightforward to inspect.

The engineer supplies the repository, dependency, target branch and existing test command. The deliverable is a patch with test output; merge and deployment remain the engineer’s decisions. That gives the dot enough direction to complete useful preparation without letting an open-ended request to maintain a service imply release authority.

Approval of this dependency update applies to the proposed change and the repository state the engineer reviewed. If the branch moves before execution, the patch needs to be reassessed against that new state. The production-agent execution guide develops this bounded-action principle. A Custom Rule can express the intended limit, while repository permissions or protected-branch rules provide an independent enforcement point.

Stage	Useful output	What the reviewer checks
Inspect	Dependency version, affected files and relevant issue links	The sources describe this repository and this request
Prepare	Patch against an identified base commit	The diff stays within the requested update
Test	Command, exit status and complete relevant results	The checks ran against the proposed patch
Review	Proposed change with unresolved failures stated	The result meets the team’s existing acceptance criteria

Now suppose the dot returns a passing test whose output still identifies the old installed dependency. The test may be perfectly valid and irrelevant to the proposed upgrade. Including the installed version and tested revision exposes the mismatch. A reviewer can request the missing check instead of accepting the command’s success as proof about a change it never exercised.

A lost response creates a different uncertainty. If an authorized pull-request creation times out, the repository may already contain the request. Inspect its branch and intended change before repeating creation. When the destination cannot establish the outcome, preserve the unresolved result and bring in the repository owner rather than multiplying possibly completed writes.

Keep the pilot at patch preparation if the team cannot establish target state or enforce the permitted scope. More autonomy is useful when it removes work whose outcome remains inspectable. It is harder to justify when the next permission makes it less clear what happened.

App access and retained information

Dots shares plugin permissions with ChatGPT, ChatGPT Work and Codex, so a new experiment can inherit connections worth reviewing. Custom Rules express action limits; Auto-review checks certain proposed actions against instructions and safety requirements. The documentation distinguishes operations that can proceed, those needing approval, and those requiring human takeover. Dots privacy, security and safety FAQ

OpenAI also describes sandboxed cloud workspaces and action-review controls outside the environment a dot can modify. These address different failure modes. A sandbox can constrain tool and code access while a permitted edit is still wrong. The reviewer must therefore establish both that the task stayed within scope and that the resulting change meets the request.

Retained information needs its own consideration. Disconnecting an app stops fresh access through that connection, without erasing information already incorporated into context. The FAQ says individual dot memories cannot currently be directly viewed or edited. Deleting context and managing separately stored files or ChatGPT memories are distinct operations, so connection removal should not be treated as a universal cleanup action.

An approved test repository and synthetic tickets let a workplace team learn the workflow before supplying sensitive incident records. If organizational rules exclude the data a proposed task requires from that environment, pick a different first task. A useful pilot should answer a workflow question without creating an avoidable information-handling problem.

Account access and task allowances affect the plan

The rollout covers Pro, Business Premium and Enterprise offerings subject to plan, region and administrator conditions. The getting-started page excludes the EEA, Switzerland and UK from the initial Pro rollout, and requires administrator enablement for Enterprise beta access. Access can take several days, so the announcement alone is not evidence that a team can start immediately.

Usage descriptions at publication also require care. The announcement says conversations do not consume ChatGPT limits, while delegated Codex and ChatGPT Work tasks count normally; the help page describes a first-month allowance concession. Check the account’s current terms before budgeting recurring maintenance. Neither description supports planning for unlimited delegated tasks.

Specialist dots are a separate enterprise-pilot offering with organization-managed identities and access. Their demonstrated capabilities should not be assumed available to a personal dot. Match the trial to the access the team actually has.

What continuity buys the next engineer

Use a maintenance request the team already knows how to review, preserving its existing test and release criteria. Count preparation, patch review and correction time alongside the useful work completed. Duration of background activity is a poor substitute for whether another person can accept the result with less effort.

The dependency update should end with a patch against a known revision and test evidence that used the new dependency. That returns the trial to its opening problem. If Dots produces that package with less briefing and correction, continuity has delivered something concrete: the next engineer can make the release decision without first reconstructing what the assistant actually tested.