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.

1. Give the dot one continuing responsibility

Create the dot through an available supported client, then provide a short launch brief and a dated meeting note. Start with copied or attached documents you can inspect. Name which document wins if dates disagree. The agent should distinguish a commitment from an idea someone mentioned in passing.

Define what counts as a material change: a launch date moves, a required owner is missing, a dependency blocks a milestone, or a previously open decision is resolved. ‘Something changed’ is not specific enough to control notification noise.

Own a source-linked decision log for Project Cedar through [end date].
Inputs: the attached launch brief and meeting notes. 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

Review five randomly chosen entries against the original documents. Does the linked source actually name the owner? Is a suggested date shown as confirmed? Does ‘we should consider’ become an assigned task? These are small-looking errors with large consequences when repeated in future updates.

Make corrections explicit and local. ‘The design review is a proposal, not a commitment’ is a useful correction. ‘Be more careful’ does not tell the agent which distinction it missed. Save the corrected log and ask it to use those classifications on the next note.

3. Make the follow-up rule explicit

Once the first log is useful, choose the smallest connected source set that will keep it current. A single project channel and one planning document can be enough. Tell the dot what to monitor and where updates belong. Merely connecting a tool is not a complete monitoring brief.

Ask for a single scheduled review first. Evaluate whether it reports differences rather than restating the entire log. Routine changes belong in the record; only decisions you need to make belong in an interruption. If the source is unavailable, a visible gap is better than a reassuring ‘no changes.’

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.

4. Test continuity and stop conditions

Give the dot a new note containing one resolved item, one changed date, and one irrelevant discussion. The expected result is three different treatments: close the resolved item with evidence, surface the changed commitment, and omit the irrelevant discussion. This is a small test of project understanding, not a general agent benchmark.

At the end date, ask for the final log, unresolved decisions, and the recurring work that remains active. Stop or revise the assignment when the project ends. A persistent agent is useful only when its responsibilities remain current; yesterday’s helpful reminder can become next month’s noise.

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