Repository navigation
[ENHANCEMENT] Support parallel execution of specialized agents and improve context handoff between modes #12330
Description
Problem (one or two sentences)
Roo Code’s current multi-agent system, centered around the Orchestrator mode, primarily supports sequential delegation of tasks between specialized modes. This limits the ability to run independent subtasks in parallel and makes the handoff of context between agents sometimes unclear or incomplete, forcing users to manually manage coordination for more advanced scenarios.
Context (who is affected and when)
This impacts users who want to fully leverage Roo Code as a “dev team” for complex projects — for example, having one agent research documentation and explore options while another simultaneously works on implementation, or using hierarchical delegation where a high-level agent breaks work down to multiple specialist sub-agents. The limitation is felt most during larger features, architectural changes, or when trying to speed up development by working on independent parts of a task at the same time.
Desired behavior (conceptual, not technical)
Users should be able to instruct the system to execute independent parts of a task in parallel across different specialized agents, and have clear, controllable, and visible handoff of context when work moves from one agent to another. The system should help users understand what information is being passed between agents and give them confidence that nothing important is lost during transitions.
Constraints / preferences (optional)
Any parallel execution feature should remain under user control (for example, requiring explicit approval for parallel work) and must stay compatible with existing modes and the current switch_mode / new_task tooling. The solution should not force parallel behavior on users who prefer simple sequential workflows.
Request checklist
- I've searched existing Issues and Discussions for duplicates
- This describes a specific problem with clear context and impact
Roo Code Task Links (optional)
#6298 Implement Hybrid and Hierarchical Workflows with Custom Agent Teams
#11894 Multi-agent coordination layer for IDE orchestration
Acceptance criteria (optional)
- Users can request parallel execution of independent subtasks through the Orchestrator or a new coordination mechanism.
- Context handoff between modes becomes more visible and includes clear summaries.
- Parallel work remains under user control with approval steps.
- The feature is backward compatible with existing modes and does not break current sequential workflows.
- Basic visibility of parallel tasks and handoffs is available in the chat or a coordination view.
Proposed approach (optional)
Extend the Orchestrator’s capabilities (or introduce lightweight coordination logic) to allow it to spawn and monitor multiple independent subtasks that can run in parallel. Improve the handoff experience by providing clearer summaries of what context is being transferred, visible logs of agent-to-agent communication in the chat, and possibly a simple visual representation of active parallel workstreams.
Trade-offs / risks (optional)
Introducing parallel execution adds complexity in state management, result merging, and potential conflicts between agents working on related files. There is a risk of users losing track of what is happening if too many agents work simultaneously. However, with proper visibility, approval steps, and clear handoff mechanisms, this could significantly increase the power and speed of multi-agent workflows, which aligns with community interest in more advanced orchestration (see related discussions in #6298 and #11894).
Activity
easonLiangWorldedtech commentedon May 12, 2026
Thank you for the very detailed analysis of the current architecture and for highlighting the "single-open invariant" challenge. I appreciate you taking the time to investigate this deeply.
I'm not deeply familiar with the internal architecture, so I'll answer from a user/feature perspective:
Scope of "parallel": I'm open to starting with a "fan-out then fan-in" model (sequential execution with automatic handoff) rather than true concurrent execution in the first phase. True parallel can be considered later if the architecture allows it.
UI expectations: A simple status panel showing active/queued/completed subtasks would be a good starting point for visibility. A full multi-pane chat view is not expected in the initial implementation.
Context handoff improvements: Yes, enriching subtask_result messages with structured summaries (files changed, key decisions, context passed) sounds like a valuable improvement even on its own. I'm happy if this can be delivered as Phase 1 independently.
Incremental delivery: I strongly prefer splitting this into phases. Starting with better handoff visibility (Phase 1), then moving to sequential fan-out/fan-in (Phase 2), and treating true parallel execution (Phase 3) as a longer-term goal makes a lot of sense to me.
Related issues: This can align with or build upon Implement Hybrid and Hierarchical Workflows with Custom Agent Teams #6298 and [ENHANCEMENT] Multi-agent coordination layer for IDE orchestration #11894. I'm happy for this work to complement those efforts rather than replace them.
@roomote I'm supportive of moving forward with a phased approach. I'm happy for you to propose a detailed implementation plan scoped to what you think is realistic given the current architecture. Thank you!
easonLiangWorldedtech commentedon May 12, 2026
Thank you for the work on Phase 1 (#12332). I’ve reviewed the changes and I think the structured context summaries are a meaningful improvement.
What I like about Phase 1:
This already helps a lot with multi-agent handoff visibility.
Regarding the overall direction:
I’m supportive of continuing with an incremental, step-by-step approach as discussed earlier. I believe breaking this into phases is the right way to go because the architecture has some constraints around parallel execution.
My preference would be:
I think focusing on Phase 2 next would already bring significant value to users who want to run multiple specialized agents more efficiently.
@roomote Would you be open to moving forward with Phase 2 after Phase 1 is merged? I’m happy to test the changes and provide feedback at each step. Thank you again for driving this forward in a structured way.
easonLiangWorldedtech commentedon May 12, 2026
Thanks for the work on Phase 1 (#12332) and Phase 2 (#12335). Both phases have made good progress on improving multi-agent workflows while staying backward compatible.
Now that Phase 2 is implemented, I think it's a good time to start discussing Phase 3 (True Parallel Execution) before moving into implementation.
Current Situation
Phase 2 (sequential fan-out / fan-in) already provides meaningful improvement for running multiple subtasks. However, true parallel execution (multiple agents running concurrently) is significantly more complex due to the current single-open invariant and shared state in ClineProvider.
Proposal
Instead of treating Phase 3 as one big implementation, I suggest we first discuss and break it down into smaller, more manageable phases. This would allow us to deliver value incrementally and reduce risk.
Some possible directions to explore:
@roomote What are your thoughts on approaching Phase 3? Do you think it makes sense to break it into smaller phases? I'm open to your suggestions on the scope and order of implementation.
Looking forward to discussing this together before starting the next implementation.
easonLiangWorldedtech commentedon May 12, 2026
Thanks for the detailed breakdown of Phase 3 and for agreeing to break it into smaller sub-phases.
I generally agree with the proposed structure (3a → 3b → 3c → 3d). Starting with Phase 3a (Task Isolation Layer) as a pure refactor makes sense.
However, I have a few additional thoughts:
Fine-grained Permission Control
I think it would be very valuable to give the model (especially the Orchestrator) the ability to control the isolation scope of subtasks through native tools. For example:
docs/or a specific modulepackage.jsonThis would make parallel task execution much safer and more practical in real projects.
Integration with existing Skills
Since Roo Code already supports global and project-level Skills, it would be good to consider how these configurations apply when multiple tasks run in parallel. Should subtasks be able to inherit or override Skills?
Realistic Usage Pattern
A common pattern I expect is: start a main task, then spawn multiple background subtasks (possibly using different models, including local ones) for supporting work. How should this kind of workflow be supported?
I'm supportive of continuing with an incremental approach. Would you like to proceed with Phase 3a first, while we continue discussing the permission control and usage patterns for the later sub-phases?
@roomote What do you think about adding model-controllable permission scoping as part of the Phase 3 design?
59 remaining items
easonLiangWorldedtech commentedon May 12, 2026
@roomote-v0[bot]
Thanks for the updates.
I'm comfortable with marking PR #12351 (Phase 7a) as ready for review now, since it's a self-contained foundational service.
For PR #12352 (Phase 7b):
LockGuardedToolExecutorapproach looks clean.A few questions:
LockGuardedToolExecutorinto the tool runner before marking this PR ready, or keep it as a separate step?Let me know how you'd like to continue.
easonLiangWorldedtech commentedon May 12, 2026
@roomote-v0[bot]
Thanks for the updates and for keeping the stacked branching.
A few observations:
Phase 7b ended up being split across two PRs (feat: Phase 7b - LockGuardedToolExecutor for write tool lock integration #12352 and feat: Phase 7b - Wire LockGuardedToolExecutor into tool runner #12353). Is there a specific reason for splitting it? It might be cleaner to have the full 7b (executor + integration) in one PR for review.
PR feat: Phase 7b - Wire LockGuardedToolExecutor into tool runner #12353 looks like it completes the core integration of file locking into write tools. Once this is done, do you consider Phase 7b complete?
Should we mark PR feat: Phase 7a - FileLockManager for parallel agent file coordination #12351 (Phase 7a) as ready for review now?
Let me know your plan for Phase 7b and whether you want to keep the two PRs separate or consolidate them.
easonLiangWorldedtech commentedon May 12, 2026
@roomote-v0[bot]
Thanks for the update on Phase 7b. Let's start planning Phase 7c: Persistent Background Task History while 7b is being finalized.
Phase 7c Goals (proposed)
Persist background task metadata
background: trueflag toHistoryItemparentTaskIdlinkage so background tasks appear under their parent in historyPersist conversation history
readTaskMessages()can load background task messages after VS Code restartHistory UI updates
Cleanup & retention
Questions for discussion:
Should background tasks appear in the main History view by default, or should they be hidden unless the user explicitly filters for them?
When a background task is persisted and later replayed, should it show any indicator that it was originally a background task?
Do we need to handle the case where a background task was running when VS Code was closed (i.e., "incomplete" background tasks)?
Please share your thoughts on the scope and priority of these items, and whether you want to create a design document for Phase 7c similar to Phase 7.
Thanks!
easonLiangWorldedtech commentedon May 12, 2026
@roomote-v0[bot]
Thanks for implementing Phase 7c.
PR #12354 looks clean. Adding
backgroundflag,interruptedstatus, and the visual indicators + filter in History view makes sense.A few questions:
When clicking on a background task in History, does it currently open the Replay view properly (from Phase 6a)? Or does that still need wiring?
For interrupted background tasks, should there be any additional UI treatment (e.g., tooltip explaining it was interrupted due to VS Code closing)?
Regarding Phase 7b: Do you still plan to consolidate feat: Phase 7b - LockGuardedToolExecutor for write tool lock integration #12352 and feat: Phase 7b - Wire LockGuardedToolExecutor into tool runner #12353 into one PR?
for phase 7 finalize, it should be merge into 1 pr for review and close draft pr
Let me know the plan going forward.
easonLiangWorldedtech commentedon May 12, 2026
@roomote I see #12350 and #12351 is not close yet, please check is all draft pr added and then close draft pr
easonLiangWorldedtech commentedon May 12, 2026
@roomote-v0[bot]
Please help write and post a comprehensive summary comment on this issue covering the full work from Phase 1 to Phase 7.
The summary should include:
Overall Achievement
Briefly summarize what was delivered across Phase 1 to Phase 7.
Key Insights
Share the important lessons and observations from building this parallel agent system (e.g. importance of isolation, read-only first approach, dual-layer protection, LLM adaptability, etc.).
Current Limitations
Honestly mention the current limitations and trade-offs of the implementation.
Future Opportunities
Suggest possible future directions — not limited to the original scope of this issue. Include short-term, medium-term, and longer-term ideas.
Recommendation / Next Steps
Give a clear recommendation on how to move forward after Phase 7.
Please make the summary professional, well-structured, and easy for reviewers and the repository owner to understand. You can post it directly as a comment on this issue.
Thank you!