When delegation slows things down
Agentic systems that delegate too eagerly can end up making simple work slower. A task Copilot CLI could finish directly might instead trigger a helper agent to search the repository, wait on results, and stall — turning a one-step operation into a three-step detour. Delegation has real value when a subagent brings independent context, explores unfamiliar code, or runs a long command while the main agent keeps working. But each handoff adds coordination overhead, extra tool calls, and waiting time. When an agent delegates indiscriminately, the assistance becomes friction.
GitHub recently shipped an update to Copilot CLI that makes delegation more selective. The change, now live on 100% of production traffic, helps the main agent decide when to act alone, when to delegate, and when to parallelize independent work. Developers can get the update by running the /update command in their terminal to reach version 1.0.42 or later.
Costs of over-delegation
Subagents are a core enabler for agentic workflows. They let Copilot decompose complex jobs, investigate multiple areas concurrently, and keep the main agent free to coordinate the final response. For large codebases and multi-step engineering tasks, that can make the difference between a slow linear process and efficient parallel execution.
However, delegation introduces distinct failure modes:
- Unnecessary handoffs when the main agent could complete a simple task faster directly.
- Overuse of exploration subagents when the handoff already supplies sufficient context.
- Repeated or overlapping searches performed by both the main agent and subagents.
- Sequential delegation, where the main agent idles waiting for a subagent instead of continuing with independent work.
- Failure-prone subagent paths stemming from stale file paths, moved files, incorrect relative paths, and workspace mismatches.
The objective was to route work to subagents only when they create real leverage, keep focused tasks with the main agent, and exploit parallelism where tasks are genuinely independent.
Finding the bottleneck with LLM analysis
The path from problem to fix relied on a single feedback loop rather than separate phases of analysis, product change, and validation. The team first used LLMs to analyze complete agent trajectories and identify where orchestration added value versus where it merely created overhead. That analysis revealed a recurring pattern: subagents were being dispatched for tasks that were narrow, well-defined, or fully described in the handoff.
When that happened, the subagent could spend excess time re-searching the repository even though the main agent already had enough context to act. The improvement target became clear: keep simple discovery-and-edit work in the main agent, and reserve subagents for work that is broader, cross-cutting, or naturally parallelizable.
Refining the orchestration policy
With the diagnosis in hand, LLMs helped translate the finding into a more selective orchestration policy. Copilot CLI's main agent should handle focused work directly: find a file, read it, make a targeted change, and verify it. Delegation makes more sense when the task demands independent context, broad exploration, or parallel execution.
In practice, the policy means starting with the narrowest effective approach, escalating when complexity or uncertainty pays for it, and stepping back when the work narrows again. Subagents should function as a parallelism tool, not a pause button. When Copilot does launch a subagent, the main agent should keep progressing on independent work instead of simply waiting. Handoffs to subagents should also be explicit about what the user asked for, what is already known, what the subagent owns, and what kind of result the main agent expects to receive.
Offline validation and production rollout
Before wide release, the change was validated with automatically generated regression cases and existing benchmarks. That verification confirmed the revised guidance reduced avoidable overhead without breaking scenarios where subagents genuinely help.
After staff and public A/B testing, the production analysis covered reliability, responsiveness, subagent workload, and output quality. The gains did not come primarily from faster individual LLM calls — they came from reduced orchestration overhead via fewer unneeded subagent paths and lower subagent workload per user.
Measured outcomes
The production A/B test showed measurable improvements across reliability and responsiveness.
| Dimension | Metric | Delta |
|---|---|---|
| Reliability | Tool failures per session | 23% reduction |
| Reliability | Search tool failures | 27% reduction |
| Reliability | Edit tool failures | 18% reduction |
| Responsiveness | Total user wait time at P95 | 5% lower |
| Responsiveness | Total user wait time at P75 | 3% lower |
| Quality | Quality metrics | No regression |
| Metric | Delta vs. control | Interpretation |
|---|---|---|
| Failed raw subagent search calls | 15% reduction | Reliability – fewer failure-prone subagent search paths. |
| Average subagent LLM duration per user | 12% lower | Responsiveness – reduced orchestration overhead per user. |
| P95 subagent LLM duration per user | 18% lower | Responsiveness – better worst-case subagent overhead. |
Sessions saw a 23% reduction in tool failures, including a 27% drop in search tool failures and an 18% drop in edit tool failures. Total user wait time improved by 5% at P95 and 3% at P75, with no quality regression. P95 represents wait time near the slowest 5% of sessions; P75 sits near the slower end of typical sessions. The aggregate result is fewer unnecessary handoffs, fewer repeated searches, fewer failure-prone tool paths, and less time waiting during long coding tasks.
These results illustrate that orchestration quality itself can materially shape developer experience, even when the visible feature surface remains unchanged. The improvement comes from Copilot getting better at allocating models, tools, and subagents behind the scenes rather than adding controls for developers to manage.
What developers should expect
For day-to-day use, Copilot CLI should feel smoother. Straightforward work is more likely to be handled directly, complex work can still summon specialist help when warranted, and lengthy sessions should make steady progress with less idle waiting. The change is deliberately behind the scenes — the workflow a developer follows stays the same, but Copilot CLI coordinates the underlying work better.
Continuing toward adaptive orchestration
This release is one step toward a larger approach: making Copilot CLI choose the right model, agent, and tools for every task. More available agents and models expand what Copilot can attempt, but the actual benefit to developers rests in how those resources are applied to the work at hand — reading files, running commands, and moving from issue to pull request. As tasks grow more complex, orchestration quality matters even more. The best system is not the one that delegates the most, but the one that knows when to act directly, when to delegate, and how to keep work moving without added friction.
The next phase is making Copilot CLI adaptive across models, agents, skills, and tools, so developers don't need to decide whether a task requires a larger model, a specialist subagent, or a procedural skill. Copilot would make that call based on the task, repository context, policy, expected outcome, and internal measurements that track planning quality, subagent coordination, and results.
Developers can update by running /update in a terminal session to get version 1.0.42 or later. Feedback can be shared within a CLI session via the /feedback command or by opening an issue in GitHub's public copilot-cli repository.
