Problem (one or two sentences)
Orchestrator can delegate work to a subtask and receive its completion summary, but it cannot later send follow-up work to that same subtask conversation. Repeated work therefore starts in a new context, even when the original agent already investigated the repository and made the relevant decisions.
Context (who is affected and when)
This is particularly useful in an implementation and review loop:
- Orchestrator delegates implementation to a Developer subtask.
- Developer implements the change, opens a PR, and completes.
- Orchestrator delegates review to a Reviewer subtask.
- Reviewer requests changes and completes.
- Orchestrator needs to ask the same Developer subtask to address the findings.
- Orchestrator then needs to ask the same Reviewer subtask to review the updated PR.
Today, steps 5 and 6 require new subtasks. Their previous conversation histories are unavailable to those new agents, so the Orchestrator must reconstruct and pass the context again. This adds work and may increase token usage and cost. The actual savings from reuse would depend on context length and provider caching.
Desired behavior (conceptual, not technical)
Allow Orchestrator to select one of its previously completed subtasks and send it a new message. That subtask continues with its existing conversation history and mode. When it completes the follow-up, Orchestrator receives a new completion result and can continue the workflow.
Developer and Reviewer should remain separate conversations. Each role would reuse only its own prior subtask.
Constraints / preferences (optional)
No response
Request checklist
Zoo Code Task Links (optional)
No response
Acceptance criteria (optional)
- Orchestrator can identify its eligible completed subtasks and resume a selected one with a new instruction.
- The resumed subtask retains its previous conversation history, mode, and relevant task settings.
- The parent pauses while the resumed subtask runs and receives its new completion result afterward.
- Repeated Developer → Reviewer → Developer → Reviewer cycles can reuse the original Developer and Reviewer subtasks.
- An unavailable, deleted, or incompatible subtask produces a clear error without silently starting a new one.
- A subtask cannot be resumed concurrently in two places.
- The task history clearly shows each follow-up run and its result.
Proposed approach (optional)
Expose a tool such as resume_subtask(task_id, message) alongside new_task, with the exact API and lifecycle left to the maintainers. The Orchestrator could retain the task IDs returned by delegation and choose between starting a new subtask and continuing an existing one.
This request concerns follow-up work after normal completion. It is distinct from restoring an interrupted parent–child delegation, previously discussed in #559.
Trade-offs / risks (optional)
Long-running conversations can accumulate irrelevant context and eventually require compaction. Reuse should therefore be optional; Orchestrator should still be able to create a fresh subtask when that is more appropriate.
Problem (one or two sentences)
Orchestrator can delegate work to a subtask and receive its completion summary, but it cannot later send follow-up work to that same subtask conversation. Repeated work therefore starts in a new context, even when the original agent already investigated the repository and made the relevant decisions.
Context (who is affected and when)
This is particularly useful in an implementation and review loop:
Today, steps 5 and 6 require new subtasks. Their previous conversation histories are unavailable to those new agents, so the Orchestrator must reconstruct and pass the context again. This adds work and may increase token usage and cost. The actual savings from reuse would depend on context length and provider caching.
Desired behavior (conceptual, not technical)
Allow Orchestrator to select one of its previously completed subtasks and send it a new message. That subtask continues with its existing conversation history and mode. When it completes the follow-up, Orchestrator receives a new completion result and can continue the workflow.
Developer and Reviewer should remain separate conversations. Each role would reuse only its own prior subtask.
Constraints / preferences (optional)
No response
Request checklist
Zoo Code Task Links (optional)
No response
Acceptance criteria (optional)
Proposed approach (optional)
Expose a tool such as
resume_subtask(task_id, message)alongsidenew_task, with the exact API and lifecycle left to the maintainers. The Orchestrator could retain the task IDs returned by delegation and choose between starting a new subtask and continuing an existing one.This request concerns follow-up work after normal completion. It is distinct from restoring an interrupted parent–child delegation, previously discussed in #559.
Trade-offs / risks (optional)
Long-running conversations can accumulate irrelevant context and eventually require compaction. Reuse should therefore be optional; Orchestrator should still be able to create a fresh subtask when that is more appropriate.