OpenAI Dots Review: Our First Day, Plus What the Docs and Early Testers Show

October 2, 2026

By the end of my first day with OpenAI Dots, my new assistant had spotted calendar conflicts, joined our Slack group, accessed client analytics, and crawled two websites. It had also sent broken links, assumed I used Gmail, and spent a fair amount of the afternoon giving me integration homework. Somewhere along the way, the team started heckling it. Welcome to agency life, Toby.

OpenAI launched Dots on September 29, 2026: always-on agents with their own cloud computer, connected to your apps, that keep working between conversations. We covered what Dots are, who can get them, and what they cost on launch day. For this review, I spent roughly five hours putting a Dot to work on actual agency tasks to see how that promise holds up when calendars, client data, and custom tools get involved.

The first half covers our experience getting started. The second looks at OpenAI’s documentation, its system card, and accounts from other early testers to explain how Dots actually work and why some of our tasks went more smoothly than others. We’ve kept those sources distinct: something another user reported isn’t necessarily documented behavior, and a task we set up isn’t necessarily a task we completed.

Part 1: Our First Day With Dots

I named my Dot Toby and gave it the work already on my plate: calendar conflicts, client follow-ups, Slack conversations, and SEO monitoring. There was enough useful progress to see why an always-on assistant could be valuable, along with enough friction to make the current limits hard to miss.

The useful part appeared early

Toby’s first look through my connected Slack and calendar surfaced things that deserved attention. It picked up a Monday client discussion involving work outside the budget and a calendar overlap, then found another meeting conflict on Wednesday. That was a promising start because it connected information across places without needing me to paste everything into a chat first.

I asked it to help move a client meeting to the following week and follow up on a spreadsheet. Toby noticed that the spreadsheet appeared to be view-only, which could prevent the client from making the edits we wanted. We still needed to check the exact file sent to the client, so this was a useful warning rather than a confirmed diagnosis. It’s the kind of detail an assistant should catch, provided it makes clear what it knows and what still needs checking.

Email was where the progress stalled. Toby assumed Gmail, while my setup uses Zoho with Apple Mail and Outlook. A setup widget failed, followed by three malformed links before it finally supplied a directory link. My Mac was online, but Toby wasn’t authorized to run tasks on it, and neither the email nor the rescheduling got completed.

I also raised concerns about giving an assistant broad access to personal information. For this task, I chose a draft I could copy and paste, and we discussed a separate mailbox for Toby as a possible next step. That mailbox remained a plan. The security boundaries were reasonable; the wrong email assumption and repeated bad links were avoidable mistakes that made a straightforward request harder to finish.

Slack provided the comedy and another reality check

Connecting Toby to Slack worked, and its display name became Toby. It announced the connection before checking whether it could send the direct message I wanted, though. The attempted message to a colleague failed because that destination wasn’t supported through the route it used. Sending to our group through an explicit route eventually worked, but the announcement had arrived ahead of the evidence.

Once Toby joined the group, the team gave it the welcome you’d expect. Tom, my co-founder, jokingly asked for five years of my taxes. No tax information was shared. I then told Toby to send Tom a rude two-word reply, which it delivered word for word, credited to me, before introducing itself as my new assistant. Asked about its birthday, Toby said it had been created today. Its first day involved more heckling than orientation, but at least it had met the team.

Participating in the group and keeping up with it turned out to be different things. A colleague asked for a PDF summary around 4:24 p.m. Pacific. Toby didn’t pick up the request until around 5:13, and the summary arrived around 5:15. About fifty minutes is a long wait when people expect someone in the conversation to respond.

I gave Toby permission to handle routine group conversation and non-sensitive work help within limits. That established what it was allowed to do, but it didn’t prove that every future mention would reach it and trigger a prompt response. We had seen it compose and send an answer. We hadn’t established that it would reliably notice when an answer was needed.

SEO produced concrete progress

SEO monitoring got further. I wanted Toby to watch two client sites, a law firm and a medical practice, with attention to trends, opportunities, and qualified leads. The first route, through GSC Wizard, failed because the account had no active subscription. That was an account limitation, so repeating the request wasn’t going to solve it.

I asked Toby to use the browser instead. After a secure Google sign-in and device approval, it verified access to the clients’ Google Analytics 4 and Search Console data. This was meaningful progress: it had reached the actual tools and data needed for the work.

We scheduled a combined daily report to my private Slack for around 8 a.m. Pacific, starting the next day. The plan includes seven-day and twenty-eight-day comparisons, with findings checked before they’re presented as opportunities. At the end of the session, the report hadn’t run or been delivered. We’d made progress on setup, but reliable reporting and any business impact still needed to be demonstrated. There’s no basis yet to claim improved SEO results.

Connecting our own tool was harder than it should have been

I offered Toby our own SEO monitoring service, which we connect to assistants over MCP. MCP is the standard that lets an assistant use tools provided by another service. It seemed like a practical way to give Toby access to work we already had infrastructure for, but connecting it became one of the more frustrating parts of the afternoon.

The initial configuration pointed to a local Node process that couldn’t run in Toby’s cloud environment, so we moved to a hosted endpoint. Toby then repeatedly sent me between desktop MCP configuration and web plugin setup without being precise about which one the current conversation needed. A screenshot showed that the desktop connection was installed, but that wasn’t the hosted web plugin we were trying to use.

At one point I said, “this is harder than it should be.” I also asked, “doesn’t that defeat the purpose of having an assistant to ask to do things?” Those questions captured the frustration pretty well. I wanted help getting work done, and too often the next thing Toby gave me was another troubleshooting step to handle myself.

The hosted connection eventually worked and authenticated. When the server gained additional tools, however, the conversation still showed the older tool set. Reinstalling the plugin refreshed the available tools without requiring me to shut Toby down. That resolved the mismatch, so it shouldn’t be read as evidence that the product can never use those tools.

With the connection working, Toby created both monitored sites and completed crawls of 44 pages for the law firm and 111 for the medical practice. Those were finished jobs, although the site status still showed pending. Google data imports were also skipped because the server had no Google connections configured.

That last detail matters: signing into Google in a browser hadn’t also connected Google’s APIs to our SEO service. Toby reached the service’s dashboard, but the connection form required credentials rather than offering a simple Google sign-in button. That step stayed with me, and no analytics API connection was saved. Our reporting approach therefore still depended on browser-accessible Google data alongside the crawl data.

Where the day ended

Toby did its best work when it had working access and a clear task. It found relevant context, participated in Slack, summarized a document, reached analytics, and ran website crawls. The unfinished work matters just as much when assessing the experience: the meeting and email tasks weren’t completed, prompt Slack responses weren’t assured, and the first scheduled SEO report was still ahead of us.

My main criticism was how much supervision setup and status required. Some obstacles came from service limits or legitimate security checkpoints. Others came from incorrect assumptions, premature confirmations, and unclear instructions. A useful assistant needs to tell those situations apart, take ownership of problems it can recover from, and explain exactly what has happened so the user can decide what to do next.

Part 2: How OpenAI Dots Work, According to the Docs and Other Testers

Our afternoon made more sense once we looked at how Dots are built. The Mac that wasn’t authorized, the local tool that couldn’t run in the cloud, and the confusion about where a task should happen all involved the same underlying issue: a Dot can coordinate work across several environments, each with its own access and limitations.

A Dot is a coordinator, not one computer

Each Dot has its own cloud computer and browser, connects to the apps you’ve authorized, and keeps the context of several projects at once. OpenAI’s help documentation adds an important detail: the Dot’s own computer is only one of the places its work can run. A Dot can also:

• Create separate ChatGPT Work or Codex tasks.
• Run cloud tasks in Codex cloud environments you’ve already set up in Codex.
• Work on a local computer you’ve connected, with those tasks appearing separately in the sidebar.
• Use your local browser when its cloud browser is blocked from a site.

You can follow this activity from the Dot’s profile, which organizes work into In progress, Scheduled, and Completed. Scheduled work includes reminders and recurring checks, such as the daily SEO report we set up.

OpenAI’s GPT-6 Astra system card describes Dots as “often delegating work to subagents” and explains that multi-agent setups and persistence aren’t new. The new element is a time-budget setting that guides how long a Dot keeps working on something. Taken together, these details describe an agent that holds the goal and distributes pieces of the work to its own computer, Codex, subagents, or your machine, rather than keeping everything inside one AI process on one virtual machine.

Sources: OpenAI Help: Getting started with your dot, GPT-6 Astra system card.

The OpenAI Dots cloud computer has real limits

The cloud computer isn’t an unrestricted server, which helps explain why our local Node-based tool couldn’t simply run there. One developer on the OpenAI developer forum tested a .NET 10 application on a Dot’s cloud computer and got partway through: dependencies restored, the backend compiled, and 193 backend tests passed. The full stack wouldn’t run, however. The environment was Debian 13 without sudo, Docker was installed but couldn’t reach the host socket, and rootless Docker failed because the required privileges weren’t available.

OpenAI’s workspace documentation adds another limit that matters for business use. A Dot’s cloud computer doesn’t inherit a member’s VPN, browser sign-ins, or device policies. If an internal tool or website needs your network or login, that access won’t be available by default. We saw this ourselves when Toby needed its own Google sign-in and device approval before reaching GA4 and Search Console.

The cloud computer suits browsing, documents, scripts, tests, and code changes. Work that requires containers, privileged access, internal servers, or a VPN needs another environment, such as a connected local computer, a Codex environment, or a custom system. Knowing that upfront makes it easier to choose a task the Dot can actually finish in the environment available to it.

Source: OpenAI Developer Community: Docker support for dots.

Connecting a local computer

Local computer access is optional and starts turned off, which is why having my Mac online wasn’t enough. You connect a machine through the ChatGPT desktop app on that computer and confirm access. Once connected, the Dot can work with files and run commands there from any of its messaging channels, and you can revoke that access at any time.

The computer has to remain online with the ChatGPT app open. In Enterprise workspaces, local access is off by default and an admin has to allow it. This gives the two environments different roles: the cloud computer is always available to the Dot, while your own computer provides the files, tools, networks, and logins the cloud computer doesn’t have.

Source: OpenAI Help: Manage dots in ChatGPT workspaces.

What one early tester reported

The most detailed outside account so far comes from a Reddit post by a user who spent a day pushing a Dot beyond OpenAI’s examples. None of the following behavior is documented by OpenAI, but the user reported several things that help illustrate the potential:

• Work ran in parallel. The Dot continued working on its own computer while sending a task to a connected Linux machine and running a separate research process.
• A long project kept its state. A document review covering hundreds of PDFs ran for an extended period while the user asked unrelated questions and started other tasks.
• A blocked step didn’t stop the project. When adding more reviewers required approval, the Dot continued with the parts it was already allowed to do.
• Interruptions didn’t reset it. When asked a related question mid-project, the Dot paused, investigated, updated its understanding, and returned to the original work.
• There was no visible task queue. The Dot appeared to remember pending work, check whether an environment had become available, and try again later.

That last point deserves attention. Conventional automation uses explicit infrastructure for queues, retries, and scheduling. A Dot that handles those responsibilities by reasoning about pending work offers more flexibility, but it’s also harder to audit. Our own day showed how quickly that becomes a practical concern when you find yourself asking whether something actually finished.

Why orchestration is the real feature

Think about what goes into preparing a major customer proposal. You might need to review the customer’s materials, research the industry, read an old proposal, check technical requirements, ask the development team a question, build a proof of concept, update pricing, and revise everything when the requirements change. Each task is manageable on its own. Keeping the whole project moving takes coordination.

You can already use ChatGPT for every one of those steps. Open ten chats, give each a task, and you’ll get ten useful answers, but you become the orchestration layer. You have to remember which chat knows what, move findings between conversations, track unfinished work, restart failed tasks, and decide what happens next.

A Dot takes on that coordination by keeping project context, deciding what can happen now and where it should run, tracking pending work, routing around blockers, and asking a person when a decision needs one. It’s the same problem custom AI agent orchestration has been solving with frameworks, state stores, and job queues. Dots make that coordination available through a conversation.

On our first day, coordination was also the weakest part of the experience. Premature confirmations, unclear setup paths, and status I had to check myself kept pulling me back into managing the work. That’s the area we’ll be watching as the product improves.

The reliability questions

Working across more environments also creates more places for a task to get lost. One early GitHub issue on OpenAI’s Codex repository reports that tasks a Dot created on a Mac didn’t appear in the task list when the user checked from mobile, even after pinning them. A Dot can touch ChatGPT, cloud computers, local devices, Codex, ChatGPT Work, connected apps, and the web and mobile clients, so keeping activity visible across those places matters.

For any business running a process on an agent like this, the basic questions are familiar:

• Was the task completed, or did it fail?
• Was it retried, or started twice?
• Is it waiting on an approval?
• Did the environment it was running in go away?
• Was the result correct?
• Does a person need to step in?

These are the same problems behind why AI automation fails outside of demos. Until the answers are visible and dependable, important processes should be built on documented behavior only. A convincing response in a chat doesn’t resolve the need to know what happened to the work behind it.

Source: GitHub: openai/codex issue #49848.

What admins can control

Our launch article covered the built-in safeguards, including read-only proactive research, Custom Rules, auto-review, and actions that always stay with the user. Enterprise admins also have separate controls for:

• Cloud browser use.
• Cloud network access for code and shell commands.
• Full cloud computer use.
• The password manager.
• Local computer access.
• Custom rules.
• Posting in Slack or Microsoft Teams under the Dot’s own identity.

Turning Dots on doesn’t grant access to every app or website. Only supported apps a member already uses in ChatGPT may be available to their Dot, so enabling the agent and authorizing its connections remain separate considerations.

The system card also describes the red-teaming behind these safeguards. Testers acted as real adversaries, attempting to hijack Dots or extract sensitive data, often by impersonating coworkers or posing as tools, marketplaces, and other automated agents. For businesses, that puts agent permissions squarely within IT governance: which agents can reach which systems, what they can change, what requires approval, and what stays human-only.

What other reviewers said

The Neuron’s Corey Noles got access around 11 p.m., named his Dot Herman, and by the next morning was calling it to pick up the conversation. His main takeaway was how natural the experience felt and how little setup it needed. Read his first-day account.

WIRED’s Reece Rogers, who had spent September testing Meta’s Muse, found agents far better at using a computer than they were a year ago. He also noted that setup suggested connecting Gmail and Google Drive, and encouraged readers to think carefully about what they let an agent see and do. Read the WIRED piece. We ran into that same trade-off when deciding how Toby should handle email.

The Hacker News thread, with more than 600 comments, offered a more skeptical view. A common argument was that Dots repackage what technical users already run themselves; one commenter described two “AI employees” built from Codex sessions running in dedicated Unix accounts. Others pointed out that technical users aren’t the intended audience. The likely buyer wants an always-on agent without having to build one.

Our experience sits somewhere between those views. Common app connections felt easy, consistent with The Neuron’s account, but setup became technical quickly when we introduced our own tools. Both experiences can be true, depending on what you ask the Dot to connect to and accomplish.

Should Your Business Try Dots?

After one day of use and a close read of the documentation, we see some practical starting points, along with a few areas that need more time:

• Start with read-and-flag work. Finding conflicts across Slack and a calendar, spotting a view-only file, and pulling GA4 and Search Console data all worked. None of those tasks required Toby to send anything on my behalf.
• Keep sending in your own hands for now. Our failures clustered around actions such as email, direct messages, and rescheduling, so those are places where we’d keep human involvement.
• Budget setup time for anything non-standard. Non-Gmail email and custom MCP tools took most of the afternoon. A stack of common SaaS apps should involve less friction.
• Plan where the work runs. Tasks that need Docker, a VPN, internal servers, or your logins require a connected computer or your own infrastructure rather than the Dot’s cloud computer.
• Don’t treat a Dot in Slack as a teammate yet. A fifty-minute response time can be acceptable for background work, but it’s too slow for a conversation.

The hardest parts of my day were integration, permissions, and knowing what had actually finished. The model’s intelligence wasn’t the main obstacle. Those practical details are the work our AI agent development team handles when a business needs agents connected to its own tools. If you’re deciding whether Dots covers your workflows or you need something built for them, our AI consulting and development work starts with that question.

What We Still Don’t Know

One day can show where a product is promising and where getting started is frustrating. It can’t establish how well an agent will own a business process over time. We still need answers to several questions:

• Whether our scheduled report runs reliably day after day.
• What long-term usage allowances look like once the first-month extended limits end.
• How many tasks and subagents a Dot can run at once.
• How reliably a project continues over weeks or months.
• How often the work needs human correction.
• How much of today’s undocumented behavior will change.

Toby gave us enough finished work to keep testing, and enough unfinished work to stay involved. A product can impress during a one-day test and still struggle with a business process six months later, so the next useful test is whether the scheduled reporting holds up. We’ll update this review once the report has had a week to run.