[Feature Proposal] Implement 'jointask' for Active Task Handoff & Contextual Collaboration

[rapus95]

What problem does this proposed feature solve?

Roo Code's current subtasking mechanisms, while valuable for decomposing complex problems, lead to significant context loss. When a subtask completes or a task becomes dormant, its accumulated internal state, reasoning, and learned information are not easily recoverable or directly transferable to other existing tasks in an automated fashion. While users can manually re-engage with an old task to revive its context, tasks themselves lack the ability to initiate this.

This limitation results in several inefficiencies:

• Information Silos: Valuable knowledge and context built within one task remain isolated and inaccessible to others that might benefit from it.
• Inefficient Workflows: Tasks may expend resources re-discovering information or re-solving problems that another (dormant) task has already processed.
• Limited Specialization & Collaboration: It's difficult for one task to directly "consult" or "delegate" a specific part of a problem to another pre-existing task that might have specialized knowledge or relevant history, without significant manual intervention.
• Loss of "Live Memory": The rich, dynamic context built up during a task's operation is effectively lost for future automated use once the task is no longer in the immediate execution chain.

Describe the proposed solution in detail

This issue proposes a new core command/functionality called jointask(target_task_id, message). This feature will enable an active roo task to:

1. Identify and Target: Specify a target_task_id corresponding to any pre-existing task, whether currently active, dormant, or previously completed.
2. Reactivate & Restore Context: The system will reactivate the target_task_id. Crucially, this reactivation will restore the target task's full prior context, including its memory, history, internal state, and any accumulated knowledge up to the point it last became inactive.
3. Inject New Input: The message (a string, prompt, or structured data) provided by the calling task will be passed as new input to the reactivated target task, guiding its subsequent actions within its restored context.

Essentially, jointask allows one task to "call for help," "delegate a sub-problem," or "pass the baton" to another specific task, bringing its "live memory" and specialized capabilities back into the active workflow. The target task, now equipped with its past knowledge and the new directive, can then continue processing, potentially using jointask itself to collaborate further or return results to the original caller or another designated task.

Key Functionalities & Benefits:

• Persistent Live Memory: Enables explicit access to and utilization of the rich contextual history of any task within the system instead of reading loads of files on task start ("memory bank approach")
• Specialized Team Workflow: Facilitates the creation and interaction of "teams" of specialist tasks (e.g., Code Analyst, API Researcher, Git Manager). Tasks can direct specific queries or sub-problems to the most appropriate specialist, which can then leverage its full historical context.
• Dynamic Contextual Handoff: Allows for seamless and context-rich transfer of information and control flow between tasks, far exceeding simple output-input chaining.
• Reduced Redundancy: Minimizes re-work by allowing tasks to build directly upon each other's specific prior efforts and findings.
• Foundation for Advanced Features: This mechanism serves as a foundational building block for more sophisticated capabilities like:
  • Smarter Task Compression/Summarization: New tasks can ask their ancestors for key insights, thus accelerating the progress after compression if something was missed.
  • Proactive Assistance: Orchestrator mode could itself create dedicated specialists not just by introducing new modes but also by controlling which task focuses on what topic.

Technical considerations or implementation details (optional)

• Task Identification: Assumes a robust system for persistent, unique task IDs. For example, by always having the current task ID as part of the generated prompt. If the current task knows its own ID, it can communicate it to other tasks.
• Message Injection: The message from the calling task should be added to the reactivated task's history as a new prompt or input, allowing it to process it naturally, in the same way it would get up running again if the user entered a new prompt.
• Task Spawning and Mode Switching: Supplying predefined IDs or maybe even name tags as the first parameter would generalize mode switching and task creation. For example, jointask(0, "dothat") could create a new task in the same mode as the caller. jointask(CODE, "dothat") could be a generic approach to switch to the code mode. Optionally, it could be designed as a 3 argument function, supplying the target mode as a dedicated argument.
• New Capability Rule: Have a toggleable capability for task joining as that's way more powerful than subtask starting.

Describe alternatives considered (if any)

1. Manual User Re-engagement: Users can currently re-open and interact with old tasks by looking them up in the history and providing new input.
   * Why jointask is preferred: Manual re-engagement is not automated, cannot be initiated by tasks themselves, and doesn't scale for complex, autonomous inter-task workflows. jointask empowers tasks to perform these contextual handoffs.
   2. Standard Subtasking: Creating new subtasks to handle parts of a problem.
   * Why jointask is preferred: Standard subtasking typically involves creating a new task, which starts with a limited, explicitly passed context. It doesn't allow for re-engaging an existing, specific task with its full, rich historical context. jointask is about leveraging the "wisdom" and "experience" of specific, previously active tasks.
   3. Passing Extensive Context Payloads: Tasks could attempt to pass all potentially relevant historical data to new tasks or via messages.
   * Why jointask is preferred: This is highly inefficient, verbose, and makes it difficult for the receiving task to discern the most relevant information. jointask revives the entirety of a specific task's inherent context, making it immediately available and operational without massive data transfers in the jointask call itself. The "memory" is already within the target task.

Additional Context & Mockups

The core idea is to enable a "team" of roo agents to collaborate more effectively by explicitly calling upon each other, bringing their unique histories and specializations to bear on a problem. This is analogous to how human teams operate, where one member might consult another with specific expertise or prior experience on a related matter.

Example Scenario: Implementing a Minecraft Entity

Imagine a team of specialized roo tasks, each with a unique ID:

• Orchestrator (ID: 2113)
• NetworkGuru (ID: 1237)
• GUIGuru (ID: 8832)
• Git Manager (ID: 1284)
• Main Developer Task (ID: 2232) - The task currently working on a new entity.

Disclaimer: Sent message would be longer and with a little more context (like the files currently working on, though, they can also be taken from active tabs). I've kept them intentionally short here for interaction demonstration instead of implementation demonstration.

Workflow using jointask:

1. Main Developer Task (2232) needs to implement an Entity:

   • Issues: Task 2232: jointask(8832, "I (Task 2232) need a new GUI that provides a 5*9 inventory for miner inventory, 6 dedicated slots (for those described in InventoryComponent) plus 2 progress bars that show remainingFuel and remainingEnergy and lastly a grid for access to the player inventory. And when I hit the R button while in GUI the miner needs to execute Rpressed on the server. Can you set that up?")

2. GUIGuru (8832) activates and -relying on previous GUI setup knowledge- starts building the GUI without having to fetch full GUI source again:

   • Implements GUI and keybindings and creates a first iteration payload X for server communication
   • Issues: Task 8832: jointask(1237, "Task 2232 requested GUI setup and Payload X to call Rpressed on the server side. Please implement the latter in accordance to the project guidelines. When done, report to 2232.")

3. NetworkGuru (1237) activates and

   • -relying on deeper understanding of the project networking approach- right away one-shots the network calling code. Again.
   • Issues: Task 1237: jointask(2232, "GUI and Networking are set up.")

4. Main Developer Task (2232) receives information and might run a round of testing before:

   • Issues: Task 2232: jointask(1284, "Miner entity finished. Please commit the changes. Once done, notify the Orchestrator (2113).")

5. Git Manager (1284) activates, prepares, and makes a git-history-aware commit since it knows the larger picture thanks to knowing all recently made commits.

   • Issues: Task 1284: jointask(2113, "The Miner entity is implemented and versioned. Commit hash: [commit_hash].")

6. Orchestrator (2113) is informed:

   • Acknowledges: Task 2113: "Noted. Next up is task 15. Implementing an engine item. Handoff to Architect for item design"

This example illustrates how jointask allows for a fluid, context-aware handoff between specialized tasks, mirroring an effective team workflow and preserving valuable accumulated knowledge within each task.

Conceptual Task Role Management (Usage Pattern):

A user or an orchestrator task could maintain a list of "specialist" task IDs for easier reference when using jointask.

// Example of how task IDs might be managed for easy lookup
"specialist_tasks": [
  "orchestrator": "2113",
  "network_guru": "1237",
  "gui_guru": "8832",
  "git_manager": "1284"
]

// Then a task could do:
// jointask(specialist_tasks["gui_guru"], "Please setup a gui with the following contents...");

Proposal Checklist

• I have searched existing Issues and Discussions to ensure this proposal is not a duplicate.
• This proposal is for a specific, actionable change intended for implementation (not a general idea).
• I understand that this proposal requires review and approval before any development work begins.

Are you interested in implementing this feature if approved?

• Partly. I would like but I fear it to be a huuuuge task tbh. And I won't be available for the next 2 weeks anyway (except today, 8.5.). But if there are questions or issues arise with the idea, I'd love to help tackling them on a conceptual level. And to sweeten the deal and get this awesome thing built, I'm throwing in a Roo Bucks bounty worth 50€ for whoever makes this magic happen!

[elianiva]

I've been thinking of something similar too, we basically need a 'structured' task output for boomerang instead of it being continuous and plain text like how it is now so that the agent can 'come back' to other task and have context of all previous tasks without it being too overwhelmed with the context noise.

I think to start off this work we need to improve the current sub-task system so that it outputs a more structural output which we can then store to reference later on. I've been using https://github.com/marv1nnnnn/rooroo for a few days and I like it, it's just that sometimes it's still 'overwhelming' and prefer to use plain ol' boomerang mode due to its simplicity — it doesn't generate a lot of files just to complete a single task I gave it.

What I'm thinking off right now is:

• Improve the current boomerang so it outputs a structured output — hopefully reliably
• The structured output should contain a bunch of details that can be read later on such as task title, summary, relevant context, etc. Basically similar to what rooroo is doing.
• Every time the agent finished a sub-task, it should output a single entry to this 'state' file
• Each entry should have a related 'history' file, so we can pass the 'outline' of the tasks but if we need the full context the agent can still reference it.
• This 'state' file should always be referenced in case it needs to 'come back' to the previous task

So the workflow is:

• Ask boomerang to do stuff
• It outputs structured plan, say, plan.jsonl
• Roo will execute the plan step by steps
• Every time Roo finishes, it should append an entry to a 'state' file containing information about the task it executes. Let's say it's called state.jsonl for the state, with each entry having a reference to a markdown file (the same format that we're already using to export a task, but it's now separated per sub-task)
• The state.jsonl can now be referenced so whenever Roo reads this file, it can hopefully figure out if the current task needs some wisdom from one of the previous tasks
• If it does, instead of continuing with the plan, it will 'come back' to the old task. Roo can also reference the chat history if needed for more context because we stored them before. Basically we now have a more elaborate boomerang interaction thing going on, instead of always moving linearly forward and create a 'branch' of sub-task, we can have a non-linear workflow since the progress gets passed around between each agents with previous context. Having a context compression would also help a lot because it can just keep going while preserving relevant context for each mode.
• The cycle repeats until it finishes

The reason why I wanted structured output so much is because:

• it's easier to work with instead of having an arbitrary 'summary', we can have different fields that contains different value, much more useful than having a single paragraph of summary
• it can be parsed which opens up the ability of having a dedicated UI. Imagine whenever you open up boomerang you can see the tasks it needs to execute, its progress, its context length, costs per subtask, etc. I don't think there's any coding agents / extension out there that does this orchestrating workflow yet, could be a good Roo selling point.

Think of a UI that looks something like this (we can go wild with some fancy iconography, progress indicator and whatnot)

- Setup Project (Doing) $0.14 - 14k
- Implement Feature A (TODO) $0 - 0
- Implement feature B (TODO) $0 - 0

--- later on

- Setup Project (Done) $2.14 - 42k
- Implement Feature A (Doing) $0.4 - 23k
- Implement feature B (TODO) $0 - 0

--- later on when it needs to reference stuff from the setup step, i.e. how are we setting up the project and what's the best way to structure this feature

- Setup Project (Doing) $3.2 - 54k
- Implement Feature A (Pending, needs [setup-project]) $1.4 - 43k
- Implement feature B (TODO) $0 - 0

Although, the model could just fail when generating a structured output, I've had a few of these errors when using rooroo (it fails to output a valid json).

It's still a rough idea, we definitely need to break this down into something that can be implemented incrementally — or we can try to implement it Roo Marketplace style (see: #2772), basically have a few people work on a single big PR from a separate repo

I'm definitely up for this if we want to make it happen :)

[AlephBCo]

Maybe I'm missing something, but the example scenario under "Example Scenario: Implementing Vertex AI Caching" does not match the logic proposed under "Describe the proposed solution in detail". The example scenario seems far simpler than the logic proposed. Can you provide an example scenario that matches the logic?

To put it clearly:

• The jointask proposal emphasizes reactivating a target task (target_task_id) and crucially having it operate within its fully restored historical context (its "Live Memory", previous reasoning, state, accumulated knowledge). The core benefit highlighted is leveraging the specific past experience and state of that target task to handle the new input message.

• The Vertex AI Caching example primarily demonstrates task delegation based on role specialization. Main task (2232) sends specific, largely self-contained requests to specialist tasks (Researcher 8832, Analyst 1237, Git Manager 1284). While these tasks could theoretically use their past history, the example doesn't show interactions where accessing that specific history is essential to fulfill the request. For instance, the Analyst (1237) is given a repo URL and likely just needs its general code analysis ability, not necessarily its memory of analyzing other unrelated repositories previously. The example showcases a valuable workflow (delegation) but doesn't strongly illustrate the unique "restore full context/live memory" aspect that distinguishes jointask from simply creating a new subtask with a specific role/prompt.

[rapus95]

Tl;Dr: The lack of proper non-llm knowledge bases gives much value to dynamic llm-context based knowledge.

@AlephBCo ah, yeah, you're right. I lost a key aspect of the problem when transforming my own use case/problem to a more general one. I was operating under the assumption that there is a limited api docs source w/o available MCP tooling (in my case, I'm minecraft java modding and there's no public javadoc but only yarn-mappings which are decompiled). It doesn't make sense that the researcher needs to read the method signatures fomr a repomix entirely each time a question arises. So it may read it once and then be sticky, so every task which needs insights can do so by leveraging that existing context. Making them "same context-different modes" would blow up the context unnecessarily. And if the api researcher found related signatures (that btw can be a very fast model, once available it might even be offloaded to some vector similarities) the analyst can try to make sense from that part of the code. Here again, it's really context-efficient to have a network specialist that knows how to set up the network parts (because it already knows the network code), a render specialist (who already knows how to set up rendering for entities) etc. So each time a new entity needs networking, it calls into the same network specialist to implement a packet send. In some times it might even be able to one-shot it right away as it learned from previous implementation tasks (for example if it missed imports the last time).

I'll replace the example given with my actual use case.

EDIT: original proposal updated!

[porocode11]

An idea I was thinking today is about task suspending and resume, not sure if this issue is about this or not but here's my logic and issues with currently roo-code implementation.

We have specialized modes for reasoning the code (architect) and writting the code (code) and an mode to delegate tasks. The issue (at least from what I could understand, correct me If I'm wrong) is that an task/mode state does not persist.

This causes cache to not persist and $ spent for no reason. Anytime Orchestrator needs to delegate an task, it opens an new one.

I don't think there is any reason for the Architect mode to always be in a new_task when delegated.

Personally I think an workflow like this would be better.

Orchestrator has an plan or Main task.
Option A: Has an already made plan (plan.md) which orchestrator acts upon, it can create an Architect (if it was not made before, made the user was in architect mode first, if so we use that).
Option B: Task is given without any other mode activated. Orchestrator creates the architect mode and have the user interact with it to formulate an plan (or some other way).

Code mode can always be created via new_task.
Architect mode, if needed we can switch to it via an new command.

This way, file that are already in context in architect mode are used to forumlate or edit the plan.

We can edit Code to disallow edit, or have a way (logic implementation) that we can add an file into context via /read-only. That way the cached files in Architect mode are not touched.

[rapus95]

@porocode11 your use case would be solvable with the proposed solution here, as the orchestrator could decide to join a new or an existing instance of code mode and architect.

[porocode11]

@rapus95 The proposed solution doesn't seem to fully solve it. jointask would pass context around, like file context etc which I think would be really useful but not an full solution.

The issue that this causes is that cache will only work if we are using one profile and calls are properly structured when context is joined from one task to another.

What I proposed is to allow some modes to only run one subtask per maintask. That way, Architect mode will always have full context it needs.

I think the issue propose is also an good idea, in case architect mode needs to pass small snippets of its whole context around for other task to act upon.

For example:
Architect mode can read like 100k+ context to have an idea what we need to edit, and pass the correct snippets of code to main-task (orchestrator) or subtasks (via jointask) so they can work on it.

After the work is done, if there's anymore need for Architect, the Orchestrator can resume that suspended task to continue with the new information (like snippets solution is not correct, we retry an new one).

The only issue I see here, is that we need to have an solution to mark some files as read-only, so no other modes changes the code and makes the active Architect task stale.

My suggestion is to have an way to pin or toggle an task to only run once per subtask (from main task), like let's say we do that with architect and an orchestrator can only run one architector per Main Task.

Jointask is useful also in the case I explained above.

Let me know what you guys think (maybe I should open an separate [Feature Proposal] for this. Still, my idea will need jointask anyhow for it to be powerful (since the architec will need a way to get new information from other tasks to know if the solution failed or not)

[rapus95]

What I proposed is to allow some modes to only run one subtask per maintask. That way, Architect mode will always have full context it needs.

Why doesn't that solve your use case?
1111: jointask(1121, "Orchestrator(1111) here, please design the requirements needed")
1121: *designs requirements *
1121: jointask(1111, "I finished, here's your catalogue of requirements requirements")
1111: jointask(1121, "Does requirement 5 mean that or taht?")
1121: jointask(1111, "It means "taht")

Here 1111 joined the same task twice (instead of creating a new one). I don't yet see why it's a requirement to restrict 1111 to ever be able to only access a singular architect task if it can intentionally join the same task in architect mode each time?

[porocode11]

@rapus95 But how will cache work in this case?

[rapus95]

@rapus95 But how will cache work in this case?

what kind of caching do you mean?
API caching? Should be bound to the task id
Context keeping? Each task has its own context, so they keep it just the same way as it is right now. The only change is that there now is a tool which allows automated revival of old tasks. The user could already do it manually.