OpenAI Engineer Tests DOTS: How a Persistent Cloud Agent Takes Over On-call

OpenAI engineer Ali demonstrated the engineering use of DOTS (internal codename) on the official channel. Its positioning is clear: a persistent cloud agent that has its own cloud computer, can also access your local machine, and has its own identity in services like Slack. In Ali's words, this combination unlocks a new way of collaborating—not you calling the AI, but the AI proactively catching the work you don't want to do.

What DOTS Is: A Cloud Agent with Identity That Works Across Devices

The core design of DOTS can be broken into three parts. First, it runs in the cloud and has its own cloud computer, meaning tasks don't depend on whether your local device is powered on. Second, it can access your local computer, which lets Codex sessions actually execute code and run builds on your laptop. Third, it has an independent identity in services like Slack, so you can @ it in any thread just like you would @ a colleague.

The first step in Ali's demo was to click on his DOT in the Codex app and connect it to Slack. Once connected, DOTS gained a Slack identity and could be named and assigned tasks in any thread.

This combination of "identity + cross-device" is the key thing that distinguishes it from ordinary chat-style agents. An ordinary agent is conversational: you open a window, ask a question, get an answer. DOTS is resident; it stands by in the background, and when triggered, it decides for itself which machine and which tool to invoke.

Setting Up On-call Automation with a Single Prompt

The workflow Ali showed revolves around his own on-call duty. He typed an instruction into Composer: monitor the channel, do initial triage on any incoming page, and create a thread to investigate. After sending it, the automation took effect.

The prompt itself is plain—no complex orchestration, no scripts written. Its value lies in turning "on-call response"—a high-frequency, repetitive action that must be timely—into a continuously running background task.

For on-call engineers, what really drains energy is often not the fix itself, but the stretch of troubleshooting between being woken up by a page and figuring out "what exactly went down." Ali's automation outsources precisely this upfront work.

On-call and page

On-call is a common rotation system in SRE/ops and infrastructure teams: during a fixed period, a particular engineer is the first responder for system alerts and may be woken up at any time to handle an incident. A page refers to a notification actively pushed to the on-call person's phone or instant messaging tool through alerting platforms such as PagerDuty or Opsgenie, usually meaning an online service has an anomaly affecting users. The on-call process generally includes acknowledgment (ack), triage, escalation, and postmortem; triage requires quickly determining the scope of impact, suspicious changes, and the responsible team. This kind of work is high-frequency, repetitive, and sensitive to response latency, making it very suitable for a resident agent to handle the upfront investigation while leaving the final decision to a human.

A Real-World Test at 3 AM: Completing Triage on Mobile

Ali recounted a recent real experience. At 3 AM he received a page on his phone; he picked up the phone to acknowledge it, then opened the ChatGPT app to check on DOT's progress. By then, DOTS had completed the investigation, located the problem, and created a Codex thread for him to enter, continue guiding the investigation, and send follow-up messages.

The key detail: this Codex thread actually runs on his laptop, and all messages are synced to the laptop. That is, he didn't need to get up at 3 AM and open his computer; the investigation was already running on the machine, and he only needed to confirm and push it forward on his phone.

In this case, the problem was ultimately resolved on the phone. But if deeper investigation were needed, he could put down the phone, walk over to the laptop, and see the same Codex thread continuing to be available locally. The switch between cloud identity and local execution is seamless—this is also the most noteworthy point of DOTS's architecture.

Codex and Codex thread

Codex is the product form of OpenAI's coding agent, capable of reading code repositories, executing commands, modifying files, and running tests in a controlled environment. It often organizes work as "threads": a thread corresponds to the context of a task that can be continuously followed up on, including historical messages, tool-call records, and the current workspace state. The value of a thread lies in being recoverable and resumable—a person can enter the same thread at any time to continue guiding it without having to re-describe the background. When a thread runs on a local laptop, code, credentials, and the build environment do not have to leave the machine; the cloud agent is only responsible for triggering and forwarding messages, which is the technical precondition for the seamless switching between phone and laptop described in the article.

Broader Uses: From Feedback Triage to Writing PRs in Slack

Ali stressed that this is just a small example. By setting up automation with a simple prompt, more scenarios can be covered: for example, triaging all incoming feedback in a specific channel, or @-mentioning DOTS in Slack to have it create a PR and iterate on changes directly with it in Slack.

The common thread across these uses: the trigger point is where the engineer already is (Slack, phone, ChatGPT app), execution happens in DOTS's own environment, and the human only needs to make judgments and steer at key moments. It shifts the "context-switching cost" from the human to the agent.

It should be noted that these capabilities currently come from a self-reported demo by an OpenAI internal engineer, with a single source; no third-party independent verification or public details on availability, pricing, or permission models have been seen yet. For those following the engineering adoption of agents, the direction DOTS demonstrates—persistence, cross-device, identity—is more worth tracking than specific features.

PR and iterating in chat tools

A PR (Pull Request) is a merge request on a code collaboration platform: after a developer submits branch changes and opens a PR, it goes through review, discussion, and CI checks before being merged into the main branch. Traditionally, creating and modifying a PR must be done in an IDE or code hosting platform, whereas @-mentioning an agent in Slack to create a PR means compressing "describe the requirement—generate the change—submit for review" into a conversation flow. This pattern depends on the agent having repository write permissions, being able to run tests, and returning results in a reviewable form; it also raises issues such as permission boundaries, audit records, and ownership of review responsibility, which are essential to examine when evaluating whether such persistent agents can enter production processes.

One-line Summary

OpenAI demonstrates persistent cloud agent DOTS: independent identity and cross-device on-call triage

Paragraph Summary

The article introduces DOTS, an internal agent system demonstrated by OpenAI engineer Ali on the official channel. It is positioned as a persistent cloud agent: it has its own cloud computer, can access the user's local machine, and has an independent identity in Slack, allowing it to be @-mentioned and assigned tasks like a colleague. In the demo, Ali used a single prompt to set up on-call automation that monitors a channel, performs initial triage on pages, and creates investigation threads. During a real alert at 3 AM, DOTS completed the investigation and created a Codex thread before he got out of bed; the thread actually runs on his laptop, so he only needed to confirm and push it forward on his phone and switch back seamlessly locally when deeper work was needed. Other uses include channel feedback triage and creating and iterating on PRs in Slack. The article also notes that this information comes only from an internal demo, lacking third-party verification and details on pricing and permission models.