Orchestrating GitHub Copilot Custom Agents in VS Code

-

GitHub Copilot custom agents make it possible to move beyond a single “do everything” assistant. Instead, you can design workflows where multiple agents collaborate, each focused on a specific responsibility.

In this post, I’ll walk through three orchestration modes you can use today when building custom agents in VS Code:

  1. VS Code agent handoffs
  2. Explicit subagent delegation
  3. Automatic subagent delegation
Each mode serves a different purpose. Understanding the trade‑offs helps you decide when you want user control, when you want structure, and when you want the agent to adapt on its own.

1. VS Code Agent Handoffs


```mermaid sequenceDiagram participant User participant MainAgent participant SecurityAgent User->>MainAgent: scan my code for security issues MainAgent->>SecurityAgent: handoff (code review) SecurityAgent-->>MainAgent: report findings MainAgent-->>User: remediation steps ```

Agent handoffs allow one agent to explicitly transfer control to another agent inside VS Code. The key point is that the handoff is visible and intentional, both for the agent and for the user.

A common example is separating general coding assistance from specialist reviews. The main agent stays responsible for the overall interaction, but temporarily hands control to a security‑focused agent for a deeper analysis.

Key Characteristics

  • The transition is explicit and user‑driven
  • Context and conversation history are preserved
  • The user stays in control of when and why a handoff happens
The main Copilot agent hands off to a security agent. Once the review is done, control returns to the main agent, which explains the findings and suggests remediation steps.

Example

A user asks: “Scan my code for security issues.”

This pattern works well when you want a clear human‑in‑the‑loop moment, such as reviews, approvals, or sensitive checks.

2. Custom Agent-to-Agent Subagent Delegation

```mermaid flowchart TD MainAgent[Main Agent] LinterAgent[Linter Agent] TestAgent[Test Agent] BuildAgent[Build Agent] MainAgent --> LinterAgent MainAgent --> TestAgent MainAgent --> BuildAgent LinterAgent --> MainAgent TestAgent --> MainAgent BuildAgent --> MainAgent ```

With explicit subagent delegation, a primary agent programmatically invokes other custom agents to handle well‑defined subtasks. Unlike handoffs, the user does not switch agents. The orchestration happens behind the scenes.

This is useful when you have a repeatable workflow with clear responsibilities, and you want each agent to stay focused on a single concern.

Key Characteristics

  • The primary agent controls orchestration via APIs
  • Subagents run autonomously and return results
  • Tasks can run in parallel or in a defined sequence

Example

A DevOps‑focused agent orchestrates a deployment pipeline:

  • Code linting is delegated to a linter agent
  • Tests are delegated to a test agent
  • Packaging is delegated to a build agent

The main agent collects the results and presents a single, consolidated outcome to the user.

This approach maps well to CI/CD pipelines and other structured automation scenarios.

3. Automatic Delegation to Subagents

```mermaid flowchart TD User[User Request] MainAgent[Main Agent] TestAgent[Test Agent] DeployAgent[Deploy Agent] User --> MainAgent MainAgent -- detects missing tests --> TestAgent TestAgent -- test results --> MainAgent MainAgent --> DeployAgent DeployAgent --> MainAgent MainAgent --> User ```

Automatic delegation pushes orchestration a step further. Instead of relying on predefined rules or explicit calls, the agent decides at runtime whether a subagent is needed.

The decision can be based on context such as project structure, detected issues, or the current stage of the workflow.

What changes here

  • The agent decides when and which subagent to invoke
  • Delegation is driven by intent and context, not static configuration
  • Workflows adapt dynamically as conditions change

Example

A user says: “Deploy my app.”
The main agent inspects the project and notices that tests are missing. Before deploying, it automatically invokes a test agent, waits for the results, and only proceeds if the outcome is acceptable without the user explicitly asking for this step.

This pattern is useful when you want intelligent defaults and minimal user intervention for routine tasks.


Choosing the Right Orchestration Mode

Decision Framework

```mermaid flowchart TD Start([What type of workflow do you need?]) Start --> UserControl{Does the user need to approve transitions?} UserControl -->|Yes| HandoffMode[Agent Handoffs] UserControl -->|No| AutoPattern{Are tasks predictable?} AutoPattern -->|Yes, structured pipeline| DelegationMode[Subagent Delegation] AutoPattern -->|No, context-dependent| AutoMode[Automatic Delegation] HandoffMode --> HandoffDetails[User control
Human-in-the-loop
Context preserved] DelegationMode --> DelegationDetails["Modular workflow
Clear boundaries
Parallel execution"] AutoMode --> AutoDetails[Adaptive behavior
Runtime decisions
Dynamic workflows] ```

Comparison Matrix

| Criteria | Agent-Handoffs | Subagent Delegation | Automatic Delegation | |----------|----------------|---------------------|----------------------| | **User Control** | High - User approves each transition | Medium - User initiates workflow | Low - Agent decides autonomously | | **Complexity** | Low - Simple 1-to-1 handoffs | Medium - Structured orchestration | High - Context-aware logic | | **Use Case** | Interactive reviews, approvals | Pre-defined workflows | Adaptive workflows | | **Setup Effort** | Minimal | Moderate | High | | **Flexibility** | Low - Fixed handoff paths | Medium - Configurable delegation | High - Dynamic runtime decisions |

When to Use Each Mode

Agent handoffs

  • You want explicit user visibility and approval
  • Human oversight is important
  • The task benefits from specialist context

Example: Main agent suggests handing off to a security agent for review.

Subagent delegation

  • The workflow has clear, repeatable stages
  • Multiple specialized tasks need coordination
  • Tasks can run in parallel or in sequence

Example: Lint → test → build → deploy pipeline.

Automatic delegation

  • The agent should adapt based on context
  • The workflow depends on project structure or state
  • You want fewer manual decisions for routine work

Example: Deployment agent automatically invokes tests or security checks when needed.

Try It Yourself

If you want to explore these orchestration styles hands-on, see the accompanying repository:

https://github.com/royarin/github-copilot-agent-orchestration

The repository contains concrete examples for agent handoffs, explicit subagent delegation, and automatic delegation, making it easier to experiment with and compare the different patterns in practice.

Conclusion

Custom agents are not just about adding more capabilities to GitHub Copilot, they’re about structuring responsibility. The orchestration model you choose determines how much control you keep, how predictable your workflows are, and how much autonomy you delegate to the agent.

Agent handoffs work best when humans need to stay in the loop. Explicit subagent delegation shines in structured, repeatable pipelines. Automatic delegation becomes powerful when you want the agent to adapt to context and make sensible decisions on your behalf.

In practice, most real-world solutions will combine these patterns. The goal isn’t to pick a single “best” approach, but to use the right orchestration style at the right point in the workflow.


Comments

Post a Comment

Popular posts from this blog

Automate Import of Functions/WebAPI in Azure API Management as backend and using OpenAPI definition and Terraform

-
Image
 When hosting APIs in Azure it is more and more common to make them available for consumption via an API Management Gateway. The advantages of using a API Management gateway are well known.  When adding a Function/WebAPI to an API Management gateway, the most common method is to add the Function/WebAPI as a backend in API Management and then exposing the Function/WebAPI as an API that uses this backend to process requests. There is a very simple way to do this using the Azure Portal. The portal allows connecting an existing Function or WebAPI inside the API Management gateway.  The portal now also allows to expose a function/web api from the action pane of functions and web api. While this makes it very easy to add APIs to API Management gateway using the portal, this would very soon become unmanageable and for more complex and automated environments, the obvious tilt would then be towards a automated deployment using one of the Infrastructure as Code (IaC) possibilities....
Read more

Managing built-in cache in Azure API Management

-
Image
 Azure API Management offers caching possibilities to improve performance.  There are 2 caching options: Response Caching - Useful for caching entire HTTP responses Value Caching - To cache arbitrary pieces of data from within policy definitions. When it comes to the actual store, APIM supports: Built-in cache External Redis Compatible cache In this blog I will focus on how to manage "Value Caching". How do we set/retrieve/delete values using APIM policies? Typically, Value storage is used for fragment caching - where responses contain data that is expensive to determine and yet remains fresh for a reasonable amount of time. Also, within the APIM policies, we want to cache certain values e.g. OAuth tokens, key-vault secrets, etc. because these remain relatively fresh for a longer period of time. With caching comes the need to manage the cache specially when you need to clear cached values because they are stale.  In some scenarios, where OAuth tokens or secrets are cached...
Read more