In-Depth

Hands On with New Multi-Agent Orchestration in VS Code

• By David Ramel
• 02/09/2026

As agentic AI continues its transformation of software development, the new release of Visual Studio Code 1.109 was described by Microsoft as "the home for multi-agent development."

As usual, the announcement post was dominated by new AI functionality. Foremost of these were multiple agents and orchestration.

I had earlier tried out new experimental features including workspace "priming" via the /init command. This allows the AI agent to proactively recognize context and suggest multi-step workflows the moment a file is opened.

Because I'm a journalist, not a coder, I used it to prime my GitHub Copilot VS Code agent with formatting rules for freelance articles, and it worked well. My resulting Editorial Assistant skill recognized the file as a freelancer article, applied the right formatting rules, and even generated a short summary and a tl;dr Key Takeaways box, along with social media posts to promote the article. This was a great demonstration of how workspace priming can make AI agents more proactive and context-aware.

However, the tool choked on an extremely long, code-heavy data science tutorial by Dr. James McCaffrey, which stalled toward the end and left an unformatted tail section.

Subagents

Setting: chat.customAgentInSubagent.enabled

Agents can run subtasks using subagents to break down complex tasks into smaller parts. The nice thing about subagents is that they operate in their own dedicated context window and don't add up to the main agent's context window.

Subagents can now run in parallel, which can significantly speed up tasks that can be split into independent tasks.

To provide more visibility into what the different subagents are doing, the chat conversation now shows details such as what tasks it's doing, the custom agent used for the subagent, and whichever tool is currently used. You can expand the subagent information to show the full details of what it's doing, including the full initial prompt it was provided with and the result it returned.

Because it's designed to break down complex tasks into smaller, verifiable steps. I wanted to see if multi-agent support could make the workflow for my Editorial Assistant skill more dependable and easier to verify when the input is long and error-prone.

My Use Case
My Editorial Assistant skill includes a long set of deterministic formatting steps to prepare articles for our Content Management System: convert curly quotes and apostrophes, normalize dashes, wrap paragraphs, convert subheads to our custom CMS format, and format code blocks. As noted, it also includes author-specific rules (Posey, McCaffrey, Fenton) and additional content generation (summary, Key Takeaways, social posts). This is exactly the kind of workflow where one missed block near the end can ruin the output, and where verification is just as important as transformation.

Baseline Workflow
Before this experiment, I ran everything as one operation: open a freelancer file, run a command like "format this article" in a Chat window and let the Agent (using directions in a SKILL.md file) do all steps in a single pass. It works 99 percent of the time, but when a file is long or code-heavy, it can miss unwrapped text near the end or forget to format a listing. In one failed McCaffrey run, the process stalled and left an unformatted tail section, which is exactly what I wanted to prevent.

Plan for The Multi-Agent Version
The idea was to keep the existing Editorial Assistant skill intact, and add a new multi-agent layer that divides the work into smaller, verifiable steps. I wanted the workflow to stay simple for me: open a file, run "format," and let the system recognize the freelancer and apply the right rules automatically.

High-level plan:

• Create a set of custom subagents for the individual tasks: core formatting, Key Takeaways, summary, social posts, and QA.
• Keep the existing skill untouched so the old workflow still works.
• Add a coordinator agent that detects the author from the file contents and routes to the right subagents.

What I Built
I created a new .github/agents folder with six agent files:

• formatter.agent.md: runs the core formatting rules only.
• takeaways.agent.md: fills the Key Takeaways box only.
• summary.agent.md: creates the summary line only (skipped for McCaffrey, who provides his own).
• social.agent.md: generates X and LinkedIn posts only.
• qa.agent.md: scans for unformatted blocks and missing conversions.
• coordinator.agent.md: orchestrates the workflow, runs parallel subtasks when possible, and writes a handoff report.

Regarding that handoff report, one generated during my testing looked like this:

File: C:/Users/dramel/OneDrive - 1105 MEDIA, INC/Articles/renametest.html

Date/time: 2026-02-08 22:16

Detected author: James McCaffrey

Handoffs:

- formatter: flagged subhead merging, HTML escaping for code, grammar fixes, and social post placement.
- takeaways: supplied three final key takeaways (already used in sidebar).
- social: drafted X and LinkedIn posts, inserted in document.
- qa: reported missing root html element and social posts outside the document; fixed by adding <html> and moving posts inside body.

Author Detection and Routing
I updated the coordinator to read the first ~50 lines of the file and detect the freelancer based on common byline patterns. For example:

• James McCaffrey or Dr. James McCaffrey triggers the McCaffrey formatting path.
• Brien M. Posey or By: Brien M. Posey triggers the Posey path.
• Tom Fenton or By: Tom Fenton triggers the Fenton path.
• If no match is found, it falls back to the standard rules.

Running The Multi-Agent Workflow
I ran the "coordinator" from the Agent dropdown and formatted a McCaffrey data science article with multiple code blocks, figures, and subheads. The coordinator invoked the formatter, then ran takeaways/summary/social as parallel subtasks when possible, and finished with QA.

To give you an idea of how it works, here's a screenshot I grabbed as it churned away through the workflow:

Results
The key improvement was reliability at the tail end of long files. The QA pass caught missed blocks that would have otherwise required manual cleanup. This made the workflow more predictable, and it also made the individual steps easier to audit, because each subagent had a single responsibility.

Just as important, the workflow produced a clean audit trail: each agent had a single role, each step produced a visible output, and the QA pass served as a final gate. As noted,the coordinator also wrote a timestamped handoff report that captures the detected author and a one-line summary of each subagent action.

The Proof of Concept
The takeaway is not that multi-agent orchestration is flashy. It is that it turns a fragile, monolithic workflow into a set of smaller, verifiable steps. That matters in production workflows where a single missed block can invalidate the whole run. This proof of concept shows the value of orchestration as a quality control layer, not just a convenience feature.

Reality Check
The multi-agent features in VS Code 1.109 were primarily designed for coding workflows like planning, implementation, review, and search. My formatting-based experiment sits outside the canonical use case, but it still exercises the same core capability: decomposing a long, multi-step task into smaller, verifiable units and running a final QA pass. It is not the most typical showcase for my audience of developers at Visual Studio Magazine, but it is a legitimate proof of concept for orchestration reliability, and the same pattern can extend directly to real coding projects.

The subagent approach isn't exactly fast. A couple times I got this message:

"Copilot has been working on this problem for a while. It can continue to iterate, or you can send a new message to refine your prompt. Configure max requests."

That last part was linked to a configurable VS Code setting chat.agent.maxRequests that allows you to set a value that controls how many network requests Copilot agents are allowed to make during a single task before suggesting you adjust the limit.

However, while not fast, it's faster than manual editing/formatting and it's more reliable and auditable than my original monolithic approach, which is a critical improvement for production workflows. The big benefit of all this experimentation so far is that a bunch of editing drudgery is now handled with just one command, and the workflow produces a clear audit trail that makes it easy to verify the output and identify any issues that need to be fixed. The ability to run subtasks in parallel will also hopefully evolve to speed up the process when there are independent steps that can be executed simultaneously.

I'll continue to improve it, kind of like training my replacement.