VS Code has Agent mode, subagents, and the Agents window. Copilot CLI adds /fleet. These features can all look like forms of “multi-agent” work, but they operate at different layers.
One detail is easy to miss: Copilot CLI is an agent runtime, not just a terminal experience. You can also start, monitor, and manage Copilot CLI sessions from the Chat view and the Agents window in VS Code. That makes “VS Code or CLI?” a misleading either-or question.
This article reflects the product as of July 2026. Check the official documentation for the latest supported agents, models, and concurrency limits.
1. Start with three layers
These concepts become confusing when we mix three separate dimensions:
| Dimension | The question it answers | Examples |
|---|---|---|
| Interaction surface | Where do I view and control the agent? | VS Code Chat view, Agents window, CLI terminal |
| Agent runtime | Where and how does the agent run? | VS Code local agent, Copilot CLI, Copilot Cloud |
| Orchestration model | How is one goal distributed across multiple agents? | Subagent delegation, CLI /fleet, multiple independent sessions |
These dimensions can be combined. For example, you can:
- Use a local agent in the VS Code Chat view and let it invoke multiple subagents
- Start a background Copilot CLI session from the VS Code Chat view, then use
/fleetwithin that session - Run Copilot CLI directly in a terminal, then use
/fleet - Use the Agents window to manage Copilot CLI, Copilot Cloud, or Claude agent sessions across multiple workspaces
The useful questions are therefore not simply “VS Code or CLI?” Instead, ask:
- Which interface will I use to observe and control the agent?
- Which runtime will I use: a local agent, Copilot CLI, or something else?
- Which orchestration model fits the task: on-demand subagent delegation, explicit Fleet orchestration, or multiple independent top-level sessions?
A local agent and Copilot CLI can also hand work off to each other. You might first discuss requirements or build a plan with a local agent in VS Code, then hand the full conversation history and context to Copilot CLI so it can continue the implementation in the background.
2. What each concept actually means
2.1 VS Code local agents: interactive work in the editor
After you select Agent in the VS Code Chat view, a local agent can repeatedly work toward a goal:
Understand the request
↓
Read and search the code
↓
Edit files and run commands
↓
Check the result and make further corrections
↓
Return the final result
This workflow is commonly called Agent mode. It means that the agent can use tools to carry out a multi-step task autonomously; it does not mean that multiple agents are launched every time.
Local agents work well when:
- The requirements are still taking shape and you want to discuss them while implementing
- The task depends on files, selections, diagnostics, or test results from the current editor
- You want to inspect changes and adjust direction at any time
- You need tools provided by VS Code extensions or MCP servers
2.2 VS Code subagents: delegation on demand
When a local agent decides that a subtask would benefit from isolated work, it can invoke the built-in agent/runSubagent tool. Here, agent/runSubagent is a tool identifier, not a command that you type into the Chat input. Make sure the tool is enabled before using this capability.
User
↓
VS Code main agent
├── Subagent A: analyze security risks ──────┐
├── Subagent B: analyze performance issues ─┼── Return individual results
└── Subagent C: analyze testing gaps ───────┘
↓
Main agent synthesizes the findings
Each subagent has its own context and receives only the information it needs for its subtask. The main conversation usually receives only the result or summary, keeping extensive search steps and intermediate details out of its context. You can still expand the tool call to inspect the prompt sent to the subagent, the tools it used, and the result it returned.
Subagents are typically initiated by the main agent. You can suggest or request isolated, parallel delegation in your prompt, but this is not a mandatory invocation syntax. The main agent ultimately decides whether to use subagents and how many to start.
Use three independent subagents to analyze these areas in parallel:
1. Authentication-related security risks
2. Error-handling consistency
3. Gaps in unit test coverage
Wait for all three analyses to finish, then combine the findings into a prioritized report.
2.3 Copilot CLI /fleet: explicit parallel orchestration
/fleet is a slash command that you explicitly enter in Copilot CLI. It tells the main agent: analyze whether this task can be divided, then delegate suitable parts to multiple subagents to run in parallel.
/fleet Refactor each SDK package independently, run its tests, and summarize the changes
Invoking /fleet is explicit, but you do not have to perform the entire decomposition yourself, and the command does not guarantee that multiple subagents will be created. The main agent still analyzes the prompt and task dependencies, determines which parts can run in parallel, and schedules the subagents that are actually needed.
Fleet coordinates subtasks and their dependencies through the main agent. In Copilot CLI, /tasks shows background tasks in the current session, including tasks delegated to subagents by Fleet.
Overall goal
↓
Main agent analyzes tasks and dependencies
├── Refactor the auth package ── Subagent A
├── Refactor the API package ── Subagent B
└── Refactor the utils package ── Subagent C
↓
Use /tasks to inspect background tasks, open details, or stop a task
↓
Parent session synthesizes the results
2.4 The Agents window: a multi-session console
The Agents window is an agent-first interface in VS Code. It emphasizes something different from the traditional Chat view:
- Chat view is code-first: it centers your work on the currently open workspace and code
- Agents window is agent-first: it lets you create, inspect, and manage multiple agent sessions across workspaces
The Agents window currently supports Copilot CLI, Copilot Cloud, and Claude agent sessions; it is not a generic interface for every local or third-party agent. It solves the problem of observing multiple top-level sessions at once. It does not define a new subagent orchestration algorithm.
This also reveals two different kinds of parallelism:
- Multiple independent sessions: you start several top-level tasks, each with its own goal
- Subagents within one session: the main agent delegates several subtasks in pursuit of a single goal
Both can be described as “multi-agent,” but their management boundaries and result-synthesis models are different.
3. A one-table mental model
| Concept | What it actually is | The problem it mainly solves |
|---|---|---|
| VS Code local agent | An interactive agent runtime inside the editor | Discussing, implementing, and iterating close to the code |
| VS Code subagent | Context-isolated task delegation through an internal tool | Research, analysis, and reviews from multiple perspectives |
Copilot CLI /fleet |
Explicit orchestration of multiple subagents within the Copilot CLI runtime | Background parallel work with clear plans and independent boundaries |
| VS Code Agents window | A session-management interface spanning workspaces and supported agent types | Managing multiple top-level sessions at once |
These features are therefore not simple competitors. A local agent handles interactive work in the editor. A subagent lets the main agent delegate on demand. /fleet explicitly requests parallel orchestration. The Agents window provides one place to inspect and manage sessions.
The first step is not to decide which feature is more powerful. It is to identify whether you are choosing an interface, an agent runtime, or an orchestration model.
The next article will compare VS Code subagents and Copilot CLI /fleet across default models, custom agents, nesting, concurrency, and isolation, then provide a practical decision tree.
You can outsource your thinking, but you cannot outsource your understanding.
Official references
-
VS Code agents and interfaces
-
VS Code subagents
-
Copilot CLI
/fleet
Top comments (1)
I found the distinction between the interaction surface, agent runtime, and orchestration model to be particularly insightful, as it clarifies how these concepts can be combined in various ways, such as using a local agent in the VS Code Chat view and invoking multiple subagents. The example of handing work off between a local agent and Copilot CLI also highlights the flexibility of this architecture. One question that comes to mind is how the choice of orchestration model, such as subagent delegation or CLI
/fleet, impacts the scalability and complexity of the overall system - are there any general guidelines for selecting the most suitable model for a given task?