Original source: Your Home for Multi-Agent Development
Agent Sprawl Is Now a Workflow Problem
The interesting question is no longer which coding agent wins. Developers can use several agents with different strengths, and the hard part becomes coordinating them without losing context or accountability.
VS Code’s multi-agent direction is an answer to that operational problem. The editor brings local, background, cloud, and third-party sessions into a common experience. For .NET teams moving from occasional chat prompts to repeatable engineering workflows, that shared view is more important than another model selector.
A local agent is useful when the developer wants to steer every step. A background agent is useful for an isolated task that can run while the developer continues. A cloud agent is useful when the work needs remote infrastructure, pull-request integration, or team visibility. The same repository can need all three in one day.
Pick the Agent for the Task
A useful way to adopt this model is to stop asking which agent should own the project and instead ask what kind of work is being done.
For architecture and API design, a second model can challenge assumptions and expose tradeoffs before code is written. For repository-specific refactoring, the agent with the strongest workspace context may be the better fit because it can follow existing .NET abstractions and conventions. For a long-running change, a background or cloud session can produce a pull request while the developer handles a separate issue.
The point is not to treat model differences as a leaderboard. It is to make them part of task design. A plan should say what the agent needs to know, what it may change, and how the result will be checked.
Subagents Add Structure, Not Magic
Specialized subagents make the pattern more powerful. A parent agent can delegate a security review, a documentation scan, and an implementation investigation to focused workers, then integrate their findings.
For a .NET service, those boundaries might look like this:
- a read-only agent maps authentication and authorization paths;
- a test-focused agent identifies missing coverage around the proposed change;
- an implementation agent drafts code inside an isolated worktree;
- a reviewer checks the resulting diff against the original acceptance criteria.
This structure reduces the temptation to ask one general agent to do everything. It also gives humans clearer checkpoints. The security agent should not silently modify production configuration, and the implementation agent should not decide that an unresolved authorization question is harmless.
Agent Skills extend the same idea by packaging reusable instructions and capabilities. For .NET, the opportunity is obvious: skills for API versioning, Entity Framework migrations, ASP.NET performance, or test design could make a general agent more consistent without pretending that a prompt replaces engineering experience.
The Cost of Coordination
Multi-agent workflows have a failure mode that single-agent workflows hide: conflicting context. One agent may assume a service uses managed identity while another assumes a connection string. One may optimize for a fast patch while another recommends an architectural migration.
Use explicit handoffs. Require each agent to state assumptions, evidence, files inspected, and unresolved questions. Keep the parent session responsible for choosing between competing recommendations. For sensitive changes, make the final decision a human-reviewed pull request rather than an automatic merge.
Quota and cost also become more visible. Parallel work consumes requests faster, and cloud agents may have separate availability or subscription requirements. Measure the time saved rather than assuming that more agents means more throughput.
A Practical Adoption Path
Start with two roles: a local agent for interactive work and a background or cloud agent for an isolated, well-scoped task. Compare the results on a small refactoring or test-improvement issue. Add a specialized subagent only after the handoff between those two roles is clear.
For the first month, track which tasks are delegated successfully, how often a reviewer has to redirect the work, and whether the generated tests catch regressions. That data is more useful than a general impression that one model feels smarter.
VS Code is becoming a home for multi-agent development because it gives these sessions a common operating surface. The engineering discipline still comes from the team: clear tasks, narrow permissions, visible assumptions, and tests that remain independent of whichever agent produced the code.
