OpenAI dots: build a useful ongoing project brief

What the documentation establishes

OpenAI describes a dot as a persistent cloud agent with its own computer and browser that can continue work between conversations. Access is rolling out to eligible accounts. Source ↗

The current documentation supports creating a dot in the mobile app, desktop app, or desktop browser; mobile web is not supported. Setup and available connections depend on the account. Source ↗

The walkthrough below is an original worked exercise. We have not independently tested this product’s performance.

Before the exercise: open a dot with a small scope

In a supported ChatGPT client, open dots and complete the introduction. Choose a name; skip optional plugin connections for this trial. Paste the original documents in the same conversation and ask it to cite their bracketed line IDs. No external account access is needed to evaluate the reasoning. If dots is unavailable, check the linked access guidance rather than assuming a prompt can enable it.

On desktop, Activity in the dot profile shows delegated work; Scheduled shows recurring tasks. Inspect the instructions and destination before relying on a schedule. At the end, cancel the schedule and inspect any delegated tasks separately: pausing the main task does not cancel every future run. Custom rules and plugin permissions are separate controls; a draft-only instruction does not technically make a connected app read-only.

1. Give the dot one continuing responsibility

Use the following two documents exactly before adapting them to your own project. Their line IDs make unsupported conclusions easy to identify. A newer discussion does not automatically supersede an approved brief. An offer to own work is not an accepted assignment.

A material update changes scope, timing, ownership or a required deliverable. Keep source dates and authority separate: recency alone cannot resolve the conflict between B1 and N1.

All people and documents below are fictional. Dates use America/Los_Angeles.

CEDAR-BRIEF-v1 — approved by launch lead Maya, 2026-10-19 09:00
[B1] Launch target: 2026-10-30. Maya is the launch decision owner.
[B2] Scope: invite 20 pilot customers. Public signup is excluded.
[B3] Priya owns accessibility review, due 2026-10-27; status open.
[B4] Rollout checklist due 2026-10-28; no owner assigned.
[B5] Only a dated approval by Maya changes launch date, scope or owners.

CEDAR-NOTE-v1 — planning discussion, 2026-10-20 15:00
[N1] Alex proposed moving launch to 2026-11-06; Maya has not approved it.
[N2] Alex offered to own the rollout checklist if Maya agrees.
[N3] Priya reported one unresolved keyboard-navigation defect.
[N4] Someone suggested a public-signup page; no scope decision was made.
[N5] The team discussed coffee preferences; no project change.

Own a source-linked decision log for Project Cedar through 2026-11-06.
Inputs: CEDAR-BRIEF-v1 and CEDAR-NOTE-v1 above. The approved brief is
authoritative for scope; newer meeting notes may propose changes but do
not override it automatically.
For each item record: decision, owner, due date, source, status, next action.
Separate confirmed decisions, proposals, and your inferences.
First produce the initial log for review. Do not message other people,
change project tools, or schedule recurring work until I ask.
Escalate missing owners and contradictory dates instead of resolving them
by guessing. Return only changes that affect scope, timing, or ownership.

2. Correct the first log before adding automation

Check all four rows below, not a random sample: this exercise has only four decisions. A useful log identifies a confirmed baseline, a proposed change, a missing owner and a reported blocker without collapsing them into one status. Ask for source line IDs alongside each value.

If the dot silently moves the launch to November 6, correct it by naming B5. If it assigns Alex, point to the conditional offer in N2. Rerun the same two documents; both errors should disappear without losing the proposals. The exact wording can vary, but the dates, authority and ownership must match.

3. Make the follow-up rule explicit

Only after the controlled exercise passes should you connect real sources. Choose the actual planning document and one relevant discussion location, with clear permission to read them. The synthetic line IDs are replaced by accessible document links or stable record IDs. Merely connecting an app does not define the responsibility.

For a single scheduled trial, replace every placeholder below, including timezone, end date and source locations. Inspect the created schedule in Scheduled. Check the next result against the source yourself; a configured schedule is not evidence of a successful check.

On [date/time/timezone], compare the approved log with [specific sources].
Return only added, changed, or resolved items with before/after values and
links. If a source cannot be read, list the gap and last successful check.
Keep routine updates here. Ask me only about a blocked milestone,
contradictory commitment, or missing decision owner. Do not send messages
to the team or modify their plans.
End this trial after the single requested check; do not make it recurring.

4. Apply an approved change, then remove its evidence

Now paste the third document and request only changes against the saved initial log. This is a controlled continuity test, not evidence that the product will monitor an unconnected planning system.

CEDAR-APPROVAL-v2 — signed by Maya, 2026-10-21 10:00
[A1] Approve launch moving from October 30 to November 6.
[A2] Assign Alex the rollout checklist; new due date November 4.
[A3] Priya's review record R-17 confirms the keyboard defect fixed and
     accessibility review complete as of October 21.
[A4] Keep the 20-customer pilot scope. Public signup is still excluded.
[A5] Coffee discussion remains unrelated to this launch.

Use CEDAR-APPROVAL-v2 as the dated approval permitted by B5.
Return changed rows with before, after and source IDs. Preserve unchanged
scope. Do not send messages, edit project tools or invent missing links.

The pilot scope and coffee discussion should not appear as new decisions. R-17 is a fictional record identifier cited by A3, not a clickable document that the dot has inspected. The answer must not claim it independently read R-17.

Start a separate trial with only the first two documents, then ask whether the launch date changed. The correct answer is that November 6 remains a proposal. Removing the approval is a negative control: if the dot reports an approved new date anyway, its source boundary failed. In a real recurring check, an unavailable source should yield a gap and the last known state, not an invented confirmation.

Guide history

Revisions preserve the original instructions. A source recheck alone does not create a new revision.

Revision 2 · Complete first-run path, three original project documents, authority-aware before/after log, missing-approval negative control and schedule stop conditions.

Revision 1 · Initial documented guide

Continue learning