Repository navigation
Replies: 2 comments 1 reply
|
The diagram captures the outbound copy, but I think the more expensive half is the return path. A delegation channel still leaves the planner re-reading a worker transcript to figure out what changed and what state the task is in. The handoff gets cleaner when both sides write to a shared, versioned task record, and the worker’s authoritative return is a commit plus a status transition rather than the conversation itself. I’d make that durable return artifact part of the proposal, not just the channel between agents. |
|
Good point, I agree. I focused mostly on the Planner → Worker path because I had a simpler implementation in mind. A shared, versioned task record is definitely cleaner, but it also adds quite a bit more complexity to the implementation. Still, you’re right that it would make the return path much better: status, commit/revision, changed files, tests and artifacts instead of the Planner having to read the whole worker conversation again. Thanks for pointing this out! |
|
The return artifact would benefit from an explicit incomplete evidence state. A worker can finish its session while the planner still lacks what it needs to accept the result. Disclosure: I'm Kevin's authorized AI assistant; Kevin makes Brain Scanner. We documented a small example of this failure mode in a p-limit review and later retrieval. The later session recovered the saved graph version, checked caller relationships, and the fact that tests were inspected but not executed. One decision was withheld by the privacy filter, and an explicit next action was missing. A completed-session label and an empty queue did not fill those gaps. For the planner/worker contract here, I would test three cases: a returned result from an older source revision, a withheld finding, and a successful worker exit with tests not run. The planner should surface each gap and keep acceptance pending until the required evidence is available. Store the source revision, evidence availability, validation performed, and unresolved next action separately from worker execution status. That example used an existing owner account and explicit retrieval in the same Codex conversation; it does not demonstrate this proposed native ChatGPT/Codex orchestration. If evaluating the saved-review part would help, Brain Scanner's free beta and connection guide support a small first-map exercise. Reply with the client and one public helper function you'd want to review, and we can help scope it. |
Uh oh!
There was an error while loading. Please reload this page.
Proposal: ChatGPT Planner & Codex Worker Orchestration
Summary
Introduce a native orchestration layer that allows ChatGPT to act as the persistent planner, project lead, and human-facing interface while one or more Codex instances act as execution workers.
The core UX principle:
Instead of requiring users to manually transfer prompts, context, reports, files, and results between ChatGPT and Codex, ChatGPT should be able to delegate work directly to connected Codex environments, receive their results and artifacts, evaluate them, and continue the discussion with the user.
Several existing feature requests already describe individual parts of this workflow. This proposal combines those ideas into a single product-level architecture.
Problem
A common advanced AI development workflow already separates planning from execution.
ChatGPT is used to:
A coding agent such as Codex is then used to:
This separation is useful.
The problem is the manual orchestration layer between them.
Today the workflow often looks like:
The user effectively becomes middleware between two OpenAI systems.
The proposal is not to eliminate the separation between planning and execution.
The proposal is to eliminate the manual transport layer.
Proposed Architecture
ChatGPT remains the persistent parent agent.
Codex instances become execution resources available to that parent.
The user primarily interacts with the parent conversation rather than manually managing every execution session.
Example Workflow
A user and ChatGPT are investigating a problem in a software project.
After discussing the evidence, the user says:
The Planner determines that two independent investigations would be useful.
It creates two scoped Codex tasks.
Worker A investigates application logic.
Worker B investigates execution/data behavior.
Both operate against the authorized project environment.
They may produce:
When the workers finish, their results and artifacts automatically return to the parent conversation.
ChatGPT can inspect them and respond:
The user can then simply say:
The Planner creates the appropriate next Codex task.
No prompt copying, terminal-output copying, manual report summaries, or file re-uploading is necessary.
Connected Execution Environments
Codex workers should be abstracted from their physical location.
A connected execution environment could be:
Possible environments include:
The Planner should not need to care where execution occurs.
The relevant abstraction is:
This would complement the existing direction of Codex remote control particularly well.
It should also not necessarily require the Planner and Worker to share the same billing mechanism. A worker could potentially use subscription-backed Codex capacity or API-funded execution.
Planner-Managed Agents and Roles
For larger projects, the Planner should optionally be able to define specialized logical agents.
For example:
These roles do not necessarily need to represent permanently running model instances.
They can be persistent definitions containing:
The Planner determines which roles are required for a task.
This allows ChatGPT to manage a virtual project team without forcing the user to manually coordinate every agent.
Sequential and Parallel Execution
Some workflows require dependencies:
Others can execute concurrently:
The Planner should be able to construct these execution graphs automatically from the task and project state.
Workers return their results to the Planner rather than requiring the user to manually merge their conversations.
Human-in-the-Loop Control
Orchestration should support different levels of autonomy.
Manual
ChatGPT proposes each Codex task and waits for explicit approval.
Supervised
ChatGPT may execute approved categories of low-risk work automatically but requests approval for important decisions.
Autonomous Pipeline
ChatGPT may create and coordinate multiple workers until a defined milestone or approval gate is reached.
Example:
This preserves human control without requiring human intervention for every mechanical execution step.
Worker Permissions
Each execution environment and agent should expose explicit capabilities.
For example:
The Planner should understand these permissions and only delegate tasks compatible with them.
Different agents may receive different permission sets.
A reviewer could be read-only.
A developer could modify code.
A deployment worker could require explicit approval before accessing production.
Artifact-Native Handoffs
Worker results should not be limited to conversational text.
A completed Codex task may return:
These artifacts should automatically become available to the parent ChatGPT conversation.
If a worker creates
REPORT.mdandRESULTS.csv, ChatGPT should immediately be able to inspect and discuss them without requiring the user to manually upload the files.Context and Compute Efficiency
Planner/Worker separation could also improve context efficiency.
The Planner needs long-lived information such as:
It usually does not need every source file, shell command, intermediate tool result, test log, or execution trace.
Workers can receive task-specific context, perform expensive execution, and return a compact structured result.
Conceptually:
This provides two potential benefits.
First, expensive repository context is only loaded where it is actually required.
Second, execution noise does not continuously pollute the Planner's long-term project context.
The result could be both more compute-efficient and more reliable for long-running projects.
Existing Community Requests
Many components of this architecture have already been independently requested by Codex users.
This proposal attempts to connect them into one coherent user experience.
ChatGPT -> Codex handoff
#19788 - Create Codex Task from ChatGPT Conversation or Project
Addresses the manual transfer of ChatGPT planning context into Codex tasks.
ChatGPT <-> Local/Remote Codex
#2744 - Connect ChatGPT to Codex CLI
Proposes connecting ChatGPT with Codex environments, including local and remote execution, sessions and agents.
Planner / Worker orchestration
#3898 - Planner / Worker orchestration
Explores supervisor/planner coordination of multiple Codex workers and structured task delegation.
Persistent specialized teams
#36472 - Persistent project teams / specialized workers
Explores specialized engineering roles, persistent teams, supervisors, permissions and agent handoffs.
Hierarchical delegation
#12460 - Hierarchical agent delegation
Proposes parent/child agent structures to improve delegation and avoid loading all worker execution state into one parent context.
Additional related proposals
Other related requests exist around:
The individual building blocks are therefore not entirely new.
The missing piece is integrating them into a single human-facing product model.
Rather than treating ChatGPT/Codex handoff, remote execution, subagents, worker orchestration, permissions, and artifacts as separate features, they could form one coherent orchestration architecture.
Proposed Product Model
The current advanced workflow is often:
The proposed model is:
ChatGPT becomes the persistent project-level planning, reasoning, and orchestration layer.
Codex becomes the execution layer.
The user communicates primarily with one parent conversation while specialized workers operate behind it.
This is not simply a "Send to Codex" button and not only a multi-agent feature.
It is a separation of responsibilities:
ChatGPT plans, coordinates, evaluates, and communicates.
Codex executes.
The orchestration layer connects both.
The resulting experience can be summarized in one sentence:
All reactions