Articles / Viewpoints and methods
10 minFor tool users

How to Use OpenAI dot for Work: Lessons from Real Tasks

Lessons from using OpenAI dot for research, content and website work, with a reusable task brief, decision handoff and guidance for reviewing deliverables.

Aaron HuangSystems, product and AI practice

How to Use OpenAI dot for Work: Lessons from Real Tasks

Landscape concept cover: a person at a desk connects work through one dot conversation to four document symbols for research notes, content planning, website previews, and practice materials. Not product UI or architecture.
Cover | A personal agent in practice: one dot conversation connects work to inspectable outputs. Four document symbols represent research notes, content planning, website previews, and practice materials. Concept illustration, not product UI or architecture.

I put OpenAI’s dot personal agent in ChatGPT to work on language practice questions, website changes, article planning, and market research. The work produced research documents, questions with explanations, content classifications, and website previews. Yet when tasks spanned conversations or produced new versions, I sometimes still had to supply background, correct the direction, or ask what had actually been verified.

This article organizes the lessons into three steps: brief the goal and necessary sources together, carry evidence and current decisions into the next stage, and review the actual output against the original purpose. It includes a reusable task brief and a completed website example. These are recommendations developed after the experience for future use, not a method with measured results.

The focus is practical work after getting started, not a review of every feature. If you have not started yet, see OpenAI’s official setup guide.

A three-step method for working with dot: brief, carry forward, review

Step 1: Brief the goal and necessary context together

Start with what this task should accomplish and what would make the result usable. Put the earlier information, latest decisions, and conditions that must remain intact into the same short brief.

In the website work, I encountered a change that did not fully preserve the purpose. I wanted to remove prominent entry points for a few narrowly focused use cases. After the changes, featured content, latest articles, and reading guidance had also become less prominent. I had to return to the question of whether a first-time reader could tell what to read first and where to go next.

For this kind of task, the brief can state both what should change and which functions must remain. Alongside removing the specified entry points, readers must still be able to find suitable articles and recent content. The presentation can change; whether the section disappeared should not be the only completion condition.

That should not mean reconstructing the entire history myself every time. For information already supplied, I can ask dot to retrieve what it can access from existing documents and conversations, then identify the sources and decisions it will use. I add new requirements or correct a misunderstanding. If necessary information cannot be read or its version is unclear, dot should identify the gap and ask the questions that affect execution, rather than fill the gap with an assumption.

This step leaves a reusable brief that gives delivery and review a shared basis, without requiring the user to repeat the background at each stage.

Step 2: Have each new version explain what it carries forward

Work that continues into another stage should carry the previous output, evidence, and latest decisions with it. When its direction changes, the change and the reason should be visible.

The research task made this problem particularly clear. An earlier study found moderate support for editing existing company Word or DOCX templates while preserving their formatting. Evidence for recurring operational reports was insufficient at that stage. A later version’s traceable inputs omitted that study, and its direction shifted toward creating new reports without identifiable new evidence sufficient to justify the change. What I could establish was that the earlier evidence had not been clearly carried forward. I could not conclude that the data had disappeared or that the research had never happened. Whether the same market gap still exists also requires a separate check.

A new deliverable can therefore include a short continuity note: which sources it used, which decisions it retained, what changed and why, and what remains unresolved. If a new direction conflicts with earlier research, surface that conflict. Where the evidence is insufficient, preserve the uncertainty rather than quietly treating the earlier conclusion as overturned.

Content planning needs the same continuity. I received lists with different counts, but categories of existing articles, missing functional coverage, candidate topics, and priority work packages represented different things. Continuing the work should preserve those definitions, distinguish existing material from candidates, and explain the basis for prioritization. Small topics can be combined; there is no need to write simply to fill a predetermined number of themes.

A pause is also a decision to carry forward. I later paused the practice-question work, so it should not restart because the task changed. dot should prepare the necessary continuity information with the result, carrying only what the next stage needs. I should not have to move it again, and there is no need to copy an entire conversation.

Step 3: Review the output, the scope of the checks, and the next step

When a completion report arrives, first look for something to inspect, then for what was actually checked. The review should return to the intended use instead of accepting a completion status alone.

The practice-question task had produced questions, answer explanations, and a review document. The checks covered question counts, formatting, and consistency in AI-generated answers. They did not establish comparable difficulty to official samples, validation with human test-takers, or suitability for predicting test scores. Without a clear account of the checks, the next stage could build on an overstated interpretation of the result.

Website work calls for inspecting the preview and following a new reader’s journey. A page opening and links working establish only part of the result. Whether the reading guidance is still appropriate needs to be assessed against the original purpose.

A short delivery note can state where the result is, what was checked, what remains unverified, and what can happen next. If progress depends on missing information, a change of scope, or a decision that belongs to me, identify the stopping point and the question to resolve. That lets me distinguish reviewing a result from supplying necessary information or making a new decision, without inferring progress through repeated follow-up questions.

A suggested three-step workflow for working with dot: brief the goal, sources, and constraints; carry forward the version used, latest decisions, and reasons for changes; review the output, scope of checks, and next step. Improvement has not been measured. This is not a diagram of product internals.
Figure 2 | A suggested three-step method for working with dot: brief the goal, sources, and constraints; carry forward the version used, latest decisions, and reasons for changes; review the output, scope of checks, and next step. Recommendations drawn from experience, not measured improvement or product architecture.

A reusable dot brief: from source material to review boundaries

These six fields form one brief for research, content, or website work that spans several stages. I can ask dot to fill it from existing context, then confirm the important points. A simple one-off question does not need every field.

Goal

Produce [specific result] for [person or next step]. For this task, limit the work to [scope].

Necessary sources

First consult [existing document, page, or research]. Identify the source or version used. If information necessary for execution is missing, name the gap rather than inventing it.

Existing decisions and work that must not restart

Follow [latest decision] and preserve [conditions that must not be removed or changed]. Keep [paused work] on hold; do not restart it independently.

Deliverable

Return [file, preview, or organized result] that I can inspect directly. Include the main changes, the evidence used, and unresolved issues.

Review

Check [observable conditions] against [intended use or user journey]. Distinguish what was checked from what remains unverified.

Decisions that need me

Continue within the scope above. If the work requires [a new direction, expanded scope, or an external action], explain the reason, options, and consequences, then wait for my decision. If you cannot continue, identify the stopping point.

Completed example: change a website while preserving reading guidance

This example uses an article overview and its reading entry points to show how to fill the brief. It was developed from the experience; it is not the original prompt.

Goal

Adjust overly narrow use-case entry points in the article overview while helping first-time readers understand what to read first and where to go next. For this task, provide a preview for review.

Necessary sources

Inspect the current article overview, categories, reading entry points, and existing decisions about the changes. Identify the pages or versions used. If you cannot access the material, identify the gap rather than assume what the layout contains.

Existing decisions and work that must not restart

Remove the prominent entry points for narrow use cases, but preserve readers’ ability to find suitable articles, recent content, and categories. Do not insist on retaining a particular sorting label or control. Do not expand the task into rebuilding the entire site or restart paused projects.

Deliverable

Provide the revised preview with a short change note: what was removed, how the earlier guidance was preserved, and what was left unchanged. Make it possible to compare the reading journey before and after the change.

Review

Start from the article overview and check whether a new reader can find a suitable starting article, recent content, and categories, with links reaching the intended destinations. Report the section changes, link checks, and reading-journey review separately. Without testing with real readers, do not claim user validation.

Decisions that need me

If the existing content is insufficient to provide clear reading guidance, list the gaps and suggested options. Ask me to confirm before adding articles, changing the overall category structure, or publishing the final version. Do not treat those actions as incidental to this edit.

When the preview comes back, use the same brief to review the changes and reading journey. If the report only confirms that pages open and links work, still examine how a new reader finds the content. Technical checks should not replace reviewing the reading guidance.

Keep one point of contact, rather than maintain a set of departments

Initially, I divided work into fixed departments for intelligence, research and development, content, and technology. I hoped dot would coordinate them so I would not need to track each part. In this round of use, the arrangement did not reduce my workload as intended. I spent more attention supplying context, correcting direction, and asking about results. I therefore canceled the fixed departments, choosing to communicate directly with dot and let the current work determine the specific tasks.

The three steps above aim to keep the brief and its continuation within one understandable context. Dividing tasks should support delivery and review, rather than become another organization for me to maintain. Existing outputs, pauses, and earlier decisions should remain intact.

OpenAI’s task documentation says dot can delegate work to parallel background agents. A new task receives instructions and context but does not automatically receive every earlier conversation. The documentation also notes that completing a run does not itself establish that the requested result was achieved or delivered. These product descriptions help explain why briefs matter. They do not establish the technical cause of the gaps in my experience or prove that every earlier activity had continued independently or run in parallel.

I can make the observable requirements clearer and examine what happens in later use: whether I repeat less background, whether results can be inspected, whether they support the next step, and whether repeated corrections and follow-up questions become less burdensome.

Four qualitative questions for future use: less repeated context, inspectable results with clear verification boundaries, results carried into the next task, and fewer repeated corrections or follow-ups. These are evaluation criteria, not measured improvements.
Figure 3 | Four criteria the author will use to evaluate a personal agent: less repeated context, inspectable results, usable handoffs, and fewer repeated corrections. Qualitative illustration, not measured performance or evidence that improvement has occurred.

I still want dot to help carry my work. This experience has made the expectation more concrete: preserve the purpose in the brief, carry necessary evidence into the next stage, and return something I can inspect and review. Ultimately, I want to see the work move forward while spending less effort repeating background I have already supplied.