Unified management and delivery of sub-tasks
For example, a permission management objective can be broken down into a permission API, a permission configuration page, and an audit log. The three results can be independently achieved and verified, but they still belong to the same product objective and require unified integration and final acceptance. This type of task is suitable for using Supervisor Change.
Break down tasks according to the deliverables
Comet will check whether it is worth splitting before the final Shape is confirmed. Supervisor Change is recommended only when the following conditions are met simultaneously:- At least two results can be independently implemented and verified;
- Each acceptance item in the overall goal can be clearly assigned to a certain sub-task.
- The dependencies among sub-tasks can be clearly expressed;
- Parallel execution or phased delivery can indeed reduce the overall waiting time.
children.yaml, using the comet.native.children.v2 format in RC1. The acceptance_index in this file stores the acceptance items of the overall target derived from brief.md, including each item’s acceptance ID, source, and full text; each sub-task only declares a unique name, its dependencies, and the acceptance IDs it covers. The Runtime checks for duplicate names, unknown dependencies, dependency cycles, and acceptance omissions.
The user selects the splitting plan and the advancement method
Before confirmation, Comet will display the overall goal, sub-task list, dependencies, and acceptance mapping. Users can adjust the split, continue to use a single Native Change, or choose an advancement method:
The advancement mode only determines where sub-tasks are executed; the split results, dependencies, acceptance criteria, and integration rules stay the same under both modes. When confirming the Supervisor split, the Runtime writes the selection as
coordination_mode to comet-state.yaml. Resuming the flow or re-entering Shape after a requirement change reuses this selection; only a new user-visible decision sends the flow back to Shape for you to reconfirm.
Before confirmation, the Runtime will not create sub-tasks, worktrees, or external sessions. When there are two or more sub-tasks involved, the ordinary “confirmation” cannot replace the selection of the advancement method.
After Comet shows the complete plan and both modes together, you can reply once, for example, “Confirm this plan and use A, multi-session collaboration.” Selecting only “A” chooses the mode without confirming the complete plan. Changes to the plan, acceptance criteria, or sub-tasks require confirmation again.
Each sub-task has an independent workspace
After the Shape is confirmed, the Runtime will first create a dedicated integration branch and integration worktree for the main task, and then, starting from the current commit of the integration branch, prepare independent worktrees and task packages for each sub-task. Each task package contains:- The roles and acceptance scope of sub-tasks;
- The only working directory;
- Current integration baseline submission;
runIdfor binding task reports;- Dependency conditions and stop conditions.
readyChildren which sub-tasks can start now. By default, the multi-session mode can start up to two independent sub-tasks simultaneously at most. The single-session mode runs sub-tasks in sequence. To switch to serial execution temporarily, the main session specifies the following when dispatching tasks:
Adopt multi-session parallel advancement in Codex
After selecting multi-session collaboration in Codex, the current session becomes the main session. It is responsible for assigning tasks, continuously checking progress, handling blockages, integrating verified results into the Runtime, and completing the final Verify of the main task. The main session does not directly enter the sub-task worktree to modify the code. Each sub-task inreadyChildren will be assigned to an independent task visible to the user. Independent tasks continue to use the current project and directly enter the subtask directory already prepared by the Runtime, without the need to create a separate worktree. When an independent task reports completion, the result still has to go through the sub-task Verify and Runtime integration; the main session continues with the next step based on the integrated state.
In Claude Code, Agent Teams is adopted for parallel advancement
In the interactive session of Claude Code, different subtasks can be run using Agent Teams. In PowerShell, it can be enabled through the following environment variables:readyChildren. only works within the subtask worktree specified by the Runtime and cannot create new workspaces, claim subtasks with unfulfilled dependencies, integrate main task branches, or create nested teams on its own.
Agent Teams is responsible for running multiple sessions, while Native Runtime remains responsible for the workspace, task status, verification, and integration: the recorded Runtime state is authoritative, the final acceptance of the main task is also performed by the Runtime, and messages from team members serve only as a progress reference.
Verify first, then integrate
Each sub-task must go throughactive → verified → integrated:
- The Builder completes the candidate implementation in the sub-task worktree and submits the result of binding the current
runId. - The independent Verifier checks the candidate submissions and the acceptance scope of sub-tasks;
- The Runtime only accepts rewards that match the role,
runId, and the current task status. - After verification is passed, the Runtime submits the verified information to the integration worktree of the Supervisor and runs the necessary integration checks.
integrated will subsequent sub-tasks that depend on it enter readyChildren.
After the integration is completed, a unified acceptance will be conducted
After all sub-tasks enterintegrated, the Runtime immediately advances the final Verify of the main task. The final Verify runs at least one integration check in the integration worktree and covers the complete acceptance scope of the overall target.
Only after the final verification is passed can the Supervisor Change enter the Archive. The user decides to retain the workspace, merge locally, push or create a PR according to Native’s archive delivery options (the option semantics are described in Archive and delivery). The target branch will not be modified in advance before the final delivery.
If the Verify fails in the end, the Runtime will retain the integration scene and will not reopen the sub-tasks that have already been integrated. The process will add a unique-named repair sub-task based on the actual failed acceptance items, supplement the acceptance mapping of the overall goal, and return a Shape for the user to confirm the new repair scope. After the last sub-task is integrated, small fixes may still be committed directly at the parent level, and the final Verify records the integration commit it actually verified; when resuming, an interrupted final-verification record is completed automatically or re-run as needed.
Recoverable task progress
Sub-task summaries,readyChildren, integration status, and the next action are all recorded in the Runtime state; the main session reads them with comet native status <supervisor-change> --details --json when resuming or advancing the work. You only need to tell the Agent to continue the current task — the main session handles these queries and the handoffs automatically.
When resuming a task, Comet follows the coordination_mode persisted by the Runtime and does not recreate existing sub-tasks or worktrees. multi-session continues with multi-session collaboration, and single-session continues with the current session advancing sub-tasks in sequence.
If the original Codex standalone session or Claude Code Agent Team no longer exists, Comet will re-read the Runtime and automatically switch to subagent under multi-session. Tasks that have been dispatched but lost will first inactivate the old runId through supervisor-cancel, and then be redispatched using the new task package and runId. The late results of the old execution will be rejected. When the subagent is also unavailable, Comet will report a real block and will not automatically switch to single-session advancement.
Continue reading Native Loop] to understand the acceptance mechanism shared by the main task and sub-tasks. Read Multiple Changes and Specification Conflicts ] and Recovery Manual ] to learn about concurrent conflicts and interrupt recovery