Feature Request: Agent Team - Multi-Agent Collaboration

[tanzhenxin]

What would you like to be added?

Agent Team is a collaborative execution feature that allows users to coordinate multiple AI agents working together as a team. One session acts as the team lead, coordinating work, assigning tasks, and synthesizing results. Teammates work independently in their own context windows and can communicate directly with each other to collaborate on complex tasks.

Why is this needed?

Current Pain Points

1. Limited parallel collaboration: Subagents can only report back to the main agent, preventing peer-to-peer collaboration between workers
2. Coordination overhead: Complex tasks requiring multiple perspectives require manual management of separate sessions
3. Context isolation vs. collaboration trade-off: Single sessions lack parallel exploration, while separate sessions lack coordination mechanisms
4. No centralized task management: No built-in way to assign, track, and coordinate tasks across multiple independent agents

Expected Value

1. Parallel exploration: Multiple teammates can investigate different aspects of a problem simultaneously, then share and challenge each other's findings
2. Independent ownership: Teammates can own separate pieces of work (modules, layers, concerns) without stepping on each other
3. Direct collaboration: Teammates communicate directly with each other, enabling debate, peer review, and consensus building
4. Scalable coordination: Team lead manages orchestration, task assignment, and synthesis, allowing users to focus on high-level direction

Core Requirements

1. User Entry Point

Provide a natural language interface for users to create and manage agent teams.

• Users can request a team by describing the task and desired team structure in natural language
• Support explicit teammate specification (number of teammates, assigned roles/models)
• Allow both user-initiated and system-suggested team creation (with user approval)

2. Team Structure and Roles

Establish a clear hierarchy with team lead and teammates.

• Team Lead: The main session that creates the team, coordinates work, assigns tasks, and synthesizes results
• Teammates: Independent agent instances that work on assigned tasks and communicate with each other
• Support spawn-time configuration of teammate roles and responsibilities

3. Display Modes

Provide flexible ways to visualize and interact with the team.

• In-process Mode: All teammates run inside the main terminal; use hotkeys to select and message teammates directly
• Split-pane Mode: Each teammate gets its own terminal pane for side-by-side visibility and interaction
• Support mode auto-detection based on terminal environment (tmux/iTerm2 availability)

4. Shared Task Coordination

Enable collaborative task management across the team.

• Shared task list with states (pending, in progress, completed)
• Task dependency management (blocked tasks until dependencies complete)
• Support both lead-assigned and self-claimed tasks
• Race-condition-free task claiming mechanism

5. Inter-Agent Communication

Allow teammates to communicate directly with each other.

• Direct messaging: Send messages to specific teammates
• Broadcasting: Send messages to all teammates simultaneously
• Automatic delivery: Messages delivered without polling or lead intervention
• Idle notifications: Teammates notify the lead when finishing work

6. Quality Control and Oversight

Provide mechanisms to ensure work quality and alignment.

• Plan approval: Require teammate plans to be approved by the lead before implementation
• Delegate mode: Restrict the lead to coordination-only (no direct code changes)
• Hooks: Support TeammateIdle and TaskCompleted hooks for quality gates

7. Lifecycle Management

Support graceful team startup and shutdown.

• Graceful teammate shutdown (with approval/rejection)
• Team cleanup to remove shared resources
• Prevention of orphaned resources or sessions

Additional context

User Entry Point Examples

Create an agent team to explore a CLI tool design from different angles:
one teammate on UX, one on technical architecture, one playing devil's advocate.

Create a team with 4 teammates to refactor these modules in parallel.
Use Sonnet for each teammate.

Acceptance Criteria

• User can create an agent team by describing task and team structure in natural language
• Team lead coordinates work, assigns tasks, and synthesizes results
• Teammates work independently in their own context windows
• Teammates can communicate directly with each other (message/broadcast)
• Shared task list coordinates work across the team with dependency support
• User can interact with any teammate directly (in-process or split-pane mode)
• Plan approval workflow allows lead to review and approve teammate plans
• Team can be gracefully shut down and cleaned up

Key Differences vs. Related Features

	Agent Team	Agent Arena	Agent Swarm
Goal	Collaborative: Tackle different aspects together	Competitive: Find the best solution to the same task	Parallel processing: Dynamically spawn workers for batch tasks
Entry Point	Natural language request describing task and team	/arena slash command with explicit --models	Tool call during execution (spawn_swarm_worker)
Agent Creation	Teammates dynamically created with roles	Pre-configured models compete	Workers created on-the-fly, no pre-definition
Relationship	Agents collaborate; lead synthesizes results	Agents compete; user selects winner	Workers execute independently; parent aggregates
Communication	Direct peer-to-peer messaging between teammates	No agent-to-agent communication	One-way: results aggregated by parent
Coordination	Self-coordination via shared task list	Parallel execution with final selection	Parent agent manages spawning and result collection
Context	Independent sessions with shared task list	Completely isolated (separate worktrees)	Lightweight ephemeral context per worker
Lifecycle	Persistent team with ongoing collaboration	Session-based with comparison phase	Ephemeral: spawn → execute → return → cleanup
Output	Synthesized results from multiple perspectives	One selected solution applied to workspace	Aggregated results from parallel batch processing
Best for	Research, complex collaboration, cross-layer work	Benchmarking, choosing between model approaches	Batch operations, data processing, map-reduce tasks

[DanubeRS]

Is it expected that this could unlock individual sub-agents being run on different models? Given that a team is an orchestration of sub-agents, I would assume this is a requirement for this feature.

I was developing a tool that would delegate documentation scraping & search to a reasoning model with a broader context and specialised tools. Unfortunately, I cannot fork off this work to a separate set of resources.

By the sound of it, this would help unlock multi-model delegation as well as a degree of parallelisation.

Thanks!

[AlexParamonov]

Is it expected that this could unlock individual sub-agents being run on different models? Given that a team is an orchestration of sub-agents, I would assume this is a requirement for this feature.

I was developing a tool that would delegate documentation scraping & search to a reasoning model with a broader context and specialised tools. Unfortunately, I cannot fork off this work to a separate set of resources.

By the sound of it, this would help unlock multi-model delegation as well as a degree of parallelisation.

Thanks!

i was using this patch qwen code did itself for a while now, works well, so you dont have to wait for this to be merged to use different models in subagents:

@@ -175655,6 +175655,47 @@
        * @returns {Promise<void>} A promise that resolves when the subagent has completed its execution.
        */
       async runNonInteractive(context2, externalSignal) {
+        // Save original model config to restore after subagent finishes
+        const originalModel = this.runtimeContext.getModel();
+        const originalContentGenConfig = this.runtimeContext.getContentGeneratorConfig();
+        const originalAuthType = originalContentGenConfig?.authType;
+        let authTypeWasModified = false;
+        
+        // Convert string authType from YAML to AuthType enum if needed
+        if (this.modelConfig.authType && typeof this.modelConfig.authType === "string") {
+          const authTypeMap = {
+            "qwen-oauth": AuthType2.QWEN_OAUTH,
+            "openai": AuthType2.USE_OPENAI,
+            "gemini": AuthType2.USE_GEMINI,
+            "vertex-ai": AuthType2.USE_VERTEX_AI,
+            "anthropic": AuthType2.USE_ANTHROPIC
+          };
+          const enumValue = authTypeMap[this.modelConfig.authType];
+          if (enumValue) {
+            this.modelConfig.authType = enumValue;
+            authTypeWasModified = true;
+          } else {
+            console.warn(`Subagent "${this.name}" unknown authType "${this.modelConfig.authType}", using current`);
+          }
+        }
+        // Switch to subagent's model and authType if specified
+        if (this.modelConfig.model || this.modelConfig.authType) {
+          const targetAuthType = this.modelConfig.authType || originalAuthType;
+          const targetModel = this.modelConfig.model || originalModel;
+          // Look up the model config from registry to get baseUrl and other settings
+          const modelsConfig = this.runtimeContext.getModelsConfig();
+          const modelRegistry = modelsConfig?.modelRegistry;
+          if (modelRegistry && targetAuthType) {
+            const modelConfig = modelRegistry.getModel(targetAuthType, targetModel);
+            if (modelConfig) {
+              console.log(`Subagent "${this.name}" switching from model "${originalModel}" to "${targetModel}" (authType: ${targetAuthType}, baseUrl: ${modelConfig.baseUrl})`);
+              await this.runtimeContext.setModel(targetModel, { reason: `Subagent "${this.name}" execution` });
+              await this.runtimeContext.refreshAuth(targetAuthType);
+            } else {
+              console.warn(`Subagent "${this.name}" model "${targetModel}" not found for authType "${targetAuthType}", using current config`);
+            }
+          }
+        }
         const chat = await this.createChatObject(context2);
         if (!chat) {
           this.terminateMode = SubagentTerminateMode.ERROR;
@@ -175833,6 +175874,20 @@
           });
           throw error40;
         } finally {
+          // Restore original model and authType if subagent switched them
+          try {
+            if (originalModel && this.runtimeContext.getModel() !== originalModel) {
+              console.log(`Subagent "${this.name}" restoring model to "${originalModel}"`);
+              await this.runtimeContext.setModel(originalModel, { reason: `Subagent "${this.name}" finished` });
+            }
+            // Restore to original authType (not the modified this.modelConfig.authType)
+            if (originalAuthType && authTypeWasModified) {
+              console.log(`Subagent "${this.name}" restoring authType to "${originalAuthType}"`);
+              await this.runtimeContext.refreshAuth(originalAuthType);
+            }
+          } catch (restoreError) {
+            console.error(`Subagent "${this.name}" failed to restore model/auth:`, restoreError);
+          }
           if (externalSignal) {
             externalSignal.removeEventListener("abort", onExternalAbort);
           }