Proposal for resume_task Feature to Enhance Subtask Iteration in Roo Code

[ElemTran]

Dear Roo Code Team,

Thank you for developing such a powerful AI-assisted development tool. Based on practical usage observations, I would like to propose an improvement to the current subtask workflow to further enhance efficiency.

Current Mechanism and Limitations

1. Subtask Isolation:

   • When a subtask created via new_task completes and returns results, its context becomes unavailable for recall, even when the main task requires further iteration.

2. Redundant Consumption:

   • If the main task needs to continue operations based on subtask results (such as adding features or correcting omissions), the model must generate a brand new subtask (by calling new_task again), resulting in duplicate context transmission and additional token consumption.

3. Lack of Flexibility:

   • The current workflow cannot support progressive optimization of subtasks (such as extending partial implementations or fine-tuning logic), requiring complete re-execution instead.

Proposal: Adding resume_task Functionality

We suggest implementing resume_task while maintaining new_task, to achieve:

1. Historical Subtask Reuse:

   • The main task can select completed subtasks through filters (e.g., time, keywords) and restore their complete context (input/output/conversation history).

2. Incremental Instructions:

   • Append new instructions to resumed subtasks (e.g., "add error handling logic") without needing to restate full requirements.

3. Token Optimization:

   • Directly reuse the original subtask thread, reducing token overhead from duplicate context transmission.

Revised Usage Scenario

Example: The main task creates a subtask "Implement user login API", which returns a basic implementation lacking error handling.

• Current Workflow: The main task must create a new subtask like "Add error handling to login API" and resend all code context.
• Improved Workflow: The main task can use resume_task to restore the original subtask and directly append instructions like "Extend the previous implementation to include input validation and timeout handling", preserving all original code and discussion records.

Expected Benefits

• Reduced Token Consumption: Avoids duplicate transmission of code or lengthy contexts.
• Supports Iterative Development: Ideal for features requiring phased improvements (e.g., debugging, documentation completion).
• Seamless Compatibility: new_task remains available for independent new tasks, with resume_task as an optimization option.

We understand this feature may require designing permission rules for subtask restoration or UI interactions. We're happy to discuss implementation details or alternative solutions further. Thank you for your consideration!

Best regards,

[HobbesSR]

I suppose at this point we're moving very close to the model of Google's Agent2Agent Protocol where an agent is defined as an independent LLM context. And you've made a good point, an orchestrating task may need a dialogue with its subtasks, while remaining unaware of the subtasks entire context.

[ElemTran]

Thanks for your reply and the excellent analogy! The A2A Protocol indeed provides a great framework for thinking about these kinds of task collaboration and orchestration problems.

I had also considered the possibility of A2A. The currently proposed resume_task can be seen as a step towards smarter inter-task interaction; it focuses on solving the core problems of context loss and repetitive calls in current subtask iterations, and I believe it can cover many common iterative optimization scenarios.

In the long run, if Roo Code could support a more general agent-to-agent communication and collaboration mechanism similar to the A2A protocol in the future, that would be very exciting. It would also better support more advanced task decomposition and planning. Looking forward to seeing developments in this area in the future!