How Much of Human–AI Mediation Has ChatGPT’s dot Implemented?

Mapping its official structure onto Mediation, this piece looks at why permission review differs from judgment validity and why completion differs from success.

When I first opened a ChatGPT dot, even what to ask and how to ask it felt unfamiliar. In the chat I was used to, I asked a question, got an answer, and asked again if it fell short. Dot first had me decide what to connect and how far to delegate, and instead of waiting for an answer, I had to wait for the work to move. When I checked whether I could hand it my company work, Gmail and Slack were usable, but there was no way to connect my company email, which arrives over POP3; local documents required connecting a computer separately; and a shared project I had made on the web did not appear in the Mac app.

In the second conversation, I handed it real work. While thinking about how my company should manage its projects, I attached a proposal. What I wanted to build was a status board that gathers work information scattered across prompts, local documents, email, and Slack and updates itself. I asked dot to consider dots, ChatGPT Space, Claude Code, Codex, the GPT app, and the Claude app as candidates. Dot narrowed the request down to the question of which AI tool to adopt. It proposed costs and a pilot rollout order in detail, but it was solving a different problem. When I explained again that I wanted to build a status board, dot acknowledged it had looked too narrowly and proposed a structure for gathering the information.

Dot defined the problem wrongly at first, but revised its later answers after my correction. The revised answers included some useful suggestions about how the status board would gather information, and about cost and rollout order. But it did not sufficiently compare the candidates I had asked about, and it ended the conversation with advice, without starting any actual work such as research, design, or revising the proposal. I confirmed that it could be corrected, but I did not experience the distinctive value of a persistent agent. What bothered me more than the slowness itself was waiting while it carefully analyzed a misunderstood problem, and then having to restate my purpose anyway.

At first I thought these inconveniences were a problem of speed and usability. But as I read the official guides and early user reviews, I realized dot was built to solve a different problem from a typical conversational AI. Dot is less a chatbot that answers quickly and more an always-on agent that continues to carry responsibility across conversations and tasks.

The difference matters. Until now, people have had to explain to AI what to do, check results, restart stalled work, and connect results from different conversations. Dot tries to take on part of this coordination itself. It keeps working while the person is away, splits work across other agents and execution environments, and can return the decision to the person when it reaches a preset permission boundary or needs input to proceed. That does not mean it reliably recognizes when a new judgment about purpose or values is needed.

This structure addresses a problem quite close to the Human–AI Mediation System TYPE has been researching. So how much of Mediation has dot implemented, and what has it not yet solved?

Dot sustains responsibilities, not conversations

OpenAI describes dot as an always-on agent that keeps working between conversations. Within one conversation, a user can hand it several responsibilities, add new information, or change priorities. Dot can work directly on its own cloud computer, or split off part of the work by creating separate background agents or Work and Codex tasks. Cloud work can continue after the user moves to another conversation or turns off their computer.¹

Dot manages not only tasks that repeat on a schedule but also tasks that start when a specific event happens in a connected service. The user can decide what to check or update, which changes are important enough to be notified about, and which decisions need their input. Dot keeps track of progress and results and sends follow-up instructions when needed.²

The key here is not execution speed but the continuity of work. Before, a person had to remember the state of the work and keep producing the next action. Dot keeps track of “what we agreed to do,” “how far it has gone,” and “what it is waiting for,” and tries to reduce how often the person must reconstruct context.

Continuity is not built from one memory

Dot’s structure can be broadly divided into memory, tasks, execution environments, and permission review.

First, dot uses not only the current conversation, attachments, and tool results but also relevant ChatGPT memories and notes it saves separately. These notes can include the user’s preferences, decisions, and ongoing responsibilities. When new decisions or priorities come up, it updates the notes, and the same dot can use the relevant context even when the conversation moves between channels such as ChatGPT, Slack, and Teams.

But dot’s notes are not a complete record of everything the user said. They are information selected as needed for later work. The context provided in a conversation is likewise not the whole memory but a part selected as relevant. We cannot assume that the conversation the user remembers, the notes dot saved, and the context actually passed to a task are the same.

Work does not happen in one place either. Dot distinguishes between its own cloud computer, separate cloud tasks, a computer the user has connected, Codex environments, and background agents. Each has different files and programs it can access, different sign-in states, and different permissions. Dot creates these tasks, checks their progress, and coordinates follow-up actions once results arrive.³

To sustain a responsibility, an agent has to reach where the work actually lives. When the information it needs sits where dot cannot reach, gathering and moving that information falls back to the user.

This is part of why dot feels slow and complex. The user is having one conversation, but behind it dot is deciding which environment to use, creating separate tasks, and checking connections and permissions. Conversation and execution move at different rhythms.

Dot’s permission structure

When dot is about to affect an account or share information externally, an automatic review applies. The review checks the user’s instructions, the connected apps’ permissions, Custom Rules, and safety rules together. Depending on the result, dot acts directly, asks for approval again just before acting, or hands the step to the person.

Custom Rules let the user set one of four boundaries per action.

A specific request can allow later actions within its scope, but anything outside that scope requires a new decision. The official guide also states explicitly that asking it to draft a message does not include permission to send it.⁴

This structure lets people keep important permissions without approving every action one by one. Ask too often and the benefit of automation disappears; ask too rarely and actions the person did not want may be carried out. In between, dot handles which actions continue and which are returned to the person according to user instructions, permissions, rules, and safety reviews.

Where it overlaps with Mediation

TYPE’s Human–AI Mediation System connects judgments a person has approved with AI’s continuous execution. While an approved judgment remains valid, AI keeps exploring, planning, executing, and verifying without repeated instructions. When a new human judgment is needed, it holds the affected work and returns the decision to the person. When the person keeps, makes an exception to, revises, or withdraws a judgment, the system connects the changed judgment to subsequent execution.

From this perspective, dot clearly has structures that overlap with Mediation.

An early user’s account introduced in the previous piece shows this structure well. In a multi-day task reviewing hundreds of PDFs, when dot needed approval to use additional workers it asked the person, but kept doing the review it could do while waiting for a response.⁵

It is especially important that one permission request did not stop the entire run. In this user account, work outside the affected scope continued while operational approval was pending.

This does not mean OpenAI applied TYPE’s Mediation System. There is no evidence of a direct relationship between the two systems. It is more accurate to see dot as a commercial system that reached the same problem area as Mediation as always-on agents became real.

Memory is not an approved judgment

The most important difference between dot and Mediation lies in the nature of memory.

Dot remembers the user’s preferences, decisions, and ongoing responsibilities. This memory reduces repeated explanation and keeps work going. But the official documentation does not describe dot’s notes as a register that systematically manages approved judgments.

It is hard for a user to see the following in a clear structure:

• Which statements were simply opinions and which were approved judgments
• What the original wording and reasons for a judgment were
• Which projects and outputs it applies to
• Whether it was a one-time exception or a lasting standard
• Under what conditions it should be reviewed again
• Whether a later judgment revised or discarded an earlier one

For example, a request to soften one sentence in a particular piece may be a correction that applies only to that sentence. If dot saves it as the user’s general style preference, later repeated explanation may decrease. But if the scope is widened by mistake, a local judgment ends up changing other pieces and projects.

Accurate memory alone cannot solve this. Even a judgment remembered accurately can be applied to the wrong scope. What Mediation needs is continuity not only of a judgment’s content but of its status, scope, validity conditions, and change history.

Permission review is not judgment-validity review

Dot’s permission structure manages “Is it okay to take this action?” It distinguishes whether it can send a message, whether it can delete a file, and whether it may reuse saved sign-in information. This is an essential structure for an agent that acts autonomously.

But having permission to act is different from the judgment behind that action still being valid.

Whether a schedule approved last week still holds this week, whether a standard applied to one client can be applied to another, and whether past priorities remain valid after new information cannot be decided by permissions alone. Even if dot has permission to send a message, what to send and by what standard is a separate question.

In Mediation, Human Return is not needed only for sign-in or send approval. It is also needed when the purpose changes, when approved standards conflict, when a judgment’s validity conditions break down, or when AI would have to choose a new value. At that point, what the person needs is not an approval button but the following:

• What has changed
• Which existing judgments are affected
• Which parts can continue and which should be held
• What the possible alternatives are
• How each choice affects later execution

Dot has implemented much of the operational handoff required at permission boundaries. But the official descriptions do not establish how reliably it recognizes when changing purposes or values require a new human decision.

Completion does not mean success

Dot’s official documentation notes that a completed run does not by itself confirm that the requested result was achieved or delivered, so results and errors should be reviewed.² This is an important sentence for understanding dot’s structure.

One user introduced in the previous piece saw the potential of a persistent agent when it organized 93 screenshots. But another data-cleanup task took about 72 minutes, and although the visible text and structure were restored, internal classification data and link handling were wrong and had to be checked and fixed again. Checking the visible result alone could not tell whether a result usable in the actual system had been produced.⁶

Continuous execution and execution quality must be distinguished. That dot did not forget the task and carried it to the end matters, but it is not evidence that it applied the person’s judgment appropriately or produced a usable result. In Mediation, too, following the approval procedure does not make a low-quality result a success, and a good result does not justify unapproved execution.

Has the human burden gone down?

The early reviews introduced in the previous piece show both reduced burdens and new ones. One user felt their productivity had doubled by handing tasks over by voice,⁷ another found it slow and prone to stalling,⁸ and another would not use it because its memory boundaries were hard to inspect.⁹ These are short experiences from some users right after launch and cannot be used as evidence of dot’s general effects.

Dot can reduce the burden of restarting work directly, remembering progress, and coordinating several executions. In exchange, people must set goals, define permission and information boundaries, understand progress, verify results, and make judgments in exceptional situations.

The burden has not disappeared; it has moved.

Do the savings in repeated explanation and coordination outweigh the new costs of setup, supervision, and verification?

Judging dot only by how much it did automatically is not enough. We also need to look at where and how often people intervened, whether those interventions actually required new judgment, and what it cost to recheck and correct AI’s work.

What dot leaves open

Dot has not implemented every element of Mediation, but it shows that the problems Mediation addresses have become product problems of the present.

Continuous execution is becoming possible. Structures for maintaining the state of several tasks, setting the scope of permissions, returning certain actions to people, and resuming work after a response have entered a real product. In this sense, dot shows an operating structure quite close to Human–AI Mediation.

But some problems remain hard to confirm from the official descriptions and early user accounts alone.

1. The official descriptions do not show a mechanism for users to confirm what problem and responsibility a request was taken to mean, or for the AI to ask first when its reading diverges.
2. The official descriptions do not show how remembered information is distinguished from approved judgment.
3. Apart from action permissions, the official descriptions do not show a structure that handles whether a judgment is still valid.
4. Whether a request coming back to people is shown as a simple execution approval or as one that calls for a new judgment is hard to confirm from the official descriptions alone.
5. Completing a task must be distinguished from appropriately realizing the person’s decision.
6. Persistent personalization can reduce repeated explanation while also fixing people to their past judgments.

The last of these goes beyond the scope of Mediation and connects to TYPE’s broader research direction.

The previous piece argued that autonomous choice is not merely the expression of a pre-existing preference. People should be able to form, examine, and revise their purposes and values through possibilities and experience, adopt a direction as their own, and later reconsider or change that choice.

This piece does not explain that view of people at length again. But it does confirm that, with always-on agents like dot, a new question has become real.

The longer AI remembers human judgments and the more work it does on our behalf, the more easily the directions people chose in the past will persist. When, then, should a system keep executing that direction, and when should it reopen a past judgment? If AI has already inferred a person’s purposes and constructed the options, can the remaining act of approval still count as autonomous choice? Do the results of execution come back as experiences that help people understand their purposes better and change their next choice?

Mediation connects human judgment with AI execution. Dot has turned much of that connection into a product. What TYPE now needs to examine is not only whether the connection exists, but whether it keeps human choice open.

References

1. OpenAI. Meet dots (ChatGPT Help). Source
   Official guide.
2. OpenAI. Tasks and memory (ChatGPT Help). Source
   Official guide, including the note that a completed run does not by itself confirm the result was achieved.
3. OpenAI. Computers and apps (ChatGPT Help). Source
   Official guide.
4. OpenAI. Control your dot (ChatGPT Help). Source
   Official guide, including the four Custom Rules and that drafting does not include permission to send.
5. Reddit r/OpenAI user account — I spent a day poking dots with sticks Source
   A personal user account, not evidence of general performance.
6. David Proctor (2026-10-01). OpenAI dot: why would I start a new chat? Trilogy AI (Substack). Source
   A personal usage log.
7. John Walter. LinkedIn post and comment discussion (first day using ChatGPT dot). Source
   A personal account; the productivity figure is self-reported.
8. Reddit r/codex user account — ChatGPT dots so far too slow to be useful Source
   A personal user account.
9. Reddit r/OpenAI user account — Why I will not use dots: insufficient visibility Source
   A personal user account.