subagents

The cost of saying yes has changed (opens in new tab)

Dalia is a software engineer on GitHub’s Copilot Agent Control Plane team. Her work focuses on building the subagent governance layer for Copilot customers. ### Role and Focus - Works on GitHub Copilot’s Agent Control Plane. - Builds governance capabilities for subagents. - Supports Copilot customers through controls and management features. The provided content contains only a brief professional description, not a full blog post, so there are no additional technical sections or conclusions to summarize.

How we made GitHub Copilot CLI more selective about delegation (opens in new tab)

GitHub improved Copilot CLI by making subagent delegation more selective rather than treating delegation as inherently beneficial. The new orchestration policy keeps narrow tasks with the main agent, delegates broad or independent work, and encourages parallel execution instead of waiting. After full production rollout, it reduced tool failures by 23% and improved high-percentile wait times without reducing quality. ## The Cost of Unnecessary Delegation - Subagents help with complex investigations, large repositories, and parallel work, but every handoff adds tool calls, coordination, and latency. - Copilot sometimes delegated simple, well-scoped tasks that the main agent could complete directly. - Common problems included: - Repeated or overlapping repository searches. - Subagents re-discovering context already available to the main agent. - Sequential delegation that left the main agent idle. - Stale paths, incorrect relative paths, and workspace mismatches. - The result was slower execution and more tool failures for tasks that should have required only a few steps. ## How the Problem Was Identified - GitHub used LLMs to analyze complete agent trajectories rather than manually reviewing sessions. - The analysis found that delegation was frequently used for narrow, obvious, or fully described tasks. - This led to a clear target: - Keep focused discovery-and-edit work with the main agent. - Reserve subagents for broad exploration, cross-cutting tasks, or genuinely independent work. ## A More Selective Orchestration Policy - Copilot now starts with the narrowest effective workflow: - Find and read the relevant file. - Make the targeted change. - Verify the result. - Delegation becomes appropriate when additional context, uncertainty, or parallel execution creates real value. - Subagents are treated as a parallelism mechanism, not a reason for the main agent to pause. - Handoffs should clearly specify: - The user’s request. - What the main agent already knows. - Which work the subagent owns. - What result the subagent should return. ## Evaluation and Production Results - GitHub tested the change with generated regression cases and existing benchmarks before rollout. - Staff and public A/B tests measured reliability, responsiveness, subagent workload, and quality. - Production results showed: - 23% fewer tool failures per session. - 27% fewer search-tool failures. - 18% fewer edit-tool failures. - 5% lower P95 wait time. - 3% lower P75 wait time. - No quality regression. - The improvements came mainly from avoiding unnecessary subagent paths and reducing orchestration overhead, not from making individual model calls faster. Copilot CLI users can access the improvement by running `/update` and upgrading to version 1.0.42 or later. The broader recommendation is to delegate selectively: use the main agent for focused tasks and subagents only when independent context or parallel work provides meaningful leverage.

Run multiple agents at once with /fleet in Copilot CLI (opens in new tab)

GitHub Copilot CLI’s `/fleet` command lets multiple subagents work on independent tasks simultaneously rather than completing everything sequentially. An orchestrator decomposes the objective, manages dependencies, dispatches agents, and verifies their results. To benefit from parallel execution, users should define clear deliverables, boundaries, dependencies, and validation requirements. ## How `/fleet` Works - Breaks a task into discrete work items and identifies dependencies. - Runs independent items in parallel as background subagents. - Waits for completed work before dispatching dependent tasks. - Verifies results and assembles the final output. - Gives each subagent its own context window while sharing the same filesystem. - Prevents direct communication between subagents; the orchestrator coordinates them. ## Getting Started - Run `/fleet <objective prompt>` interactively, such as: ```bash /fleet Refactor the auth module, update tests, and fix the related docs in docs/auth/ ``` - For terminal-based non-interactive use: ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - The `--no-ask-user` option is required when no one is available to answer prompts. ## Writing Parallelizable Prompts - Define concrete deliverables such as individual files, test suites, or documentation sections. - Avoid vague requests that make it difficult to identify independent work. - Explicitly state: - File or module ownership - Constraints, such as avoiding dependency changes - Required tests, linting, or type checks - List dependencies so the orchestrator can serialize only the necessary work while parallelizing the rest. ## Using Custom Agents - Specialized agents can be defined in `.github/agents/`. - Agent definitions may specify: - Model - Tools - Role-specific instructions - Prompts can assign different agents to different tracks, such as using a technical writer for documentation and the default agent for code. - If no model is specified, the agent uses the current default model. ## Monitoring Fleet Execution - Review the initial decomposition to ensure the task has multiple independent tracks. - Use `/tasks` to inspect active background work. - Look for progress updates from separate tracks. - If work is proceeding sequentially, ask Copilot to decompose the task first and report each track’s status and blockers. ## Avoiding File Conflicts - Subagents share a filesystem without file locking. - If two agents edit the same file, the last completed write silently overwrites the other. - Assign distinct files or directories to each track. - For shared files, use temporary outputs and merge them afterward, or impose an explicit execution order. Use `/fleet` for well-partitioned work with clear ownership and dependencies. Careful prompt structure is essential: parallelism is most effective when agents can operate independently without competing for the same files.