The Complete Plain-English Guide
Every confusing new word — instructions, prompts, skills, hooks, agents, modes, models — explained simply, with real examples you can copy and a reading list at the end.
01
Copilot is an AI helper that lives inside your code editor. On its own it's smart but forgetful. Every feature below is just a way to teach it — about your project, your rules, and your tools — so it stops guessing and starts helping properly.
Think of Copilot as a brand-new coworker on their first day. Everything you set up is you handing them the handbook, the to-do lists, and the keys to the tools.
All of it is saved as plain text files in a hidden folder called .github/ inside your project. So your whole team shares the same setup, and it travels with the code in Git.
Why this matters: these aren't gimmicks. The difference between Copilot guessing wildly and Copilot nailing your task is almost always how well you've set up these files. Five minutes here saves hours later.
02
Six things you can give Copilot. Each one below has a plain explanation and a real example you can copy.
Like rules taped to the office fridge: everyone follows them, all the time, without being asked.
A short list of "always do this, never do that." Copilot reads it on every request automatically. Keep it tight — every line is re-read each time, so it competes with your actual task for the AI's attention.
Example — .github/copilot-instructions.md
# Project: Inventory API ## Stack - Python 3.12, FastAPI, PostgreSQL - Tests with pytest. Run them with: pytest -q ## Rules - Always add type hints to every function. - Never commit secrets. Read config from environment variables. - Use snake_case for files and functions. - When you add a feature, add a test for it in the same change.
Want rules for ONLY certain files? Add a scoped file
Name it react.instructions.md and add a small header saying where it applies:
--- applyTo: "**/*.tsx" --- Use functional components and hooks. Prefer named exports over default exports.
Fastest start: type /init in the chat and Copilot writes a first draft by reading your project. Then trim it.
Like a recipe card in a drawer: pull it out and cook the same dish again with one move.
A task you repeat often. Save it once, then run it any time by typing a slash command (the file name becomes the command).
Example — .github/prompts/security-review.prompt.md
# Security review
Review the selected code for:
- SQL injection and unsafe string building
- Secrets or API keys left in the code
- Missing input validation
For each issue: name the line, explain the risk in
one sentence, and show the corrected code.
Now typing /security-review runs all of that. Teams usually keep 5–10, like /release-notes, /new-component, /explain-this.
Like giving someone a job title. The "Reviewer" thinks differently from the "Planner."
A persona with its own personality, its own allowed tools, and even its own favourite AI brain. The top part (between the dashes) is the settings; below it is the personality.
Example — .github/agents/reviewer.agent.md
--- name: "Security Reviewer" description: "Checks code for security problems" tools: ["search", "editFiles"] model: "Claude Opus 4.8" --- You are a strict security reviewer. Flag every risk you find. Never wave something through just because it looks small. Suggest a safer version.
The power move: have a few agents hand work to each other — a Planner figures out the steps, a Coder writes them, a Reviewer checks them. (That's the "Orchestrator → Planner → Coder" picture you see in agent diagrams.)
A toolbox where each tool has a label. Copilot only opens the drawer it actually needs, when it needs it.
A packaged "how to do X" — instructions plus any helper scripts or templates, bundled in a folder. The clever bit is how it loads in three stages, so it stays cheap:
So you can keep dozens of skills without slowing Copilot down. And the same skill works in the editor, the command line, and the cloud — build it once.
Example — the folder layout
.github/skills/ pdf-filler/ SKILL.md # the label + the how-to template.pdf # loaded only when needed fill.py # a helper script
Example — SKILL.md (the folder name must match the name)
--- name: pdf-filler description: "Fill a PDF form from a row of data." --- To fill the form, run fill.py with the data file. Use template.pdf as the base. Save the result to the outputs folder.
Build one easily: type /create-skill and describe it; Copilot scaffolds the folder and files for you.
A guard at the door who checks every person, no matter what. The rule cannot be talked around.
Instructions are advice the AI usually follows. Hooks are law. A hook is a small command that runs automatically at set moments — for example "tidy the code after every edit," or "block any dangerous delete before it runs."
Example — tidy code after every edit · .github/hooks/format.json
{
"hooks": {
"PostToolUse": [
{
"type": "command",
"command": "npx prettier --write \"$TOOL_INPUT_FILE_PATH\""
}
]
}
}
Save it, and every time Copilot edits a file, Prettier cleans it up — automatically, guaranteed. Full section on hooks below (§04).
Giving your coworker a phone so they can call the bank, the warehouse, or the database.
By default Copilot only knows your code. An MCP connection lets it reach outside — to a database, a live API, a ticket tracker — and pull real information or take action there. You add these from the same control panel (gear icon → MCP), often by browsing a marketplace.
Bonus — AGENTS.md: one file that acts like a welcome guide for any AI tool (not just Copilot — it's an open standard). Write it like onboarding a new teammate. Best-practice shape, in order:
Keep it skimmable — it's read on every request, so don't waste space.
Before the decision table, here's the whole system on one screen — what each piece is and where it lives. The organizing principle underneath it is when it loads and who triggers it: always-on, scoped, on-demand, or manual.
| Piece | Lives at | In one line |
|---|---|---|
| Always-on instruction | copilot-instructions.md | The small, always-on constitution — read on every request. |
| Scoped instruction | instructions/*.instructions.md | A persistent project rule, switched on by file glob. |
| Prompt file | prompts/*.prompt.md | A manual trigger — a one-command workflow shortcut. |
| Custom agent | agents/*.agent.md | A persistent role: tool boundary + behavior (an operating mode). |
| Skill | skills/*/SKILL.md | A reusable procedural capability, loaded on demand. |
| Hook | hooks/*.json | A deterministic guarantee, fired at a lifecycle moment. |
| MCP server | gear → MCP | A phone line to outside tools and data. |
| Reference markdown | reference/*.md (linked) | Passive knowledge — only useful if linked or included. |
The through-line: instructions are rules, skills are procedures, agents are roles, prompts are shortcuts, and references are just knowledge. Five different jobs — which is exactly why stacking several on one task (§12) composes instead of repeating itself. The split also tells you the cost: always-on pieces tax every request, on-demand pieces cost nothing until used.
03
The fastest way to decide. Match what you want on the left to the tool on the right.
| I want to… | Use | Where it lives |
|---|---|---|
| Set rules followed every time | Instructions | copilot-instructions.md |
| Rules for only some files | Scoped instructions | *.instructions.md |
| Re-run a task on demand | Prompt file | *.prompt.md |
| Give the AI a role + tools | Custom agent | *.agent.md |
| Bundle a skill with scripts | Skill | SKILL.md |
| Force something every time | Hook | hooks/*.json |
| Reach outside data/tools | MCP server | editor UI |
The one-question test: "Must this happen every time, with zero chance the AI skips it?" → it's a Hook. If it's just guidance the AI should usually follow → Instructions.
04
Hooks are the most powerful and most misunderstood piece, so here's the full picture in plain words. A hook fires at one of eight moments during the AI's work:
| Moment | Fires when… | Good for |
|---|---|---|
| SessionStart | you send the first message | tell the AI the branch, version, environment |
| UserPromptSubmit | you send any message | keep a record, add hidden context |
| PreToolUse | before the AI uses any tool | block, allow, or pause an action — the strongest hook |
| PostToolUse | after a tool finishes | auto-format, run a linter, log the result |
| PreCompact | before old chat is trimmed | save important context first |
| SubagentStart | a helper agent starts | give the helper its own context |
| SubagentStop | a helper agent finishes | collect / double-check its results |
| Stop | the AI is about to finish | run the tests before it calls it done |
The PreToolUse hook can deny an action before it ever runs — no matter how the AI was talked into it. Point the hook at a tiny script:
.github/hooks/safety.json
{
"hooks": {
"PreToolUse": [
{ "type": "command", "command": "./scripts/block-dangerous.sh" }
]
}
}
scripts/block-dangerous.sh
#!/bin/bash INPUT=$(cat) CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty') # If the AI tries rm -rf or DROP TABLE, refuse it if echo "$CMD" | grep -qE '(rm -rf|DROP TABLE)'; then echo '{"hookSpecificOutput":{"permissionDecision":"deny", "permissionDecisionReason":"Blocked by safety policy"}}' else echo '{"hookSpecificOutput":{"permissionDecision":"allow"}}' fi
The three decisions a hook can return: allow (let it run), ask (pause for your OK), deny (refuse). If several hooks disagree, the strictest one wins.
Safety note: if the AI can edit your hook scripts, it could rewrite its own guardrails. Turn on the setting that requires your approval before any hook script is edited (chat.tools.edits.autoApprove). On a company account, hooks may be switched off by your admin.
Coming from Claude Code? VS Code reads your .claude/settings.json hooks too — but it ignores the "matcher" field (hooks run on all tools), and some field names differ (file_path becomes filePath). Tweak the scripts when you port them.
05
Skills are the one block where the folder layout is the feature. The whole point is progressive disclosure — keeping detail on disk and pulling only the slice a task needs into the AI's limited memory. A common confusion: people expect three folders for "three levels." It's the other way around.
references/, scripts/, and assets/ all live at the same (third) level.name + description only (~30–100 tokens). Loaded for every skill at startup, so the AI knows what it could reach for. This is the discovery surface.references/, scripts/, assets/. Sits on disk at zero token cost until the body points at it during execution.So the tidy one-line skill you've seen — just a SKILL.md — is the minimal valid skill: levels 1 and 2 only. You add level-3 folders the moment a skill outgrows a single file.
.github/skills/pdf-filler/ SKILL.md # Level 1 (frontmatter) + Level 2 (body) references/ FORMS.md # how AcroForm vs XFA fields differ — READ when filling assets/ w9-mapping.json # a field-mapping template — READ when that form comes up scripts/ fill_form.py # deterministic fill via pypdf — RUN, never read into context
The body pulls each one in by relative path, only at the moment it's needed:
# inside SKILL.md For XFA forms, see references/FORMS.md before proceeding. Map fields using assets/w9-mapping.json. Then run: scripts/fill_form.py --in {input} --out {output}
Level-3 resources split into two kinds, and the difference is the whole reason skills beat a giant prompt:
references/ and assets/ get loaded into context when referenced, so they do cost tokens. Pull in only the slice you need.scripts/ are executed (via the terminal), not read into memory. They give deterministic, repeatable results at near-zero token cost — perfect for the fiddly, exact steps you don't want an LLM improvising.The mental split: instructions for flexible guidance, code for reliability, resources for factual lookup. If a step must come out the same way every time, make it a script, not a paragraph.
references/ so it loads on demand instead of bloating every activation.references/FORMS.md directly; avoid chains where one reference loads another that loads another.And remember Lesson 5 (§12): the description is what decides whether level 2 ever loads at all. "Fills PDFs" is weak; "Fills AcroForm and XFA PDF forms from a field-mapping file, flattening the result" is what gets the skill picked at the right moment.
06
A little dropdown in the chat box changes how much freedom you give Copilot. From most cautious to most hands-off:
You ask, it answers. Like searching the web — it explains things but doesn't touch your code unless you copy the answer yourself. Best for "how does this work?"
You point at the exact files. It makes changes and you approve each one. Best for a small, clear change you want to watch closely.
You give a goal — "add a login page." It picks the files, writes the code, runs commands, sees its own errors, and fixes them. Best for bigger jobs across many files.
Before doing anything, it explores your project, asks you questions, and writes a to-do list for your approval. Best when the job is big or fuzzy and you don't want surprises.
Simple rule: 3+ files to do by hand → Agent. Big or unclear → start with Plan. One question or tiny edit → Ask / Edit.
Money-saver: in Agent mode, one message you send = one charge; all the AI's follow-up work (edits, retries, commands) is free. So one big request is cheaper than ten small ones.
07
Three symbols you type right in the chat box. They're how you hand Copilot the right context instead of hoping it guesses. Learn these three and your results jump immediately.
Attach exact context: #file a specific file, #selection the highlighted code, #codebase the whole project, #terminalLastCommand the last terminal output, #problems the current errors. Use # when the AI needs to see something specific to answer well.
Address a built-in participant: @workspace answers about your whole project, @terminal about shell commands, @vscode about the editor itself. Extensions and MCP servers can add their own. Use @ to pick who should handle the question.
Fire a saved command: built-ins like /fix, /tests, /explain, plus every prompt file and skill you've made shows up here automatically. Use / to re-run something you do often.
Tool Sets: in the chat … menu you can bundle a group of tools under one name (say, @github + a database tool + a browser tool) and flip the whole set on or off per task. Fewer tools in play = a more focused, cheaper agent.
A real one-liner that uses all three
/tests #selection — and follow the patterns in #file:tests/conftest.py
08
The files in §2 are the setup. This is the cockpit — the windows, sessions, and switches you click while the work happens. VS Code gives you two surfaces for the same underlying sessions, so you can move between them freely.
The normal VS Code. You're writing code; the AI helps alongside the editor, debugger, and extensions. Chat lives in a side panel. Best for hands-on work where you're in the files yourself.
An agent-first screen you open with Open in Agents in the title bar. You think in prompts and run several agents across projects at once. Best for orchestrating rather than typing code.
Both surfaces share the same sessions. A session you start in the Agents window is instantly there in the editor window, and vice-versa — they're the same thing seen two ways.
Each task runs as a session — a conversation you can pause, resume, or hand off. The green/red numbers are the running diff: lines added vs removed so far. Forking a session branches off a copy so you can try a different direction without losing the original thread.
| Type | Runs where | Reach for it when… |
|---|---|---|
| Local | in the editor loop, live | you want to watch and steer every step, with full tool access |
| Copilot CLI | background, on your machine | you want a job done while you keep working — optionally isolated in a Git worktree |
| Cloud | on GitHub's servers | you want it to open a pull request and hand off to the team |
When you start a CLI session, you pick how its edits land:
Rule of thumb: anything experimental or long-running → Worktree. A quick, supervised tweak → Workspace. Worktree mode needs the folder to be a Git repo.
Open it with Chat: Open Customizations (command palette) or the gear in the chat. It's the single dashboard for everything in §2 — Agents Skills Instructions Prompts Hooks MCP Servers Plugins — with counts next to each. Your own live under Workspace; Copilot's ship under Built-In; anything from an installed Plugin appears right alongside. The Generate Skill button scaffolds a fresh SKILL.md for you, and the model selector at the bottom sets the brain, reasoning effort, and context size for that session.
A little layout work makes the whole thing calmer to use, especially on a wide screen:
Prefer the terminal? Everything above also runs as a plain command-line agent — the same sessions, skills, and hooks, just from a shell. The editor and the CLI are two doors into one room.
09
There's a menu of "models" — different AI brains. Smarter ones cost more credits; faster ones are cheaper. Pick the brain to match the job.
The shortcut to remember: Claude (Opus/Sonnet) tends to win on tough thinking and clean code; GPT/Codex tends to win on long, multi-step automated jobs. Match the brain to the shape of the work, not the brand.
On a work account? Each brain has to be switched on by your admin before it shows up in the menu. If Opus 4.8 is missing, that's almost always a policy toggle — ask your Copilot admin, it's not broken.
10
/init. Creates your first house-rules file automatically./create-prompt, /create-agent, /create-skill, /create-hook — just describe what you want.11
Here's the composed kit — the structure from the lessons above, fully fleshed out. Every piece sits on a path Copilot actually scans, and each one has a distinct job. Copy the shape and fill in your own details.
your-project/ .github/ copilot-instructions.md # small always-on constitution instructions/ # scoped rules — fire by file glob coding-style.instructions.md # applyTo: "**" architecture.instructions.md # applyTo: "src/**" testing-policy.instructions.md # applyTo: "**/*.test.*" docs.instructions.md # applyTo: "**/*.md" prompts/ # one-command workflows (/name) review-code.prompt.md generate-tests.prompt.md explain-module.prompt.md refactor-safely.prompt.md debug-issue.prompt.md agents/ # personas, wired with handoffs reviewer.agent.md # checks a change by severity debugger.agent.md # isolates failures, finds root cause implementer.agent.md # builds an approved design documenter.agent.md # writes / updates the docs architect.agent.md # plans first (handoff → implementer) skills/ # deep procedures, loaded on demand code-review/ SKILL.md # L1 metadata + L2 instructions references/ # L3 — read when needed scripts/ # L3 — run, not read test-generation/ SKILL.md references/ scripts/ safe-refactor/ SKILL.md references/ scripts/ documentation/ SKILL.md references/ scripts/ debugging/ SKILL.md references/ scripts/ hooks/ # guarantees, not suggestions format.json # tidy code after edits safety.json # block dangerous commands AGENTS.md # welcome guide for any AI tool
Notice the discipline behind it: the review idea shows up as a prompt (review-code), an agent (reviewer), and a skill (code-review) — but each plays a different role (trigger → persona → procedure), not three copies of the same checklist. Add an assets/ folder inside any skill that needs templates or data files.
A sensible first day: don't build all of this at once. Run /init, write a short AGENTS.md, add one format.json hook, and one safety.json hook. That alone makes Copilot dramatically more reliable. Everything else above you add when you feel the need.
↓ Download a working version of this kit: copilot-customization-kit.zip — mail-safe wrapper; see RESTORE.txt inside for the one-line rename that re-activates the hook scripts.
↓ A larger worked example — five skills together: proposal-studio-kit.zip — a proposal-writing kit (structure, ROI, docx builder, block diagrams, honest review), ready to drop into a project.
12
A tidy folder is not the same as a working setup. These are the five lessons that separate a structure that looks right from one Copilot actually uses. Each one cost someone a confused afternoon.
A folder is only "customization" if it sits on a path Copilot scans. The most common mistake is inventing a clean-looking root like .copilot/ at the top of the repo — it's never read, so your agents and skills silently vanish.
.copilot/agents/reviewer.agent.md # ✗ repo-level .copilot is NOT scanned .github/agents/reviewer.agent.md # ✓ discovered automatically ~/.copilot/agents/reviewer.agent.md # ✓ but PERSONAL (your home dir), not the repo
The recognized repo-level roots are .github/, .claude/, and .agents/. Anything under ~/ (your home folder) is personal and follows you across projects, not shipped with the code. If you truly need an extra folder, register it explicitly with a setting rather than hoping:
"chat.agentFilesLocations": { ".github/agents/atlas": true }, "chat.promptFilesLocations": { "prompts/ops": true }, "chat.agentSkillsLocations": { "skills/shared": true }
Rule: repo assets → .github/. Personal assets → ~/.copilot/. Everything else → register it in settings. Don't invent a repo-level .copilot/ — it's the one that looks official and does nothing.
A folder of background docs — a glossary, an architecture write-up, a "domain pack" — does nothing on its own. Copilot only loads the recognized primitives (instructions, prompts, agents, skills, hooks). Loose Markdown is just files on disk until something points at it.
And don't solve it by making everything an always-on instruction — that re-reads the whole thing on every request and burns context you wanted for the task. A glossary is occasional knowledge, so load it on demand:
# ✗ always-on: re-read every single request, even when irrelevant .github/instructions/project-glossary.instructions.md (applyTo: "**") # ✓ on-demand: a skill that loads only when the topic comes up .github/skills/glossary/SKILL.md # ✓ or a plain reference, explicitly linked from something that IS loaded .github/reference/glossary.md # ...referenced by a Markdown link inside copilot-instructions.md or an agent
The split: rules that should always hold → instructions. Knowledge you occasionally need → a skill or a linked reference. Never put a big body of passive knowledge on an always-on path.
A scoped instruction attaches only when a file matching its applyTo glob is in context. That's the feature — and the trap. Here are three sensible headers:
coding-style.instructions.md — broad
--- applyTo: "**" --- Use snake_case for files and functions. Prefer named exports.
testing-policy.instructions.md — only test files
--- applyTo: "**/*.test.*, **/*.spec.*, tests/**" --- Every new behaviour gets a test in the same change. Use pytest; no network in unit tests.
architecture.instructions.md — only source
--- applyTo: "src/**" --- Domain logic stays out of controllers. No cross-module imports except through the public index.
The timing trap: that architecture rule will not attach during a planning turn, when no src/ file is open yet — exactly when architecture matters most. If a constraint must hold while planning, put it in the always-on copilot-instructions.md, or link the architecture reference from your Architect agent so it loads whenever that agent runs.
Five separate agents in a folder are five things you switch between by hand. The handoffs block turns them into a pipeline: when one finishes, a button appears that opens the next agent with a pre-filled prompt and the context carried over. Here's a real Architect → Implementer → Reviewer loop.
.github/agents/architect.agent.md
--- description: Designs the approach before any code — structure, patterns, risks. Makes no edits. name: Architect tools: ['search/codebase', 'search/usages', 'web/fetch'] model: ['Claude Opus 4.8', 'GPT-5.5'] # tries in order handoffs: - label: Implement this design agent: Implementer prompt: Implement the architecture above, phase by phase. send: false # pre-fill, but wait for me to hit enter --- Read the relevant files first. Identify existing patterns before proposing new ones. Produce: overview, components, data flow, risks. Do NOT edit code.
.github/agents/implementer.agent.md
--- description: Writes code for an approved design, in small phases, following project conventions. name: Implementer tools: ['edit', 'runCommands', 'search/codebase'] handoffs: - label: Review this change agent: Reviewer prompt: Review the implementation above, grouped by severity. send: false --- Work phase by phase. Run the tests after each phase. Stop and report if a phase fails twice.
.github/agents/reviewer.agent.md
--- description: Reviews a change for bugs, security, and test coverage. Read-only. Reports by severity. name: Reviewer tools: ['search/codebase', 'search/usages'] handoffs: - label: Fix the findings agent: Implementer prompt: Address the review findings above, blockers first. send: false - label: Document the change agent: Documenter prompt: Update docs for the reviewed change above. send: false --- Read-only — never edit. Group findings: blocker / major / minor, each with file:line and a one-line fix.
That's a closed loop: Architect plans → Implementer builds → Reviewer checks → back to Implementer for fixes, or on to Documenter. Each step is a button you press, so you stay in control of the chain.
Two details that matter: send: false pre-fills the next prompt but waits for your enter (use true only when you trust the step to auto-run). And pick exact tools ids from the chat's Configure tools… dialog — the names depend on your extensions and MCP servers, so don't copy them blind.
It's tempting to make a review-code.prompt.md, a reviewer.agent.md, and a code-review/SKILL.md that all say "check for bugs, style, tests, security." That's three copies of one idea — pure maintenance debt. Give each layer a job only it can do:
review-code.prompt.md # the TRIGGER "Run a code review using the Reviewer agent and summarize findings by severity." reviewer.agent.md # the PERSONA + boundary Read-only role, allowed tools, output format, review discipline. code-review/SKILL.md # the PROCEDURE The detailed checklist, scripts, examples, and references it follows.
One last thing that quietly decides whether any of this works: the description line. It's not a comment — it's the text Copilot reads to decide whether to load this thing at all. Make it specific.
# ✗ never loads at the right time description: Helps with code # ✓ Copilot knows exactly when to reach for it description: Reviews authentication changes for security vulnerabilities and authorization bugs
The whole lesson in one line: organizing files is putting them in folders; composing is making each one discoverable, single-purpose, and wired to the next. The second is the part that pays off.
13
Handoffs (§12) chain agents together with you as the conductor — click, review, click. The next step up is letting one agent conduct the others. You don't need an outside framework (LangGraph, CrewAI); VS Code has this built in, and your specialist agents are exactly the pieces it coordinates.
Sequential and human-in-the-loop. An agent finishes, a button appears, you click to pass control with context carried over. Cheap, predictable, great for approval gates on dependent steps. (This is what §12 wired.)
Autonomous and context-isolated. A coordinator runs a specialist in its own context window and gets back only the result. Independent subagents run in parallel. This is the actual multi-agent engine.
A coordinator is just an agent with two extra bits of frontmatter and one setting:
# .github/agents/review-board.agent.md --- name: "Review Board" tools: ["agent", "search", "codebase"] # the "agent" tool enables delegation agents: ["Reviewer", "Performance Profiler", "Database Expert"] # allowlist, by DISPLAY NAME model: "Claude Opus 4.8" --- Run each lens as a subagent, in parallel, READ-ONLY. Then merge by severity.
Plus one setting (VS Code 1.120+):
"chat.customAgentInSubagent.enabled": true
Two identifier conventions — don't mix them up: handoffs.agent targets by id (the filename stem, e.g. implementer), but the agents: subagent allowlist targets by display name ("Implementer"). A button that appears but won't route is almost always this.
The one hard rule — parallel means read-only. Subagents share a single working tree, so only one agent may write at a time. Parallel fan-outs must report, never edit; writing is confined to a sequential step. Two agents editing the same files at once will clobber each other.
| Situation | Use |
|---|---|
| Dependent steps, you want to approve each | Handoffs (or Plan mode) |
| Independent lenses / parallel analysis | Subagents (a coordinator) |
| Heavy research that shouldn't pollute context | Subagents, or built-in /research |
| A single quick, supervised task | Just one agent |
Cost & reality check: subagents spend more premium requests and add latency on small jobs. They pay off when work is genuinely parallelizable or context-heavy. Start with one coordinator (a parallel review board), prove it earns its keep, then expand. They require a Copilot plan that allows agents; an org admin can switch them off, so if a coordinator silently won't spawn workers, check policy before debugging your YAML.
14
15
16