The thing about AI agents that nobody tells you is this: the hardest part isn’t getting them to do things. It’s getting them to know when to stop.
I’ve been watching the agentic AI space evolve for a while now, and there’s a pattern that keeps repeating itself. We build these increasingly powerful systems that can break down complex tasks, spin up helpers, delegate work, and coordinate parallel execution. Then we pat ourselves on the back about how clever the architecture is. Meanwhile, users are sitting there waiting for a simple file edit while three different agents politely hand the task back and forth like it’s a hot potato.
GitHub just shipped something interesting that tackles exactly this problem. Their Copilot CLI team reduced tool failures per session by 23% and cut user wait time at the slower end of sessions by 5% at P95. That’s not a flashy new feature. That’s orchestration tuning. And honestly, it’s the kind of work that matters more than adding another button or model option.
The Delegation Trap
Here’s what happens in these agentic systems. You ask Copilot CLI to make a straightforward change. Maybe it’s修改 a single function, update a config value, something that should take one hop. But the main agent decides this is a good case for delegation. It spins up a subagent to “explore” the repository, the subagent searches around, finds what it needs, reports back, and then the main agent finally does what you asked.
That should have been one step. It became three. The agent got more “helpful” by being more agentic, and somehow the user experience got worse.
The overhead shows up in multiple ways. Each handoff means coordination latency, extra tool calls, and context passing between agents. Sometimes the subagent ends up re-doing work the main agent already did because the handoff context wasn’t clear. And if something fails in this chain, you’ve got multiple failure points instead of one.
This is the inverse of what we want. We’re adding agents to parallelize work and speed things up, but when delegation happens too eagerly, it becomes serialization with extra steps.
What Changed
The fix wasn’t adding more intelligence to individual agents. It was adding more judgment to the orchestration layer.
The team analyzed actual user sessions using LLMs to identify where delegation was helping versus where it was adding friction. What they found was that subagents were being invoked for tasks that were already narrow, obvious, or fully described in the handoff. The main agent already had enough context to act directly, but it delegated anyway.
The new approach is more selective. Simple discovery-and-edit tasks stay in the main agent. Subagents get used when the work genuinely requires independent context, broad exploration, or parallel execution. It’s a subtle shift, but it changes the agent from “let’s throw resources at this” to “what’s the narrowest effective path?”
And here’s the part I find most interesting: when subagents are used, the main agent is now encouraged to keep working on independent tasks rather than just waiting for the result. That’s parallelism in the true sense, not just parallelizing the waiting.
Why This Matters for the Industry
The broader implication here is significant for anyone building agentic systems.
We’ve spent the last couple of years obsessing over model capabilities, context windows, tool definitions, and agent architectures. All of that matters. But the GitHub Copilot CLI work shows that the coordination layer might be where the biggest quality improvements hide.
Think about it this way. You can have the smartest individual agents in the world, but if your orchestration is firing them off like confetti at every prompt, you’re just creating expensive overhead. The value of having multiple agents isn’t in using all of them all the time. It’s in having them available when they create leverage.
This is actually a familiar pattern from traditional software engineering. We learned years ago that microservices aren’t automatically better than monoliths. The overhead of coordination, network calls, and service boundaries can outweigh the benefits if you’re not careful. The same logic applies to agentic systems, but with the added complication that the agents themselves are non-deterministic and the coordination happens through natural language.
The difference between a well-orchestrated agentic system and a chaotic one isn’t who has the most agents. It’s who has the best judgment about when to use them.
What This Means for Developers
If you’re using Copilot CLI day to day, you should notice the experience feeling smoother. Straightforward tasks that would have triggered unnecessary subagent invocations now get handled directly. Complex tasks still get specialist help when it adds value. Long-running sessions keep moving with less waiting.
The interesting thing is that none of this requires you to change your workflow. The system is making better decisions behind the scenes. That’s actually harder to build than adding a new feature toggle or configuration option, but it’s much better for the user experience.
It also points toward where this is all heading. As artificial intelligence agents become more prevalent, the quality of orchestration will matter more than the raw capability of individual agents. The best system won’t be the one that delegates the most or uses the biggest model for everything. It’ll be the one that knows when to act directly, when to bring in help, and how to keep work moving without adding friction.
That’s a harder engineering problem than it sounds, and it’s exactly the kind of unglamorous but crucial work that determines whether these tools actually feel magical or just feel like more stuff to manage.