What would you like to be added?
Add an explicit, experimental coordination path for multiple independent Qwen Code sessions.
A leader should be able to dispatch two or three self-contained workers while remaining interactive, observe correlated runtime and task states, collect structured results, answer targeted questions, and accept or reject each result. Read-only workers may share the current checkout only under an enforceable read-only execution profile; any writer must use an independently owned Git worktree, with the leader as the only merge authority.
This should reuse the collaboration semantics already present in Agent Team and the persistent session runtime being built by Agent View. Arena should remain the competitive execution mode. The initial scope should be Qwen-only and opt-in; heterogeneous CLI orchestration can remain an external-runtime concern.
Why is this needed?
Qwen Code already has most of the pieces, but they do not yet form one safe end-to-end workflow. Agent Team covers in-process tasks, ownership, dependencies, and messaging. Agent View covers independent PTY-backed sessions, attach/detach, lifecycle, and a roster. Users still have to manually bridge those layers when they want several long-running Qwen sessions to investigate or implement separate parts of one task.
Without a coordination contract, a leader can mistake session idle for task success, collect a result from the wrong prompt, block while polling workers, or let concurrent writers collide in one checkout. The first release should therefore prove a small read-only dispatch/collect loop with prompt/result correlation and measurable quality, latency, token, and recovery gates before adding writer worktrees or richer handoff behavior.
This is related to #1815, #6383, #6093, #5239, and #8586, but focuses on the missing integration and evaluation boundary rather than replacing those tracks.
Additional context
The proposed direction is intentionally incremental:
- Finish and harden the current Agent View stack before exposing automated coordination.
- Dogfood a two-stage, read-only coordinator with no nested fan-out.
- Add one isolated writer worktree only if the read-only experiment passes its go/no-go criteria.
- Add structured hands-up and follow-up behavior only after real workflows demonstrate the need.
A draft implementation and evaluation plan will be attached in a documentation PR.
What would you like to be added?
Add an explicit, experimental coordination path for multiple independent Qwen Code sessions.
A leader should be able to dispatch two or three self-contained workers while remaining interactive, observe correlated runtime and task states, collect structured results, answer targeted questions, and accept or reject each result. Read-only workers may share the current checkout only under an enforceable read-only execution profile; any writer must use an independently owned Git worktree, with the leader as the only merge authority.
This should reuse the collaboration semantics already present in Agent Team and the persistent session runtime being built by Agent View. Arena should remain the competitive execution mode. The initial scope should be Qwen-only and opt-in; heterogeneous CLI orchestration can remain an external-runtime concern.
Why is this needed?
Qwen Code already has most of the pieces, but they do not yet form one safe end-to-end workflow. Agent Team covers in-process tasks, ownership, dependencies, and messaging. Agent View covers independent PTY-backed sessions, attach/detach, lifecycle, and a roster. Users still have to manually bridge those layers when they want several long-running Qwen sessions to investigate or implement separate parts of one task.
Without a coordination contract, a leader can mistake session
idlefor task success, collect a result from the wrong prompt, block while polling workers, or let concurrent writers collide in one checkout. The first release should therefore prove a small read-only dispatch/collect loop with prompt/result correlation and measurable quality, latency, token, and recovery gates before adding writer worktrees or richer handoff behavior.This is related to #1815, #6383, #6093, #5239, and #8586, but focuses on the missing integration and evaluation boundary rather than replacing those tracks.
Additional context
The proposed direction is intentionally incremental:
A draft implementation and evaluation plan will be attached in a documentation PR.