How to design orchestrator prompts for multi-agent workflows

Learn how to design orchestrator prompts that coordinate multiple specialized agents through structured phase-based workflows, delegation patterns, and architecture decisions in GitHub Copilot.
Author

Dario Airoldi

Published

February 22, 2026

How to design orchestrator prompts for multi-agent workflows

When a single prompt can’t handle a complex, multi-step task, you need an orchestrator—a coordinator agent that delegates subtasks to specialized agents and synthesizes their results. This article teaches you how to design orchestrator prompts that are clear, maintainable, and effective.

Up to this point in the series, you’ve learned how to structure individual customization files: instructions, prompts, agents, skills, hooks, and tools. Each one handles a specific piece of the customization puzzle. But real-world workflows often require multiple agents working together—a planner gathering context, a builder implementing changes, a reviewer checking quality.

This article bridges that gap. It introduces the orchestrator pattern—the architectural foundation for multi-agent coordination—and teaches you how to design orchestrator prompts that decompose complex tasks into clear phases, delegate work to specialized agents, and control execution flow. Later articles cover the mechanics in detail: subagent APIs, information flow, and token optimization.

Table of contents

🎯 The problem: monolithic prompts don’t scale

Consider a task like “restructure our authentication module to use OAuth 2.0.” A single monolithic prompt would need to:

  1. Research the existing auth implementation
  2. Analyze OAuth 2.0 requirements
  3. Design the migration architecture
  4. Implement the changes across multiple files
  5. Update tests and documentation
  6. Review the changes for security issues

That’s six fundamentally different activities crammed into one context window. The model loses focus, forgets constraints from step 1 by the time it reaches step 5, and you can’t intervene between phases to steer direction. The result is often a sprawling, uncontrollable session that drifts from the original intent.

The core issues with monolithic prompts:

Problem Impact
Context window bloat Earlier instructions get pushed out as the session grows
Role confusion The model switches between researcher, architect, and coder without clear boundaries
No checkpoints You can’t review intermediate results before the model moves on
Wasted tokens Research context consumed during implementation has no further value
Debugging difficulty When something goes wrong, you can’t isolate which phase caused it

The orchestrator pattern solves these problems by decomposing complex tasks into phases, each handled by a focused agent with its own context window.

🏗️ The orchestrator pattern

Core architecture

An orchestrator is a coordinator agent that doesn’t do the detailed work itself. Instead, it:

  1. Decomposes the task into discrete phases
  2. Delegates each phase to a specialized agent
  3. Synthesizes the results into a coherent outcome
  4. Controls the execution flow between phases

Think of it as a project manager. The PM doesn’t write code, design databases, or run tests—they coordinate the people who do, ensuring the right work happens in the right order with the right information.

The coordinator and worker model

┌─────────────────────────────────────────────┐
│              ORCHESTRATOR                   │
│                                             │
│  "For each feature request:"                │
│  1. Delegate research to → Researcher       │
│  2. Review findings, decide approach        │
│  3. Delegate implementation to → Builder    │
│  4. Delegate review to → Reviewer           │
│  5. If issues found → Builder (fix cycle)   │
│  6. Synthesize final result                 │
│                                             │
└─────────────────────────────────────────────┘
        │              │              │
        ▼              ▼              ▼
  ┌───────────┐  ┌───────────┐  ┌───────────┐
  │ Researcher│  │  Builder  │  │ Reviewer  │
  │           │  │           │  │           │
  │ read-only │  │ edit, run │  │ read-only │
  │  tools    │  │   tools   │  │  tools    │
  └───────────┘  └───────────┘  └───────────┘

Each specialist operates in its own isolated context window. The orchestrator receives only the condensed results—not the full research trail or implementation attempt. This isolation is the key architectural advantage: it keeps the coordinator’s context focused on decisions, not details.

Execution contexts

Orchestrator workflows can run across three execution environments. Understanding these helps you design orchestrators that match your task’s requirements:

Context Where it runs Interaction Best for
Local agent Your VS Code instance Interactive, real-time Research, planning, iterative design
Background agent CLI-based, local machine Non-interactive Well-defined implementation tasks
Cloud agent Remote infrastructure Async, via PRs Team collaboration, autonomous tasks

A practical workflow might start local (interactive planning), hand off to background (autonomous implementation), then move to cloud (PR review with the team). VS Code supports handing off sessions between these contexts, carrying conversation history forward.

The Agent HQ pattern

For complex orchestrations, you’ll want a central coordination point—what we call Agent HQ (Headquarters). This is the orchestrator agent that serves as the entry point for all multi-step tasks. Agent HQ:

  • Receives the user’s high-level request
  • Plans the execution phases
  • Selects the appropriate specialist for each phase
  • Monitors intermediate results for quality and relevance
  • Decides whether to proceed, iterate, or abort

You implement Agent HQ as a custom agent file (.agent.md) with:

  • Read-only tools for research and analysis
  • The agent tool for spawning subagents
  • Clear phase definitions in its instructions
  • agents frontmatter to restrict which specialists it can invoke
---
name: Agent HQ
description: Multi-phase workflow coordinator
tools: ['agent', 'read', 'search', 'fetch']
agents: ['Researcher', 'Builder', 'Reviewer', 'Validator']
---

📋 Designing specialized agents

Agent anatomy

Each specialist agent needs three things defined:

  1. Role — What it focuses on (research, implementation, review)
  2. Tools — What capabilities it has (and crucially, what it can’t do)
  3. Constraints — Boundaries on its behavior

Tool access as a design lever

Tool restriction is the most powerful lever for controlling specialist behavior. A reviewer agent with read-only tools can’t accidentally modify files. A builder agent without the fetch tool stays focused on implementation rather than wandering into research.

# Reviewer: read-only access prevents accidental changes
---
name: Reviewer
user-invokable: false
tools: ['read', 'search', 'grep']
---
Review code changes for quality, security, and adherence to project patterns.
Focus on actionable feedback. Don't suggest purely stylistic changes.
# Builder: full editing capabilities, no research tools
---
name: Builder
user-invokable: false
model: ['Claude Haiku 4.5 (copilot)', 'Gemini 3 Flash (Preview) (copilot)']
tools: ['edit', 'read', 'search', 'run_in_terminal']
---
Implement changes according to the plan provided.
Follow existing code patterns. Run tests after making changes.

Notice that the builder uses a faster, cheaper model. Specialists with narrow focus often perform well with smaller models, reducing token costs without sacrificing quality.

The user-invokable and disable-model-invocation properties

Two frontmatter properties control how agents appear and interact:

Property Default Effect
user-invokable true Controls whether the agent appears in the agents dropdown
disable-model-invocation false Prevents the agent from being auto-invoked as a subagent

For specialist agents in an orchestration, set user-invokable: false. This keeps them out of the dropdown—they’re only accessible through the orchestrator. The orchestrator itself should have user-invokable: true (the default) so users can select it directly.

The four-specialist pattern

A practical starting architecture for most orchestration workflows uses four specialist roles:

Role Purpose Tools Model strategy
Researcher Gather context, analyze existing code read, search, fetch, grep Standard—needs strong reasoning
Builder Implement changes, write code edit, read, search, run_in_terminal Can use faster/cheaper model
Validator Run tests, check constraints read, run_in_terminal Can use faster/cheaper model
Reviewer Quality review, security check read, search, grep Standard—needs strong judgment

This isn’t a rigid template. Some workflows need only two specialists (plan + implement). Others need more granular specialization (separate security reviewer, documentation writer, migration specialist). Start with the minimum and add specialists only when you observe clear role confusion in a simpler setup.

When to split vs. combine roles

Split when:

  • Two roles need different tool access (reviewer shouldn’t edit, builder shouldn’t research all day)
  • The work produces large intermediate artifacts that would bloat a shared context
  • You want independent quality gates between phases

Combine when:

  • The roles need the same tools and context to be effective
  • The combined work fits comfortably in one context window
  • Splitting would create too much handoff overhead

🔀 Phase-based coordination

Designing the phase flow

An orchestrator’s central design challenge is defining the phase sequence—which work happens when, what information flows between phases, and where humans can intervene.

Linear flow

The simplest pattern. Each phase completes before the next begins:

Research → Plan → Implement → Test → Review → Done

Good for well-understood tasks with clear sequential dependencies. The output of each phase feeds into the next.

Iterative flow

Phases can loop back when quality gates aren’t met:

Research → Plan → Implement → Review ─┐
                     ▲                 │
                     └── (issues) ─────┘

The orchestrator decides whether to iterate based on the reviewer’s findings. Set iteration limits to prevent infinite loops:

Iterate between implementation and review at most 3 times.
If the reviewer still reports critical issues after 3 iterations,
stop and present the current state with remaining issues for human review.

Parallel flow

Independent phases run simultaneously:

         ┌→ Security review ──┐
Task → ──┤→ Performance check ├→ Synthesize → Done
         └→ Test generation ──┘

VS Code can spawn multiple subagents concurrently. Use parallel flow when phases don’t depend on each other’s output—for example, running multiple review perspectives at once. The orchestrator waits for all results before continuing.

Handoff configuration

When using agent-level handoffs (not subagents), the handoffs frontmatter controls transitions between orchestation phases:

---
name: Planner
tools: ['read', 'search']
handoffs:
  - label: Start Implementation
    agent: Builder
    prompt: "Implement the plan outlined above."
    send: false
  - label: Request More Research
    agent: Researcher
    prompt: "Research the following areas identified in the plan..."
    send: false
---

The send property determines automation level:

send value Behavior Best for
false (default) Shows button, user clicks to proceed Review checkpoints, human-in-the-loop
true Automatically starts the next phase Fully automated pipelines

Design guidance: Default to send: false for phases where human review adds value (after planning, after implementation). Use send: true only for transitions that don’t benefit from human inspection (automatic test runs after implementation).

Handoffs vs. subagents

Handoffs and subagents serve different coordination purposes:

Aspect Handoffs Subagents
Control User-driven transitions Agent-initiated delegation
Context Full conversation carries forward Isolated context, only summary returns
Visibility New session with history Collapsed tool call in main session
Best for Sequential workflows with review gates Research, analysis, parallel tasks

Use handoffs when you want users to review and approve each phase. Use subagents when the orchestrator should autonomously delegate work and synthesize results. Many real workflows combine both—handoffs for major phase boundaries and subagents for focused subtasks within phases.

🎯 The use case challenge methodology

Before building an orchestrator, you need to validate that your use case actually requires one. The Use Case Challenge is a structured validation methodology that prevents over-engineering.

The challenge framework

For each proposed orchestrator, answer these five questions:

1. Complexity check

“Can a single agent with good instructions handle this task?”

If yes, you don’t need an orchestrator. A well-structured agent file with clear instructions often outperforms a poorly designed multi-agent system. Always try the simple approach first.

Signs you need orchestration:

  • The task requires fundamentally different tool sets at different stages
  • Context window fills up before the task completes
  • You need quality gates between phases
  • Different phases benefit from different models or personas

2. Role definition

“Can you clearly name and describe each specialist’s role in one sentence?”

If you can’t articulate what each agent does in a single sentence, your decomposition is wrong. Vague roles (“Helper Agent”, “Support Agent”) indicate unclear boundaries.

Good roles:

  • “Researcher: Analyze the existing codebase to understand current authentication patterns, dependencies, and test coverage.”
  • “Builder: Implement the OAuth 2.0 migration according to the approved plan, following existing code patterns.”

Bad roles:

  • “Agent 1: Handle the first part of the work.”
  • “Support: Help with various tasks as needed.”

3. Handoff clarity

“What exactly passes between phases—and is it clearly structured?”

Every phase transition needs a defined contract: what the receiving agent gets and in what format. Vague handoffs (“pass the results”) lead to information loss and hallucination.

Structured handoff:

The Researcher outputs a JSON report:
- `files_analyzed`: list of relevant file paths
- `current_patterns`: description of existing patterns
- `dependencies`: list of affected dependencies
- `risks`: identified migration risks

4. Failure handling

“What happens when a specialist fails or produces poor results?”

Every phase can fail. Your orchestrator needs explicit strategies for:

  • Retry: Run the specialist again with adjusted instructions
  • Escalate: Present the issue to the user for guidance
  • Skip: Proceed without that phase’s output (if non-critical)
  • Abort: Stop the workflow entirely

5. Value verification

“Does the multi-agent approach measurably improve on the single-agent approach?”

After building v1, compare results. Sometimes the orchestration overhead (design time, token costs, debugging complexity) exceeds the quality improvement. This isn’t a failure—it’s learning that the task doesn’t benefit from decomposition.

🧠 Architecture decisions: when to orchestrate

The decision framework

Not every complex prompt needs an orchestrator. Use this framework to decide:

┌─────────────────────────────────────────────────────────┐
│           Is the task multi-phase?                       │
│                                                         │
│  NO → Use a single agent or prompt file                 │
│  YES ↓                                                  │
├─────────────────────────────────────────────────────────┤
│           Do phases need different tools?                │
│                                                         │
│  NO → Consider a single agent with phased instructions  │
│  YES ↓                                                  │
├─────────────────────────────────────────────────────────┤
│           Does context fill up within one session?       │
│                                                         │
│  NO → Single agent with clear phase markers works       │
│  YES ↓                                                  │
├─────────────────────────────────────────────────────────┤
│           Do you need quality gates between phases?      │
│                                                         │
│  NO → Subagents for context isolation only              │
│  YES → Full orchestrator with handoffs + subagents      │
└─────────────────────────────────────────────────────────┘

Architecture tiers

Tier Setup When to use
Single prompt One .prompt.md file Simple, focused tasks
Single agent One .agent.md with phased instructions Multi-step but same tool set throughout
Agent + subagents One main agent spawning subagents Context isolation needed, no human checkpoints
Full orchestrator Coordinator + specialist agents + handoffs Complex, multi-phase, different tools per phase

Start at the simplest tier that handles your requirements. Upgrade when you observe specific limitations—not proactively.

Tool composition validation

Before deploying an orchestrator, validate your tool composition:

  1. Coverage check — Do your specialists collectively have access to all tools the workflow needs?
  2. Isolation check — Do specialists have access to only the tools they need? (Principle of least privilege)
  3. Conflict check — Might two specialists try to edit the same files simultaneously?
  4. MCP integration — Do any specialists need MCP server tools? Are those servers properly configured?
## Tool composition audit

| Agent | Tools needed | Tools granted | Gap? | Risk? |
|-------|-------------|---------------|------|-------|
| Researcher | read, search, fetch | read, search, fetch | ✅ None | Low |
| Builder | edit, read, terminal | edit, read, search, terminal | ✅ None | Medium (terminal access) |
| Reviewer | read, search | read, search, grep | ✅ None | Low |
| Validator | read, terminal | read, terminal | ✅ None | Medium (terminal access) |

⚙️ Execution flow control

Iteration control

Orchestrators must set explicit limits on iterative loops to prevent runaway sessions:

## Iteration limits

- Implementation → Review cycle: maximum 3 iterations
- Research → Planning refinement: maximum 2 iterations
- Overall workflow: maximum 5 total specialist invocations

If any limit is reached:
1. Summarize the current state
2. List unresolved issues
3. Present to the user for manual decision

Without iteration limits, a perfectionist reviewer paired with a compliant builder can loop indefinitely—each review finding new minor issues, each fix introducing new review surface.

Recursion prevention

Prevent agents from spawning subagents that spawn more subagents:

## Recursion rules

- Specialist agents MUST NOT spawn their own subagents
- Only the orchestrator coordinates specialist invocations
- Maximum orchestration depth: 1 (orchestrator → specialist, never deeper)

Use disable-model-invocation: true on specialist agents and control the agents array on the orchestrator to enforce this structurally rather than relying on instructions alone.

Error handling patterns

Scenario Strategy Implementation
Specialist returns empty result Retry once with explicit diagnostic prompt “The previous attempt returned no results. Explain what you searched for and what you found.”
Specialist contradicts plan Present both perspectives to the user Include the original plan and the specialist’s objection in a summary
Tool execution fails Log the error, try alternative approach “If npm test fails, try npx jest directly”
Context window exhausted Summarize current progress, start new session Create a handoff with a condensed summary of completed work

Parallel vs. sequential execution

Use parallel execution when:

  • Tasks are independent (security review AND performance review of the same code)
  • You want faster overall completion
  • Results don’t need to feed into each other

Use sequential execution when:

  • Later phases depend on earlier results (implementation depends on research)
  • You need human checkpoints between phases
  • Order matters for correctness (tests before review)
# Parallel: independent review perspectives
---
name: Thorough Reviewer
tools: ['agent', 'read', 'search']
agents: ['Security Reviewer', 'Performance Reviewer', 'Code Quality Reviewer']
---
Run all three review perspectives as parallel subagents.
Synthesize findings into a single prioritized list.

🎛️ Context engineering for orchestrators

The context budget

Every orchestrator operates within a context window budget. The orchestrator’s own context should stay lean—it’s primarily a decision-making layer, not a processing layer.

What belongs in the orchestrator’s context

Include Exclude
Phase definitions and sequencing Detailed implementation instructions
Specialist selection criteria Full code listings
Quality gate thresholds Research findings (keep in specialist context)
Iteration limits and error strategies Intermediate artifacts
Condensed summaries from specialists Raw tool output

The summarization principle

When a specialist returns results, the orchestrator should receive a structured summary, not the full context. This is where subagents shine—they process information in their isolated context and return only what the orchestrator needs to make its next decision.

Good specialist output:

## Research summary
- 12 files affected (listed in appendix)
- Current pattern: session-based auth with JWT tokens
- Migration risk: HIGH (3 shared services depend on current auth)
- Recommended approach: adapter pattern for backward compatibility
- Estimated effort: 4-6 hours

Poor specialist output:

I read through all the files and here's what I found. In src/auth/login.ts
there's a function called authenticateUser that takes... [500 lines of
paraphrased code analysis]

For a detailed treatment of information flow patterns, data contracts, and token management across orchestrations, see How to Manage Information Flow During Prompt Orchestrations and How to Optimize Token Consumption During Prompt Orchestrations.

💡 Key design principles

After studying orchestration patterns across many workflows, these principles consistently distinguish effective orchestrators from fragile ones:

1. Start simple, add complexity when observed

Don’t begin with a five-specialist architecture. Start with a single agent. When you observe specific failure modes—context overflow, role confusion, lack of checkpoints—add the minimal orchestration that addresses those failures.

2. Define roles by tools, not just instructions

Instructions guide behavior. Tool access constrains it. A reviewer with edit tools will eventually make edits, regardless of instructions saying “don’t edit files.” Remove the tools you don’t want used.

Role specialization extends to model selection. In a model-per-role pattern, each agent uses the model best suited to its function—a reasoning-heavy model for planning, a code-optimized model for implementation, a design-focused model for UI work. Burke Holland demonstrates this approach in his ultralight orchestration framework, assigning a different model to each of four agents. Specific model choices are inherently volatile—evaluate capabilities at time of use rather than hardcoding recommendations. See article 08 for model family strengths and weaknesses.

3. Design explicit handoff contracts

Every phase transition should define:

  • What information passes (structured format, not free text)
  • How much information passes (summaries, not raw data)
  • When the transition happens (explicit conditions, not “when ready”)

4. Set iteration limits early

Unbounded loops are the most common orchestration failure. Set limits in the orchestrator’s instructions and enforce them. Three iterations of implement→review is usually sufficient.

5. Prefer sequential over parallel by default

Parallel execution is faster but harder to debug. Start sequential where each phase’s output is visible and inspectable. Switch to parallel only when you’ve validated that the phases are truly independent.

6. Keep the orchestrator thin

The orchestrator should coordinate, not process. If your orchestrator instructions are longer than your specialist instructions, you’re probably doing too much work in the coordinator. Move processing logic to specialists.

7. Plan for failure at every transition

Every handoff can fail. Every specialist can produce poor results. Design your orchestrator to detect failures early and have explicit recovery strategies—don’t assume the happy path.

8. Validate before you build

Use the Use Case Challenge methodology before investing in a multi-agent orchestration. Many complex-seeming tasks are better handled by a single agent with clear instructions.

9. Delegate goals, not solutions

Models naturally want to micromanage. When an orchestrator delegates to a sub-agent, it tends to include step-by-step instructions for how the sub-agent should work—overriding the sub-agent’s own expertise. You have to explicitly prevent this.

“These models think they know everything, and so you have to really go out of your way to make sure that they don’t do that.” — Burke Holland, Senior Cloud Advocate, Microsoft

Address both sides of the delegation boundary:

  • Orchestrator side — Instruct the orchestrator to describe what it needs (goals, constraints, acceptance criteria) without dictating how to achieve it. For example: “Delegate tasks to specialists. Describe the desired outcome. Do not include implementation steps.”
  • Sub-agent side — Include a counter-instruction that grants autonomy: “Question everything you’re told. Make your own decisions.” This lets the sub-agent push back against over-specified instructions.

This principle complements “Keep the orchestrator thin” (Principle 6). A thin orchestrator coordinates; a non-micromanaging orchestrator also trusts. Combined, they produce specialists that leverage their full tool access and model strengths rather than blindly following prescriptive steps.

Practical pattern: Plan → Generate → Implement

Many of the principles above converge in a concrete three-phase workflow pattern demonstrated by Burke Holland (Senior Cloud Advocate, Microsoft). It’s a practical example of model routing, context separation, and thin orchestration working together:

┌──────────────────────────────────────────────────────────────────┐
│  PHASE 1 — PLAN (premium model, e.g., Claude Opus 4.5)          │
│  Prompt file researches the codebase and produces a              │
│  branch-oriented plan where each step is a testable commit       │
│                                                                  │
│  Output: plan.md                                                 │
│  ⚠️ Clear context window after this phase                        │
├──────────────────────────────────────────────────────────────────┤
│  PHASE 2 — GENERATE (premium model)                              │
│  Prompt file takes plan.md and writes all implementation         │
│  code into a markdown document—step by step, with checkboxes—    │
│  without modifying the project                                   │
│                                                                  │
│  Output: implementation.md (~2,000 lines)                        │
│  ⚠️ Clear context window after this phase                        │
├──────────────────────────────────────────────────────────────────┤
│  PHASE 3 — IMPLEMENT (free model, e.g., GPT-4.1 mini)           │
│  Custom agent implements code verbatim from                      │
│  implementation.md—one step at a time, stopping after each       │
│  so you can test, stage, and commit                              │
│                                                                  │
│  Output: a clean PR built from incremental commits               │
└──────────────────────────────────────────────────────────────────┘

Why this pattern works:

  • Model routing (Principle 2) — Premium models handle reasoning-heavy work (planning, code generation). A free model handles the low-reasoning execution step, saving premium requests.
  • Context separation — Clearing the context window between phases prevents context rot. Each phase starts fresh with only the artifact it needs.
  • Thin orchestration (Principle 6) — The orchestrator is the developer. Phases 1 and 2 are prompt files; Phase 3 is a custom agent. No complex coordinator agent is needed.
  • Explicit handoff contracts (Principle 3) — Each phase produces a structured markdown document that the next phase consumes. The contract is the file itself.

Key implementation details:

  • Prompt files for Phases 1 and 2 use the model: frontmatter property to route to premium models, regardless of the active model in chat
  • The custom agent for Phase 3 is deliberately instructed to implement verbatim—it should not reinterpret or “improve” the generated code
  • Context clearing is manual: start a new chat session between phases

This pattern exemplifies the “start simple” principle (Principle 1)—it doesn’t require multi-agent orchestration infrastructure. Three files and manual context clearing can achieve results that would otherwise need a complex coordinator.

For a full orchestration case study using automated multi-agent coordination, see Orchestrator Design Case Study.

🎯 Conclusion

Orchestrator prompts are the architectural glue that holds multi-agent workflows together. The key takeaways:

  • Orchestrators coordinate, they don’t process — Keep the coordinator focused on phase sequencing, delegation, and quality gates
  • Specialize by tool access — The most effective way to enforce role boundaries is through tool restriction, not just behavioral instructions
  • Design phase transitions explicitly — Clear handoff contracts with structured data prevent information loss between phases
  • Validate before building — The Use Case Challenge methodology prevents over-engineering; always start with the simplest approach that works
  • Set limits everywhere — Iteration caps, recursion prevention, and error handling strategies prevent orchestrations from running away

What’s next

Now that you understand orchestrator design patterns, explore the implementation details:

📚 References

Official documentation

VS Code: Custom Agents [📘 Official]
Microsoft’s official documentation for custom agents in VS Code. Covers agent file structure, frontmatter properties, handoffs, tool configuration, and the agents property for subagent restriction. The definitive reference for agent design.

VS Code: Agents Overview [📘 Official]
Comprehensive overview of agent types (local, background, cloud, third-party), session management, and hand-off mechanics. Essential for understanding execution contexts and when to use each agent type.

VS Code: Subagents [📘 Official]
Official documentation for subagent execution, context isolation, orchestration patterns (coordinator-worker, multi-perspective review), and the runSubagent tool. The foundation for understanding delegation mechanics.

VS Code: Copilot Customization Overview [📘 Official]
High-level overview of all Copilot customization options—instructions, prompts, agents, skills, and hooks. Explains how different customization types compose together in an orchestration.

VS Code: Chat Sessions [📘 Official]
Session management including context windows, checkpoints, message queuing, and steering. Helps understand how orchestrator sessions accumulate context and how to manage session lifecycle.