Summary
Subagent-Driven Development (SDD) requires a fresh implementer for each task, but it does not define a durable task-to-agent ownership contract. On agent harnesses that can send a new turn to an existing child, this makes it possible for a controller to accidentally assign work for a new task to children created for earlier work.
In a sanitized observed case, work for a current task was sent to two pre-existing children associated with different task scopes, rather than to children created specifically for the current task. The harness followed the supplied targets, so this report is not alleging a runtime routing defect. The failure is a workflow guardrail gap: the controller had no explicit ownership check preventing an old target from being reused for a new task.
Impact
- The current task loses the isolation promised by SDD.
- An implementer or reviewer can carry irrelevant task context into a different task.
- Task briefs, reports, diffs, and review verdicts can become hard to attribute correctly.
- “Fresh eyes” review can be silently defeated.
- A resumed or long-running execution is difficult to audit because the progress ledger records task completion, but not which child was authorized to perform each role.
Root cause
-
The freshness invariant is stated but not operationalized. SDD says to use a fresh implementer per task, while other passages allow the same agent to continue work during a review/fix loop or to be “re-dispatched.” The boundary is not explicit: reusing a child is valid only for the same task and role; it must not be used as the dispatch mechanism for a later task.
-
The durable ledger has no agent ownership data. It records task completion and commits, but not the task key, role, child handle, lifecycle state, or whether a handle is still eligible for follow-up.
-
There is no pre-dispatch admission check. Before assigning a task, the controller is not required to verify that the target is either a newly created child for that task or the already-recorded child for that same task/role.
-
Completed or idle children can remain addressable. That makes an accidental follow-up easy unless the workflow explicitly marks them retired/closed after the task, where the harness supports it.
Expected behavior
For a new task, SDD should create and record new task-scoped children. Follow-up work may target an existing child only when all of the following match:
- task identity;
- role (implementer, reviewer, or explicitly designated fixer);
- expected lifecycle stage; and
- the child is still active and authorized for that task.
A child from an earlier task must never be reused as the implementer or reviewer for a later task merely because it is still addressable.
Proposed change
Add an explicit task-to-agent ownership guardrail to subagent-driven-development and its Codex guidance:
-
Maintain a small dispatch ledger alongside the existing progress ledger, for example:
| Task |
Role |
Child handle |
State |
Allowed next action |
| task key |
implementer |
opaque target |
active/done/retired |
same-task follow-up only |
-
Require a new child for every new task-scoped implementer and reviewer.
-
Define the allowed use of a follow-up/re-dispatch operation:
- allowed for a question, fix, or re-review within the same task and recorded role;
- forbidden when its task or role does not match the ledger entry;
- never substitute it for creating the next task’s implementer/reviewer.
-
Add a short pre-dispatch check:
- new task → create a new child and record the returned handle;
- existing child → verify task + role + lifecycle before sending follow-up work;
- mismatch or missing record → do not reuse; create the correct child.
-
When a task is complete, mark its children retired and close them on harnesses that support closing. Closing is useful lifecycle hygiene, but it should not be the only safeguard.
A brief worked example distinguishing a same-task review/fix loop from starting the next task would make this much harder to misapply.
Acceptance criteria
- The SDD workflow explicitly states that agent reuse is scoped to the same task and role.
- The durable execution record binds each dispatched child to a task and role.
- A controller has a documented check before sending work to an existing child.
- New tasks cannot silently reuse an earlier task’s implementer or reviewer.
- The guidance remains harness-neutral, with adapter-specific closure guidance where available.
Related issues
Environment
- Superpowers: 6.1.1
- Harness: Codex Desktop multi-agent environment
Privacy
This report is intentionally sanitized. It omits task identifiers, project/repository names, source code, local paths, account details, conversation/thread IDs, timestamps, and transcripts.
Summary
Subagent-Driven Development (SDD) requires a fresh implementer for each task, but it does not define a durable task-to-agent ownership contract. On agent harnesses that can send a new turn to an existing child, this makes it possible for a controller to accidentally assign work for a new task to children created for earlier work.
In a sanitized observed case, work for a current task was sent to two pre-existing children associated with different task scopes, rather than to children created specifically for the current task. The harness followed the supplied targets, so this report is not alleging a runtime routing defect. The failure is a workflow guardrail gap: the controller had no explicit ownership check preventing an old target from being reused for a new task.
Impact
Root cause
The freshness invariant is stated but not operationalized. SDD says to use a fresh implementer per task, while other passages allow the same agent to continue work during a review/fix loop or to be “re-dispatched.” The boundary is not explicit: reusing a child is valid only for the same task and role; it must not be used as the dispatch mechanism for a later task.
The durable ledger has no agent ownership data. It records task completion and commits, but not the task key, role, child handle, lifecycle state, or whether a handle is still eligible for follow-up.
There is no pre-dispatch admission check. Before assigning a task, the controller is not required to verify that the target is either a newly created child for that task or the already-recorded child for that same task/role.
Completed or idle children can remain addressable. That makes an accidental follow-up easy unless the workflow explicitly marks them retired/closed after the task, where the harness supports it.
Expected behavior
For a new task, SDD should create and record new task-scoped children. Follow-up work may target an existing child only when all of the following match:
A child from an earlier task must never be reused as the implementer or reviewer for a later task merely because it is still addressable.
Proposed change
Add an explicit task-to-agent ownership guardrail to
subagent-driven-developmentand its Codex guidance:Maintain a small dispatch ledger alongside the existing progress ledger, for example:
Require a new child for every new task-scoped implementer and reviewer.
Define the allowed use of a follow-up/re-dispatch operation:
Add a short pre-dispatch check:
When a task is complete, mark its children retired and close them on harnesses that support closing. Closing is useful lifecycle hygiene, but it should not be the only safeguard.
A brief worked example distinguishing a same-task review/fix loop from starting the next task would make this much harder to misapply.
Acceptance criteria
Related issues
Environment
Privacy
This report is intentionally sanitized. It omits task identifiers, project/repository names, source code, local paths, account details, conversation/thread IDs, timestamps, and transcripts.