Talking to Dots, from OpenAI, I recognized something that was already part of my routine: speaking to an assistant, keeping context between conversations, and getting work moving.

I had already been building that in my own environment. And for my work, talking to it directly still works better.

That sounds like a bold claim to make about a new OpenAI product. But the reason is concrete: I spent time explaining how I work, recording my decisions, and turning criteria into instructions the assistant can use. A substantial part of that work is already done before the conversation begins.

I want to talk about this precisely because I find the idea behind Dots interesting.

What Dots proposes

The idea is to talk to an assistant that maintains continuity and can return with work underway. It uses persistent context and connected sources with permission to do that.

Its persistent notes record preferences, decisions, and work; they are not a full transcript. It can also resume tasks at a set time or in response to supported events you have asked it to monitor.

The getting started guide describes research without a new request and scheduled tasks. Always-on includes work between conversations; it does not establish a universal checking frequency.

Dots can create local tasks and resume an identified local Codex task. Codex is OpenAI’s environment for programming tasks with agents, systems that choose steps and use tools. The computer must be connected and online, with the ChatGPT desktop app open. Local access is optional and allows files and reusable procedures (skills) to be used.

That changes how I frame the comparison.

Why conversations with my harness get further

I was already talking to my agent environment by voice. I would bring an idea, something bothering me, or a job to do, and the contracts helped guide what came next.

I call that structure a harness: the environment that brings together context, tools, memory, and rules to turn a model’s capabilities into work.

The artificial intelligence (AI) model interprets the request; the harness organizes the conditions for it to work.

When I say “contract,” I mean written instructions about responsibilities, limits, and quality criteria. When I say “skill,” I mean a reusable procedure that guides a task and its verification. A note records context or a decision; a skill explains how to work with it.

Dots also offers custom rules (Custom Rules) to guide actions while respecting the product’s mandatory approvals. That already covers part of what I call a contract. In my use, the difference is the breadth and maturity of the method I have built.

In my current use, talking directly to that harness is more effective than talking to Dots. The criteria I have built are organized there for use in the work. I can speak naturally because I do not have to recite the whole method with every request.

That is the difference I explored when writing about instructions to AI (prompts) in “If you have to remember the right prompt, your harness hasn’t learned the job yet”. If I have to remember every check, every limit, and every procedure myself, I am still carrying a large part of the operation in my head.

This comparison comes from my experience. I have not measured every Dots feature. What I have built has a maturity advantage for my context: it holds decisions I have made over time about how the operation should work.

Making a file available to the assistant is one step. Getting the criteria in that file to appear in the conversation and guide execution takes integration, testing, and correction.

What it notes about me and what I choose to write

An assistant that follows conversations has to select what to keep. That selection can help a lot: it avoids repeating context and makes it possible to pick up earlier topics.

But an inference the system makes about me can be wrong. And a preference noticed in a conversation does not automatically carry the authority of a decision I have confirmed.

In my harness, I can discuss an interpretation, correct a note, and define what should become a contract. As I explained in “My harness learns, but it does not get to rewrite the past”, I want learning to preserve the source and the possibility of review.

The Dots privacy questions page says the interface does not currently allow users to view, correct, or delete individual memories generated by a dot. That matters when a personal interpretation starts guiding actions.

I want to examine what supports a decision and change a procedure that failed. I also want a contract that tells the agent to show contrary evidence when my idea does not hold up. Knowing me better includes knowing when to disagree with me.

The tool improves. My method has to keep up

Over time, Dots may become more effective for me. My comparison describes the workflow I use today.

I also understand the value of starting with a ready-made product. Building and maintaining a harness takes work; not everyone needs an extensive structure to solve a simple need.

What my experience suggests is that it is worth investing in the method these tools will use. When I improve a skill, clarify a responsibility, or record a decision that can be reviewed, I can reuse that work beyond the conversation.

If Dots already seems useful to you, imagine what might change when the assistant finds explicit criteria for your work. The first step can be small: choose a recurring task, write down how to recognize a good result, state what needs your authorization, and check whether the agent follows those rules.

If it fails, you have something concrete to correct.

I want to teach this

I am considering a mentorship to help people build their own harness, starting with the work they need to do.

It is what we sometimes call a “second brain”: a structure for putting context outside our heads and increasing our capacity to get things done. The metaphor has limits. The person still sets the direction, and the system needs review.

I would like to teach people to organize notes, contracts, and skills so that a conversation can lead to a verifiable result. And to recognize when a ready-made tool is enough and when it makes sense to build something of their own.

If you are seriously interested in learning, write to me about the work you would like to improve. I am considering this path, and understanding the problems of people who want to learn is part of that decision.

Dots can be a good starting point. The experience I want to share is how to keep building from there, putting your own judgment into the work AI carries out.

Further reading

• The model is only the engine. The AI harness is the whole car: the blog’s main reference for understanding the parts of this structure.
• ChatGPT already knows a lot about you. Before you trust it, make it show its work: how to examine personal interpretations before using them as rules.

References and limits of use

• OpenAI, “Introducing dots”: the product’s proposal; it does not compare its performance with my harness.
• OpenAI, “Tasks and memory”: persistent context and resuming tasks; it does not establish a universal checking frequency.
• OpenAI, “Getting started with your dot”: setup and recurring tasks; it does not demonstrate the use of my contracts.
• OpenAI, “Connect computers and apps”: local access and Codex coordination; both depend on granted permissions.
• OpenAI, Codex: introduces the coding agent environment.
• OpenAI, Dots privacy and security questions: current data and memory controls; these may change as the product develops.
• OpenAI, safety and privacy in Dots: custom rules and approvals; it does not compare the product with my method.
• Forte Labs, “Building a Second Brain”: knowledge organization; used as a metaphor, without claiming to follow the method.

The effectiveness comparison in this article is my account of using the tools, without controlled measurement. The sources describe Dots; the criteria for organizing my work and the idea for a mentorship are mine.