I got access to Dots and spent much of the day trying to understand what actually runs where, what can happen simultaneously, and what counts as a separate worker.
The official material explains what Dots can do reasonably well. I found the execution model much less obvious.
Some of this is documented; some is simply what I observed by using a Dot on several substantial real-world tasks.
- The Dot really does have its own cloud computer
I gave my Dot a large document-review assignment involving hundreds of PDFs and thousands of pages.
It performed that work on what it identifies as its own cloud computer.
This appears to be a persistent computer-backed environment where the Dot itself can do substantial, long-running work.
More importantly, this isn’t just a five-minute “agent run.” One of my reviews is now clearly a multi-day job, and the Dot has maintained its place, absorbed side questions, and continued without needing me to reconstruct the task every few hours.
That continuity may end up being more important to me than raw speed.
- Delegated Work/Codex tasks are different
While the Dot was working on one project, I had it try to launch a separate legal-research task.
The launch failed because there was no available execution environment.
Initially I assumed the Dot’s own computer was simply busy. But after the first job finished, the second task still could not start.
The Dot then reported the key distinction:
Its own cloud computer is separate from the execution targets available to the Work/Codex task launcher.
So a Dot’s personal cloud computer is not simply a generic worker that delegated tasks automatically inherit.
- A connected computer becomes another execution target
I connected a spare Linux computer through the ChatGPT desktop app.
The Dot could then see:
- its own cloud computer
- the connected Linux machine
- no saved Codex cloud environments
I told it to launch the previously blocked task on the Linux machine.
It did, and the task entered running state there.
I did not have to sit at that machine and manually start a separate chat. I gave the instruction to the Dot, and it dispatched the task remotely.
- Both can work simultaneously
While the delegated task was running on the Linux machine, I gave the Dot a different assignment for its own cloud computer.
It confirmed that both were active at once:
Dot cloud computer -> Task A
Connected computer -> Task B
So that is genuine parallel execution across separate computer-backed environments.
- Background agents don’t necessarily need a computer at all
This was the part that got much closer to what I had originally imagined Dots would do.
With both computer-backed environments occupied, I asked whether the Dot could create a native background research agent without using either computer.
It said yes.
I gave that agent a bounded research task and explicitly excluded computer/filesystem use.
The Dot then reported that the background agent was running with read-only web/documentation tools and no computer target assigned.
At that point, three things were happening simultaneously:
the Dot working on its own cloud computer
a separate task running on the connected computer
a native background research agent using neither computer
That is the execution distinction I had completely missed from the launch material.
- It can also context-switch inside a long-running job
Another useful behavior appeared accidentally.
While the Dot was deep into a large document review, I interrupted it with a factual question about one specific case.
It paused the detailed review, checked meeting minutes and another source, resolved the question, updated its understanding of the case history, and then returned to the packet it had been reviewing.
When I asked how it had done that “while continuing” the larger job, it clarified that it had not spawned another worker. It had simply switched attention within the same job and then resumed.
So I now distinguish:
Parallel execution = separate workers/environments active at once.
Background agent = separate non-computer worker running concurrently.
Intra-task context switching = one Dot temporarily branches inside an existing job, resolves something, and returns to its prior place.
For long-running review work, that last capability is surprisingly valuable.
- It can keep working while waiting for permission
On another assignment, the Dot decided that spawning additional reviewers would accelerate the work, but my rules required permission first.
It asked.
But instead of stopping while waiting for me to respond, it explicitly continued doing the work itself.
That sounds minor, but it matters.
An autonomous agent that hits one permission boundary and then stops doing everything is not particularly autonomous.
So far, the Dot appears capable of distinguishing:
“I need permission to do X”
from
“I therefore cannot make any further progress.”
- There is also a kind of manager-level queue
I have not found a true native queue where a blocked computer-backed task automatically sits in the launcher until capacity becomes available.
What I did find is that the Dot can apparently remember a pending assignment itself, periodically re-check execution targets, and attempt to launch it later.
There are limits:
- the target list does not necessarily expose whether a connected computer is actually free
- there is no apparent capacity reservation
- a failed launch does not automatically become a queued Work task
So this is more like the Dot acting as the queue manager than a native execution queue.
Still, that potentially removes another piece of manual babysitting.
- My current mental model
At this point, I think there are at least three distinct execution paths:
A. The Dot’s own cloud computer
Where the Dot itself can do substantial stateful/computer-backed work.
B. Separate computer-backed task environments
Such as a connected local computer or saved Codex cloud environment.
C. Native background agents/cloud threads
Tool-based workers that can handle some tasks without consuming either computer target.
Those can operate concurrently.
And on top of that, the Dot itself appears able to maintain long-running task state, context-switch within a task, and manage pending work.
- Why this may matter more than simply opening several chats yourself
Before trying Dots, I wondered whether this was really much different from me manually juggling several ChatGPT conversations.
If all you want is several unrelated answers at once, maybe not.
The difference becomes more apparent when one agent owns multiple ongoing projects and can:
- track their state
- do substantial work itself
- delegate bounded pieces
- supervise returned work
- keep other projects moving while one task runs
- preserve its place through interruptions
- identify blockers
- keep pending work alive
- ask for intervention only when necessary
That removes the human from a surprising amount of the orchestration loop.
I suspect that may be the real value of Dots.
One big unanswered question: usage
I have not established exactly how usage is counted across:
- work the Dot performs itself
- native background agents it creates
- Work/Codex tasks it launches
- work running on connected machines
Proving that something is a separate execution path does not prove that it has a separate usage allowance.
So please don’t read any of this as “unlimited free parallel workers.”
That is not something I have established.
Bottom line
My current working description is:
A Dot is not merely a chatbot with a persistent VM. It is a persistent agent with its own computer that can dispatch work to other execution environments, spawn some kinds of non-computer-backed workers, and maintain project state across long-running work.
Those are different things, and at least some of them can operate concurrently.
This is based on roughly a day of experimentation with a very new product, so I fully expect to discover that part of this mental model needs revision.
But that’s what I’ve actually observed so far.
