DEV Community: Bruce Wong

VS Code Multi-Agent Terminology Map: Local Agent, Subagent, /fleet, and the Agents Window

Bruce Wong — Sat, 18 Jul 2026 13:00:00 +0000

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 /fleet within 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
- Subagents in Visual Studio Code
- Agents concepts
Copilot CLI /fleet
- Running tasks in parallel with the /fleet command

Foundry IQ Explained: How Does It Relate to Azure AI Search and Traditional RAG?

Bruce Wong — Mon, 06 Jul 2026 08:25:05 +0000

When people first encounter Foundry IQ, many assume that it is simply a new name for Azure AI Search—or traditional RAG wrapped in a new user interface.

But once you start configuring it in a real project, a few questions quickly emerge:

What exactly is the relationship between Foundry IQ and Azure AI Search?
Why does retrieval need an LLM?
Is Foundry IQ genuinely different from traditional RAG, or is it simply new product packaging?

Rather than listing product features, this article focuses on these common points of confusion. The goal is to help you understand which problems Foundry IQ is designed to solve—and which ones it is not.

First, a Naming Clarification: Are the Two Foundry IQ Entry Points the Same?

They provide access to the same underlying Foundry IQ knowledge base capabilities, but through different management experiences.

Foundry IQ (Azure AI Search) in the Azure portal focuses on lower-level resource management, including Search services, indexes, indexers, knowledge sources, knowledge bases, and agentic retrieval.
Knowledge (Foundry IQ) within a Microsoft Foundry project focuses on the agent development experience, allowing developers to create, configure, and connect knowledge bases.

In both cases, the knowledge bases and knowledge sources are hosted in the selected Azure AI Search resource. If the Search endpoint—for example, https://my-search-service.search.windows.net—and the knowledge base name are the same, you are looking at the same underlying knowledge base.

Some product and pricing pages use the name Foundry IQ (Azure AI Search). However, this does not mean that every Azure AI Search technical term has been replaced. At the time of writing, official documentation still describes Azure AI Search as the underlying indexing and retrieval infrastructure for Foundry IQ. Terms such as Index, Indexer, Skillset, Vector Search, and Search API also remain part of the Azure AI Search product vocabulary.

Microsoft Foundry
  └─ Knowledge (Foundry IQ)
       └─ Project Connection
            └─ Azure AI Search Resource
            ├─ Knowledge Base / Knowledge Sources
            ├─ Index / Indexer / Vector Search
            └─ Agentic Retrieval

In one sentence: Azure AI Search performs the search, while Foundry IQ organizes search into a reusable knowledge service for agents.

They are not competing products. They are two layers with different responsibilities in the same capability stack.

Why Does a Knowledge Base Need an LLM?

The Chat Completions model shown in the screenshot is part of the knowledge base retrieval pipeline. It is not the embedding model, and it is not necessarily the agent's primary model.

According to the official documentation available at the time of writing, the LLMs supported for query planning are primarily Azure OpenAI deployments from the GPT-4o, GPT-4.1, and GPT-5 families. This support may change over time.

The model has three main responsibilities:

Query planning: It uses the user's question and conversation history to break a complex request into more focused subqueries.
Query and knowledge-source planning: It determines which sources to query and generates the subqueries. Azure AI Search then performs keyword, vector, or hybrid retrieval, followed by semantic reranking.
Optional answer synthesis: When Output Mode is set to Answer synthesis, the model combines the evidence into an answer with citations. With Extracted data, the retrieved content and its sources are passed to the agent, which generates the final response.

Retrieval reasoning effort controls how extensively the LLM participates in retrieval. It also determines the applicable resource limits:

Mode	Core behavior	Limits from the official FAQ	Recommendation
`Minimal`	Searches directly without LLM-based query planning	Up to 10 knowledge sources; no LLM and no answer synthesis	Lowest cost and latency; supports extracted results only and does not support web knowledge sources
`Low`	Performs one round of query planning and source selection; the default mode	Up to 3 sources and 3 subqueries; 5,000-token answer-synthesis budget	A good starting point for most scenarios
`Medium`	Can revise the query and retrieve once more if the first results are insufficient	Up to 5 sources and 5 subqueries; 10,000-token answer-synthesis budget	Better suited to complex, cross-source tasks where completeness matters

Higher reasoning effort generally improves retrieval coverage, but it also increases latency and token cost. Always check the latest official limits and FAQ for current values.

Remote knowledge sources such as the web require Answer synthesis to return results. As a result, Minimal mode—which does not support answer synthesis—cannot use web sources.

It is also important to distinguish between two model roles: the knowledge base LLM optimizes how evidence is found, while the agent LLM decides how to complete the task. They may use the same model deployment, but they do not have to.

For a Foundry agent that must call other tools and assemble a unified response, Microsoft recommends starting with Extracted data. This gives the agent the raw evidence and citations, allowing it to reason over them without having both the knowledge base and the agent generate an answer. Answer synthesis is more appropriate when retrieval results are presented directly to the end user and do not require further processing by an agent.

Put simply, the LLM here is not primarily responsible for answering the question. Its job is to ask the question correctly and find the right evidence.

Why Does a Blob Knowledge Source Also Require Models?

The short answer is this: models configured on the Blob page transform raw documents into more searchable content during ingestion, while the model configured on the Knowledge Base page interprets questions and orchestrates retrieval at query time.

Both pages include a Chat Completions model, but the models operate at different stages of the RAG pipeline:

Model	When it runs	What it does
Blob Chat Model	During document ingestion, indexing, or refresh	Performs generative content extraction, particularly by describing visual content such as images and charts as searchable text
Blob Embedding Model	During indexing and vector queries	Converts document chunks and user queries into vectors for semantic similarity search
Knowledge Base Chat Model	During each user retrieval request	Interprets the question, creates subqueries, selects knowledge sources, and optionally synthesizes the answer

When you create a Blob knowledge source, the system automatically generates a data source, indexer, skillset, and search index. The component names matter less than the processing logic behind them: documents are parsed and chunked, enriched with searchable text, and then converted into vectors for retrieval.

In the screenshot, Content extraction mode = Standard invokes Azure Content Understanding for more advanced document parsing and chunking. If image descriptions are enabled, the Blob Chat Model converts visual information from images and charts into text. The Embedding Model then converts both content chunks and queries into vectors for subsequent vector retrieval.

How Is This Different from Connecting an Agent Directly to Azure AI Search?

In a traditional RAG architecture, an agent typically connects directly to a search index. You configure the query type, top_k, and filters; Search returns document passages; and the agent's primary model produces the answer. This shorter, more directly controlled pipeline works well for a single index and predictable query patterns.

A Foundry IQ knowledge base is not limited to Foundry Agent Service. Any application, Microsoft Agent Framework implementation, or custom service that supports the Azure AI Search Knowledge Base API can call it. Foundry Agent Service simply provides native integration and a managed experience.

Foundry IQ does not replace RAG. Instead, it moves increasingly complex retrieval orchestration out of individual agents:

Direct use of Azure AI Search	Foundry IQ Knowledge Base
Typically targets one index	Can organize multiple index-based or remote knowledge sources
Usually runs one preconfigured search	Can decompose questions, select sources, run parallel queries, and iterate on retrieval
The agent processes documents and generates the answer	The knowledge base reranks and merges results while preserving citations
Retrieval configuration is distributed across agents	A domain knowledge base can be shared by multiple agents and updated independently
Cost and latency are easier to predict	Complex questions may produce better results, with additional model calls and latency

The central benefit is separation of concerns: Azure AI Search executes retrieval; the knowledge base owns domain knowledge and retrieval strategy; and the agent handles conversation, tool use, and business actions.

In Microsoft's published benchmark, agentic retrieval improved response quality by approximately 36% over traditional single-query RAG under the company's test conditions. This figure is best treated as a directional data point, not as a universal result that every workload will reproduce.

What Foundry IQ changes, therefore, is not merely the user interface. It changes who owns the retrieval strategy within a RAG system.

How Should You Choose?

If you have one mature index, straightforward questions, and strict requirements for control and low latency, continue connecting directly to an Azure AI Search index or tool.
If you need to answer complex questions across multiple sources, understand conversational context, or share the same domain knowledge among multiple agents, consider Foundry IQ.

The simplest way to think about it is:

Foundry IQ is not another search engine. It is an agent-oriented knowledge and context-engineering layer built on Azure AI Search.

You can outsource your thinking, but you cannot outsource your understanding.

References

Microsoft Learn: What is Foundry IQ?
Microsoft Learn: Create a knowledge base in Azure AI Search
Microsoft Learn: Agentic retrieval in Azure AI Search
Microsoft Learn: Connect a Foundry IQ knowledge base to Foundry Agent Service
Microsoft Learn: Set the retrieval reasoning effort
Microsoft Learn: Connect an Azure AI Search index to Foundry agents
Microsoft Learn: Agentic retrieval limits
Microsoft Tech Community: Foundry IQ: Boost response relevance by 36% with agentic retrieval
Microsoft Learn: Foundry IQ FAQ

🚀 How Foundry IQ helps enterprises build reusable knowledge bases for AI agents

Bruce Wong — Sun, 21 Jun 2026 12:20:31 +0000

Enterprise knowledge is often scattered across document stores, business systems, SharePoint, OneLake, and the public web. The real challenge isn’t simply putting documents into a vector database—it’s helping agents select the right sources, plan retrieval, and return traceable answers.

✅ Connect internal and external knowledge sources
✅ Automate content extraction, chunking, and vectorization
✅ Combine static documents with live web information
✅ Use an LLM to plan queries and select sources
✅ Run parallel retrieval, semantic reranking, and result aggregation
✅ Share one knowledge base across multiple agents
✅ Return grounded results with citations

Enterprise Context Engineering Through Microsoft IQ: A Four-Layer Analysis

Bruce Wong — Sun, 14 Jun 2026 13:34:15 +0000

Recently, while developing Agents with Microsoft Foundry, I noticed a confusing area: Microsoft has a series of "IQ" concepts — Work IQ, Fabric IQ, Foundry IQ, and Web IQ. They all seem to "provide context for Agents," but the context they supplement is actually different.

This points to a core problem in enterprise Agent engineering: context engineering. If prompt engineering is about "how to ask the model," then context engineering is about "what context to give the model." Microsoft IQ can be seen as Microsoft's enterprise-level implementation in this direction: packaging the scattered context inside and outside the organization into four consumable intelligence layers for Agents.

Here's the summary: Microsoft IQ consists of four capabilities:

Work IQ: Understanding how employees work.
Fabric IQ: Understanding business data and business entities.
Foundry IQ: Understanding enterprise knowledge, policies, and authoritative documents.
Web IQ: Understanding fresh information from the external world.

What Problem Does Each Layer Solve?

Enterprise Agent context typically comes from four sources, and each Microsoft IQ layer corresponds to one:

Context Source	Corresponding IQ	Core Question	Typical Representation
Human activities and relationships	Work IQ	Who, when, with whom, did what	Microsoft Graph, collaboration signals
Business facts and metrics	Fabric IQ	What is the current state of the business	Semantic model, ontology, Graph
Enterprise knowledge and rules	Foundry IQ	What do authoritative sources in the organization say	Knowledge base, agentic retrieval
External real-time information	Web IQ	What is happening in the external world	Web search, fresh content

Work IQ: Understanding "How People Work"

Work IQ is the workplace intelligence layer on the Microsoft 365 side. It understands work context, relationships, and patterns, enabling Agents to answer questions faster and more accurately than simple connectors.

From a context engineering perspective, Work IQ's core is activity signals centered on "people / relationships / time." It answers not "what is written in the document," but "who, when, with whom, did what."

For example: What recent email exchanges have there been with a customer? Which documents should I review before tomorrow's meeting? What has the team discussed around a particular project in Teams?

Work IQ leverages Microsoft 365 tenant data, including SharePoint, OneDrive, Outlook, Teams, and collaboration signals in Microsoft Graph, while respecting Microsoft 365 permissions and organizational boundaries. It is particularly suitable for employee productivity Agents: meeting preparation, email summarization, project context梳理, etc.

Fabric IQ: Understanding "What Is the Current State of the Business"

Fabric IQ is the IQ workload within Microsoft Fabric. Official documentation states: "Fabric IQ provides context on the state of your business." It is not simply about letting Agents query tables, but about elevating data to the business language layer, enabling both humans and Agents to understand data around business concepts, goals, and rules.

From a context engineering perspective, Fabric IQ solves the problem of "how business data is correctly understood by Agents." Enterprise data originally resides in tables, fields, and schemas, but business cares about: Who is the Customer, what is the relationship between Shipment and Order, how is a certain KPI calculated, and what actions should be triggered when anomalies occur.

Fabric IQ organizes these business concepts, relationships, rules, and actions through OneLake, Power BI semantic models, ontology, Graph, data agent, and operations agent. It is suitable for analytical and operational Agents: business analysis, supply chain anomaly detection, metric interpretation, and real-time operational response.

Foundry IQ: Understanding "Where Enterprise Knowledge Lives"

Foundry IQ leans more toward the managed knowledge layer for Agents. Agents need context from scattered enterprise content, but models have knowledge cutoffs and cannot access enterprise private data on their own. Foundry IQ can create configurable, multi-source knowledge bases, enabling Agents to provide permission-aware responses based on organizational data.

From a context engineering perspective, this is close to RAG, but not a hand-written simple vector library. Foundry IQ's knowledge base can connect to sources such as Azure Blob Storage, SharePoint, OneLake, and public web data, and use agentic retrieval (query rewriting, multi-round retrieval, source ranking, citation generation, etc.) to return grounded answers with citations.

It solves the problem of "how Agents reliably access enterprise knowledge:" Where are company policies? How is product documentation explained? What related content is in historical solutions? Can the answer provide citations?

It is suitable for knowledge Q&A, policy assistants, product documentation assistants, and pre-sales solution assistants.

Easy to Confuse: Both Foundry IQ and Fabric IQ Mention OneLake — What's the Difference?

Fabric IQ handles data in OneLake that has already been modeled as business semantics (tables, metrics, Graph, semantic models). It enables Agents to understand "business facts."
Foundry IQ handles unstructured content in OneLake such as documents, templates, and solutions that serve as enterprise knowledge sources. It enables Agents to understand "enterprise language / rules."

One is the "business data layer," the other is the "enterprise knowledge layer."

Web IQ: Understanding "What Is Happening in the External World"

Web IQ is the fourth capability. Official Microsoft IQ documentation states that "Web IQ provides AI systems and agents with fresh, real-world intelligence from across the web."

From a context engineering perspective, it solves the problem of "externally changing information:" What is the latest industry news? What have competitors released? What is the impact of new policies, regulations, or vulnerabilities?

If the first three are more about finding context within the organization, Web IQ supplements changes from outside the organization.

Easy to Confuse: Foundry IQ Can Also Connect to Public Web Data — Isn't That Redundant with Web IQ?

No, it's not redundant.

Web data in Foundry IQ is externally curated by the enterprise, such as competitor whitepapers, regulatory pages, and industry reports that have been crawled into the knowledge base. It has already been incorporated into the enterprise knowledge boundary.
Web IQ is real-time, open, general web intelligence that does not require pre-indexing, supplementing "what is happening in the external world right now."

One is "external materials managed by the enterprise," the other is "the real-time external world."

The Differences Among the Four

IQ	Focus	Typical Question	Typical Data	Agent Function
Work IQ	How employees work	Where did I leave off with the client yesterday?	Emails, meetings, Teams, files, personnel relationships	Understand work context
Fabric IQ	Current state of business	What is this customer's renewal risk?	OneLake, semantic models, Ontology, Graph, real-time/analytical data	Understand business concepts and metrics
Foundry IQ	Where enterprise knowledge lives	What does our service agreement say about this type of issue?	Documents, knowledge bases, SharePoint, Blob, OneLake, enterprise-curated web materials	Obtain citable authoritative knowledge
Web IQ	What is happening in the external world	Has the customer been affected by recent industry negative news?	Web information, news, public pages, real-time external materials	Obtain fresh external context

A Context Engineering Example

Suppose we are building a customer meeting preparation Agent:

Help me prepare for tomorrow's meeting with Contoso.

This is not a simple prompt, but an orchestration of multi-layer context:

Use Work IQ to pull recent emails, meetings, and Teams discussions related to Contoso, establishing "people" and "timeline" context.
Use Fabric IQ to query Contoso's business status, such as ARR, orders, risks, renewals, and service ticket trends.
Use Foundry IQ to query product documentation, customer solutions, contract policies, and delivery templates.
If needed, use Web IQ to supplement recent public news, industry trends, or competitive information about Contoso.
Finally, the Agent compiles a briefing, risk points, and suggested questions.

The key is not "which IQ is stronger," but that they supplement different contexts. For example, if you only connect Foundry IQ to query documents without knowing that the customer recently expressed strong dissatisfaction in Teams, the Agent's response is likely to be "correct but contextually detached."

Summary

The real difficulty with Agents is not just whether the model can reason, but whether it has the right context. Microsoft breaks this context into different layers:

Work IQ enables Agents to understand work like a colleague.
Fabric IQ enables Agents to understand data like a business expert.
Foundry IQ enables Agents to find authoritative materials like a knowledge manager.
Web IQ enables Agents to monitor external changes like a researcher.

From a context engineering perspective, the core value of Microsoft IQ lies in: packaging the scattered, heterogeneous, and permission-complex context within the enterprise into standardized capabilities that Agents can directly consume. You don't need to write Graph connectors, build semantic layers, maintain vector libraries, or integrate web searches yourself — you simply choose the appropriate IQ layer for the scenario.

If an enterprise Agent only connects to the model, it easily becomes an assistant that "speaks well but doesn't understand the organization." When it can simultaneously understand work, business, knowledge, and external changes, it comes closer to a truly deployable enterprise Agent.

Microsoft Build 2026: Agent Harness Is About Making Agents Production-Ready

Bruce Wong — Thu, 11 Jun 2026 08:28:19 +0000

Microsoft Build 2026 had many AI announcements, but the one I found most meaningful was not another model or another Copilot UI.

It was Agent Harness in Microsoft Agent Framework.

My reading is simple: Microsoft is trying to move agent development from "the agent can run" to "the agent can survive production."

That difference matters.

Most agent demos look impressive because the happy path is short. A user asks, the model reasons, a tool is called, and the result comes back. But real agent workloads are messier:

the task runs for many steps
context becomes too large
the agent needs memory
some tools require approval
developers need traces
multiple agents may need to collaborate
generated code may need to execute safely

These are not side features. They are the execution layer of an agent system.

Agent Harness is interesting because it makes that execution layer part of the framework default.

What Changed

At a high level, creating a harness agent looks like this:

agent = create_harness_agent(
    client=client,
    name="MyAgent",
    max_context_window_tokens=128_000,
)

The API change is small. The assumption change is not.

The old assumption was: create an agent and let it call tools.

The new assumption is: this agent may run for a long time, use many tools, need human approval, overflow context, delegate work, and require observability.

Agent Harness includes built-in providers for things like:

automatic context compaction
file-based memory
todo tracking
plan vs. execute modes
dynamic skill discovery
background agents
tool approval rules
OpenTelemetry tracing
web search and shell execution

This is why I do not see Agent Harness as just a feature list. I see it as a standardization move.

Every serious agent platform eventually needs these capabilities. The question is whether each team builds them manually, or whether the framework provides strong defaults.

CodeAct: The Real Problem Is Not Tool Speed

The first feature worth paying attention to is CodeAct with Hyperlight.

Traditional tool calling usually works like this:

LLM -> choose tool
Tool -> return result
LLM -> choose next tool
Tool -> return result
LLM -> choose next tool
...

This is fine for simple tasks. But it becomes expensive when the work is procedural.

Imagine an agent needs to calculate total order value across users:

list users
get orders for each user
get discount for each order
get tax rate by region
calculate the final total

In traditional tool calling, the model may need many turns just to walk through a loop.

CodeAct changes this by letting the model generate code once:

users = call_tool("list_users")
total = 0

for user in users:
    orders = call_tool("get_orders", user_id=user.id)
    for order in orders:
        discount = call_tool("get_discount", order_id=order.id)
        tax = call_tool("get_tax_rate", region=order.region)
        total += (order.amount - discount) * (1 + tax)

print(total)

The important improvement is not that the tools execute faster.

The improvement is that the system reduces model-to-tool round trips.

Microsoft's example showed more than 50% latency reduction and more than 60% token reduction for a multi-step workflow. The exact number will vary, but the pattern is very useful: when the task is procedural, let the model express the procedure as code and let the runtime execute it.

This is closer to how developers work. If I need to repeat an operation across many records, I do not want to manually reason through every iteration. I write a small script.

CodeAct gives agents that same execution pattern.

Hyperlight Does Not Remove Tool Governance

CodeAct uses Hyperlight to run generated code in an isolated micro-VM. That is important because model-generated code should not run directly in the host environment.

But I think the security boundary needs to be stated clearly:

CodeAct sandboxing protects the host from unsafe generated code. It does not automatically make your tools safe.

If your tool can send an email, delete a file, update a database, approve a refund, or trigger a deployment, the sandbox is not enough. You still need tool-level permissions, approval policies, and auditability.

In other words:

Sandbox protects code execution.
Approval protects business actions.

Confusing these two would be dangerous in production.

Handoff: Multi-Agent Workflow Should Not Always Be a Pipeline

The second feature I found important is Handoff.

Many multi-agent examples are built as a fixed pipeline:

Planner -> Implementer -> Reviewer

That works for some development workflows. But many real service workflows are not linear.

Think about customer support:

Coordinator
  -> Refund Agent
  -> Shipping Agent
  -> Technical Support Agent
  -> back to Coordinator if needed

The right next step depends on the conversation.

This is where Handoff is useful. Developers define the participants and topology, while agents can decide when to transfer control.

A simplified structure looks like this:

workflow = (
    HandoffBuilder(name="customer_support")
    .participants([coordinator, refund, shipping, tech])
    .set_coordinator(coordinator)
    .with_interaction_mode("autonomous")
    .with_termination_condition(should_terminate)
    .build()
)

The point is not simply "multiple agents."

The point is runtime routing.

A coordinator can route to a specialist. A specialist can finish the task, ask for more information, or hand control back. The workflow can end early when the condition is met.

That is very different from forcing every request through the same fixed sequence.

My Takeaway

For me, the most important message from Agent Harness is this:

Production agents need an execution layer, not just a reasoning model.

That execution layer includes context management, memory, approvals, tracing, code execution, and multi-agent routing.

CodeAct improves single-agent efficiency by reducing unnecessary model turns.

Handoff improves multi-agent collaboration by allowing dynamic runtime routing.

Agent Harness brings these ideas into the Microsoft Agent Framework as default infrastructure.

This is why I think Agent Harness matters. It is not the most visually exciting Build 2026 announcement, but it may be one of the most practical ones for developers building real agent systems.

The next phase of agent development will not be defined only by smarter models. It will also be defined by better execution infrastructure.

GitHub Copilot CLI: Your AI Coding Partner in the Terminal

Bruce Wong — Thu, 11 Jun 2026 08:22:45 +0000

1. What is Copilot CLI?

In February 2026, GitHub officially released Copilot CLI to General Availability (GA). It is not a command-line port of the VS Code plugin, but a standalone, terminal-native AI coding agent.

GitHub's positioning is clear:

"Copilot CLI has grown from a terminal assistant into a full agentic development environment—one that plans, builds, reviews, and remembers across sessions, all without leaving the terminal."

All Copilot subscribers can use it (Free/Pro/Business/Enterprise) at no extra cost.

2. How is it different from VS Code Copilot?

This is the most confusing part. Many people think CLI is just "Copilot from VS Code moved to the terminal." It is not.

2.1 Positioning differences

Dimension	VS Code Copilot	Copilot CLI
Runtime	Inside the IDE	Terminal / command line
Interaction	Inline editor completions, side Chat	Full-screen terminal chat
Core strength	Real-time coding assistance	Complex task planning & execution
Context switching	Within the IDE	No need to leave the terminal

2.2 Feature comparison

Feature	VS Code Copilot	Copilot CLI
Code completion	✅ Real-time inline	❌ Not the main focus
Agent mode	✅ Yes	✅ Yes, and more powerful
Multi-step complex tasks	✅ Supported	✅ Better suited
Git operations	⚠️ Limited	✅ Native integration
GitHub.com operations (PR/Issue)	⚠️ Requires browser switch	✅ Direct operations
Plan Mode (plan first, then execute)	✅ Yes	✅ Shift+Tab, more complete
Cross-session memory	✅ Yes	✅ Stronger Repository Memory
CI/CD integration	❌ Difficult	✅ -p programmatic calls
Shell command execution	⚠️ Indirect	✅ Native support

2.3 One-sentence summary

VS Code Copilot is "your co-pilot while coding" — real-time completions, quick explanations, single-file refactoring.

Copilot CLI is "a full-stack engineer that works independently" — you can say "refactor this entire module," go do something else, and it reports back when done.

3. When to use CLI vs VS Code?

Scenarios for VS Code Copilot

Daily coding with real-time completions
Quick refactoring within a single file
Explaining selected code functionality
Reviewing and confirming changes directly in the editor

Scenarios for Copilot CLI

Complex multi-step tasks: creating complete features, cross-file changes
DevOps / automation: generating CI/CD configs, Terraform scripts
GitHub operations: bulk PR management, code reviews, issue creation
Background tasks: long-running code analysis, security scans
Pure terminal environments: SSH remote servers, Docker containers, WSL
Scripted integration: embedding AI capabilities into automation workflows

4. Copilot CLI's three killer features

4.1 Cloud Delegation (&)

The most unique feature. Prefix your prompt with & to push the task to the GitHub Cloud Agent:

Runs remotely on GitHub Actions runners
Automatically creates a copilot/ branch and Draft PR
Continues even if you shut down your local machine
Perfect for long-running tasks (code analysis, large-scale refactoring)

In contrast, Autopilot Mode (--autopilot) runs locally, is visible in real time, but stops if your local machine shuts down.

4.2 Programmatic Mode (-p)

Ideal for integration into scripts and automation workflows.

# Single-shot call, great for script integration
copilot -p "Show me this week's commits and summarize them" --allow-tool='shell(git)'

# Pipe input
./script-outputting-options.sh | copilot

Value: Can be integrated into CI/CD, cron jobs, and shell scripts.

4.3 Plan Mode — plan first, then execute

Press Shift+Tab to enter Plan Mode. Copilot will:

Analyze your request
Ask clarifying questions
Build a structured implementation plan
Wait for your confirmation before coding

Value: Avoids the "AI blindly changes code" problem by communicating requirements first.

5. Installation and quick start

5.1 Installation

这是提取出来的 Markdown 表格内容：

Platform	Command
macOS	brew install copilot-cli
Linux	brew install copilot-cli or curl -fsSL https://gh.io/copilot-install \| bash
Windows	winget install GitHub.Copilot
npm	npm install -g @github/copilot

需要我帮你保存成 .md 文件吗？如果要的话，文件名和路径有偏好吗？
Article content

5.2 Authentication

copilot
/login 
## 5.3 Quick start

# 1. Enter your project directory
cd my-project

# 2. Start interactive mode
copilot

# 3. Initialize custom instructions (helps Copilot understand your stack)
/init
# Generates .github/copilot-instructions.md with project context

# 4. Start building
"Create a React component for user authentication"

# 5. Run in the background (non-blocking terminal)
& "Analyze all security vulnerabilities in this codebase"

Reference resources

Official docs:https://docs.github.com/copilot/how-tos/copilot-cli/cli-getting-started

Best practices:https://docs.github.com/copilot/how-tos/copilot-cli/cli-best-practices

Command reference:https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

Slash command cheat sheet:https://github.blog/ai-and-ml/github-copilot/a-cheat-sheet-to-slash-commands-in-github-copilot-cli/

Product page:https://github.com/features/copilot/cli