Dots, ChatGPT Work and Codex: how to delegate a software job
Dots coordinates, Work prepares deliverables and Codex works on software. Assign tasks, choose the environment and verify changes before release.
Reading time: 12 min

Dots can coordinate a software work, while Codex remains the product dedicated to code and development. ChatGPT Work manages articulated and deliverable activities; the dot follows responsibility over time and can delegate parts of the work. The correct choice depends on the result, the environment and the tests needed to accept it. Official guide to ChatGPT Work and Codex.
An assignment such as "follow the improvements of this portal" may need coordination. Code editing requires a technical task with repositories, requirements, and controls. The "completed" state does not prove that the behavior is correct. The manager must be able to open the result, understand the changes and verify what has really been tried.
The documentation was verified on 9 October 2026. For the general description of the dot read OpenAI Dots: What They Are; for Italian access check Dots plans and availability. This guide does not set up accounts, does not run API expenses, and does not report tests performed on a real project.
In summary
- Dots coordinates a responsibility; Codex is dedicated to software work.
- Work can prepare deliverables, without becoming synonymous with Codex.
- The dot can create or continue tasks and use already configured Codex Cloud environments.
- Dot environment, local computer and Codex environment are not interchangeable.
- A completed task must have proofs and revisionable changes.
- Agent API and SDK are not automatically an API of your dot.
When to use Dots, Work or Codex for a project?
Start with the object of the work. If you need to clarify a request, a conversation may be enough. If you need to prepare a document with multiple steps, Work is the deliverable-oriented experience. If you need to intervene on a repository or code, Codex is the dedicated experience. If you want to follow in time requests, decisions and activities, the dot can coordinate responsibility. These roles are described in the product documentation.
| Need | Relevant experience | Test useful for review |
|---|---|---|
| Clarifying the Problem | ChatGPT Conversation | Understandable requirements and open points |
| Prepare a specification or report | ChatGPT Work | Deliverable with sources and criteria |
| Modify or verify software | Codex | Diff, checks performed and observable result |
| Follow the project over time | Dots | Status, Coordinated Activities, and Required Decisions |
| Build an agent in the application | Appropriate API or SDK | Specific architecture and integration |
The project can use more experiences without confusing them. Work can help make a specification readable; Codex can work on the implementation; the dot can maintain coordination within the assignment. The documentation of ChatGPT Work describes the work on deliverables. The quality of the handover still depends on requirements and sources, not the number of products involved.
For an SME, separation prevents a business request from becoming an unrevised technical change. "Improving the page" can mean text, performance, accessibility, or behavior. Before delegating, identify the concrete problem and acceptance criterion. The Guide to ChatGPT for coding helps to distinguish conversational support and verifiable work on the software.
What can a dot delegate to Codex?
The Dots documentation describes the creation of local tasks, the continuation of existing Codex tasks, and the use of already configured Codex Cloud environments. It does not mean that any repository or conversation is automatically accessible. The relevant task and environment must be available in the work path. Tasks and memory Dots.
To delegate, indicate the existing task or prepare a circumscribed technical brief. Specifies the current behavior, the desired behavior, the affected area, and the result to be delivered. If the problem is reproducible, describe the path that shows it. If you only have an impression, ask for a diagnosis and proposal first, avoiding authorizing broad changes based on an unverified premise.
The dot should keep distinguishable decisions and activities. One request may be ready for implementation; another may require a choice of the holder first. Useful coordination makes this difference visible. There is no need to assign everything to Codex as soon as the word "software" appears: a contradictory requirement must be clarified before touching the code.
The history of Codex is separate from that of ChatGPT according to the product documentation. Therefore, do not assume that an old conversation automatically contains the context necessary for the new task. Provide relevant references and ask what information is missing. Work and Codex. The comparison on how to create the first dot helps build responsibility before technical delegation.
How to write a software brief that you can accept?
The brief must contain an observable condition. "System the search" is vague. "When the user applies this filter, the results must comply with the agreed criterion and show a clear state if there are no matches" describes a behavior. Add context, excluded cases, and parties that need not be changed without a new decision.
It then points to the required evidence. The result should show changes, reasons, checks performed and limits left. Don't just ask for a "past tests" phrase: you need to know which controls are relevant to the behavior. If a check cannot be executed because a prerequisite is missing, the report must indicate it. A visible limit allows you to decide the next step; an alleged success hides it.
Brief for a limited technical modification
Problem: Describe the observed behavior and how to reproduce it. Objective: indicates the expected result and the cases to be covered. Scope: Identify repositories and relevant area without enlarging work to unnecessary refactors. Delivery: revisionable changes, checks performed, observed result and limits. Before release or external actions, prepare the necessary material for the decision of the manager.
This example is an editorial model, not a executed configuration. It must be adapted to the project and its instructions. A management software with real data requires an appropriate environment for testing; a public page requires control of the behavior the reader will see. Do not use the dot to circumvent pre-requisites, permissions, or business decisions not yet made.
The AI prompt to program is useful when it makes the problem readable. It must not become a list of technicalities copied to seem precise. If the person responsible cannot verify the acceptance criterion, it is necessary to clarify the requirement or involve the technical referent, before taking the completion of the task as sufficient proof.
What environment does delegate work use?
The dot's cloud computer should not be confused with a Codex Cloud environment configured for the software. Codex Cloud works on computers managed by OpenAI; the dot can use environments already configured according to the path described. Work and Codex Guide and Tasks and memory.
To choose the environment, verify repositories, dependencies, control commands, and task sources. An environment that opens the code but cannot perform the relevant verification does not demonstrate the final behavior. A task can produce a useful proposal even with a limit, but that limit must appear in the result. The manager can then complete the prerequisite or choose another appropriate environment.
The Dots personal computer connection remains distinct from Codex and Work Sync. Local access requires an online device and open ChatGPT; files and logins are not automatically transferred to the cloud. Computers and Dots apps. The guide to Computer Dots Off comes into dependencies, useful even when coordination involves technical work.
Do not enter credentials in the briefs to start a verification. If an authorization is missing, the report must make it explicit. The necessary resources must be configured in the appropriate path, with the responsible person when needed. The same principle applies to a linked app or source, covered in the guide to Dots with Gmail, Drive and Slack.
How to distinguish completion, verification, and release?
Task completion, software correctness, and release were different. A task may have prepared changes without demonstrating all the required cases. A verification may be positive in the test environment and not yet represent a release. A release must have an observable result in the intended environment. Distinction is an operational quality criterion, not an automatic product promise.
For the review, ask for three elements: what has changed, what has been proven, and what remains uncertain. The diff allows the technician to control the scope. Evidence makes it possible to compare the result with the requirement. Uncertainties avoid turning a limit into a certainty. A long description without these elements makes it difficult to decide whether to accept the change.
If the change is about an interface, the revision must observe the user's path. If it concerns a calculation, it must compare input and expected result. If it concerns data import, it must verify the formats and problem cases defined in the project. You don't have to invent a huge suite of tests for each change, but the check must be relevant to what was asked.
External actions require a recognizable boundary. Preparing a release proposal is not the same as publishing. Dots documentation distinguishes permissions and actions; the guide to Permits and Approvals applies the principle also to steps with external consequences. The manager must know which version and which environment are involved.
Two hypothetical software projects for Italian SMEs
An e-commerce corrects a filter behavior
Imagine an Italian e-commerce that receives reports on a catalog filter. The dot can help keep demand, requirement, and open questions in order. The Codex task is about a limited change in the available repository. The brief describes the observed path and the desired result, without authorizing a complete rewriting of the search.
The technical result to be reviewed shall include diffs, relevant controls and any limits encountered. A referent tests the path in the appropriate environment and compares the behavior with the requirement. The dot can keep the status of the request visible, but should not summarize it as "solved" just because the task is finished. No tests have been performed for this example: it is a liability distribution model.
A study improves an import of files
Imagine an Italian studio using small software to import demonstration files. The problem is an unclear handling of some incomplete lines. Work can help prepare an understandable specification; Codex can work on editing; the dot can coordinate the points to be decided. However, the holder must establish which fields are mandatory and what to do with the missing data.
The task does not invent a business rule. The change is evaluated with agreed examples and expected output. If the software is to process real data, the tests should be organized in the appropriate environment, without randomly inserting them into the brief. The useful result makes it clear whether a line is accepted, rejected or reported according to the decision taken. The continuity of the dot keeps the project readable, does not replace the choice of the criterion.
Is Dots also an API for building agents in software?
The developer tool documentation describes separate agent APIs and SDKs: tools to integrate agents into the application and manage its execution. It does not automatically present them as a self-service API of its own ChatGPT dot. No basis was found in the sources consulted for inferring that availability from general capabilities. Official Guide to Agents Tools.
If you want an agent inside a management software, the question is architecture, data, identity, cost, and application control. If you want your dot to follow a project, the question is about a personal responsibility in the ChatGPT experience. They are different needs. The Guide to What are AI APIs clarifies the first path without turning it into a Dots function.
Workspace shareable agents also have separate documentation. They should not all be called dots. To compare development tools you can read Kimi Code, but the comparison must relate to technical work, environment and testing, not an automatic equivalence with Dots's persistent responsibility.
What mistakes to avoid and how to start a useful delegation?
The first mistake is giving an ambiguous requirement and expecting the agent to choose the business rule. The second is confusing dot cloud environment and Codex environment. The third is to call "verified" a task only completed. The fourth is to deduce a Dots API from the general agent APIs. A fifth is to use continuity to broaden the scope without a new decision.
To start, prepare a reproducible problem, goal, and acceptance criterion. Choose a limited technical task and ask for revisionable changes, evidence, and limits. The dot can help maintain the work map, while the technical contact verifies the result. The Guide to AI Agents for Companies It helps to give an owner these responsibilities.
If your project requires you to link coordination, code, and operational process, the path of Tailored software from Giallo can start from that first requirement and its test criterion. The choice of tools comes after a concrete question: what behavior is needed and what evidence will allow us to accept it.
Giallo Studio guides: methodology and sources
How we apply it in the company
Related resources
OpenAI Dots: ChatGPT's always-active agents explained
Do Dots work when your computer is off? Cloud, local access and login
Can Dots Send Emails? Permissions, Approvals, and Custom Rules
How to create the first Dot in ChatGPT and assign it a project
ChatGPT for coding
AI coding prompts: write, fix and explain code
Kimi Code: an agent for coding and development
AI APIs: what they are and how they workFAQ
What is the difference between Dots, Work and Codex?
Dots tracks personal responsibilities over time and can coordinate activities. ChatGPT Work focuses on complex tasks and deliverables; Codex is the experience dedicated to software development and technical work.
Can a dot delegate a task to Codex?
The documentation describes the creation of local tasks, the continuation of existing Codex tasks and the use of already configured Codex Cloud environments. The concrete conditions depend on the working context and the accesses available.
Does connecting the computer let the dot read every Codex chat?
It should not be inferred from the link. Dots, Codex and Work have distinct paths and contexts; you need to indicate the relevant task and verify what is actually accessible.
Does a completed Codex task mean the software works?
No, the completion status does not replace the verification. Evidence is needed about the requested behavior, appropriate controls, revision of changes and, for a release, verification of the affected environment.
Are Agents SDKs the API of my dot?
No, the developer tool documentation describes separate Agentic APIs and SDKs. No self-service API of your ChatGPT dot is documented in the consulted sources to be inferred from those general capabilities.
Which environment to choose for a software change?
Choose the environment where repositories, dependencies, and checks are available with appropriate access. Local work depends on the device; Codex Cloud uses managed environments configured for technical work, separate from the dot’s cloud computer.