Back on the build site. A robot showed up to work (lesson 1.6) — but a robot doesn't just wander onto the job. It arrives with a spec sheet: one card saying who this unit is, which model brain it runs, which tools it may pick up, and which jobs it may take. That spec sheet is the agent file. Change one line — add "power saw" to its tool list — and you've changed what the machine can do to your building. That's why swapping a tool is a sign-off event, not a casual edit.
And the site office has a wall of binders, each in its own labeled slot: the house rulebook every worker reads (repo instructions), a per-room rulebook for the kitchen only (path-specific instructions), the robot spec sheets themselves (agent profiles), and a standard job-request form every work order must use (the PR template). File a sheet in the wrong slot and nobody reads it — so the exam tests whether you know exactly which slot each binder goes in.
Last rule, the most important: no robot starts cutting until its written plan is signed. It drafts the plan, sets down its tools, and waits. A human (or an automated gate) signs off — then the tools switch on. That's plan→validate→gate, enforced by a checkpoint at the office door, not by asking nicely.
Part 1 · Where the files live (the path map)
Memorize-cold. Each path is a binder slot; the exam shows a path and asks "what concept is this?"
| Path | What it is |
|---|---|
.github/agents/*.agent.md (or .md) | Custom agent profile — the spec sheet (role, model, tools, persona) |
/agents/ in a .github-private repo | Org-/enterprise-scoped custom agents |
.github/copilot-instructions.md | Repo-wide instructions (whole repo) |
.github/instructions/*.instructions.md | Path-specific instructions (certain paths only) |
AGENTS.md (repo root) | Agent instructions; nearest one can take precedence (framing) |
.github/pull_request_template.md | The PR template — forces a structured plan + evidence into every PR |
.github/workflows/plan-gate.yml | The plan-gate workflow — fails the PR if no plan section |
CODEOWNERS | Auto-assigns required reviewers by changed path |
.github/prompts/*.prompt.md | Prompt templates (framing) |
.github/skills/<skill>/SKILL.md | Per-skill definition (framing) |
Seeing copilot-instructions.md, *.instructions.md, or AGENTS.md signals "instructions" (how an agent should behave). Seeing .github/agents/*.agent.md signals "agent profile" (what the agent is and may do).
Part 2 · The agent file's YAML frontmatter
A custom agent file is Markdown (plain text with simple symbols for headings, links, lists) with a YAML frontmatter (a small settings block at the very top of the file, fenced by --- lines) and a Markdown body below (the persona/role, in prose).
---
description: Reviews PRs for security issues and posts findings # REQUIRED
name: security-reviewer # optional — display name only
tools: # allowlist of capabilities
- read
- search
mcp-servers: # MCP server config (YAML), if any
sentry:
command: ...
target: github-copilot # surface: github-copilot | vscode
model: gpt-5 # pick a model where supported
disable-model-invocation: true # block auto-invocation by inference
user-invocable: true # can users invoke it directly?
metadata: { team: platform } # extra metadata
---
You are a careful security reviewer. Read the diff, flag risky patterns…
| Key | Required? | What it does |
|---|---|---|
description | ✅ required | The agent's purpose/capability (the #1 trap) |
name | optional | Display name only |
tools | optional* | Allowlist of tools (*behaviour when omitted is the trap) |
mcp-servers | optional | MCP (Model Context Protocol — a standard "plug" that lets an agent connect to outside tools) server config (YAML) inside the agent file |
target | optional | Which surface (github-copilot, vscode) |
model | optional | Pick a model where supported |
disable-model-invocation | optional | Prevent auto-invocation by inference |
user-invocable | optional | Whether users can invoke it directly |
metadata | optional | Extra metadata |
handoffs | — | Exists in some formats but ignored by the Copilot cloud agent |
descriptionis required — NOTname.nameis optional display text.- Omit
toolsentirely → the agent may get ALL tools (the opposite of least-privilege). tools: [](empty list) → ALL tools disabled.tools: ["*"]→ all tools — trusted/sandboxed cases only (framing).handoffsis ignored by the Copilot cloud agent.
Part 3 · The tools list (values + least-privilege)
The tools key takes these values — the same set from 1.6, now as exact config:
| Value | Grants | Notes |
|---|---|---|
read | read file contents | |
search | search the repository | NOT web search |
edit | edit/write files | add only if it must change files |
execute | run shell commands | add only if it must run tests/scripts |
agent | invoke another custom agent | must be listed for agent-to-agent; aliases agent / custom-agent / Task |
web | fetch URLs / web search | not supported in cloud agent today |
todo | task list | not supported in cloud agent today |
Least-privilege is the rule. If the agent only reviews, omit edit; if it never shells out, omit execute. Worked example: an agent with tools: [read, search, agent] can read files, search the repo, and invoke subagents (a subagent is a helper agent that another agent calls to do a sub-task) — but cannot edit files or run shell commands. The capability is exactly the list, nothing implied. MCP tools go alongside: declare the tool in tools (e.g. sentry/get_issue) and configure the server in the mcp-servers block of the same file. This is the capability boundary from 1.6, made literal — and changing the allowlist is a governance-sensitive change (a change risky enough to need extra human review).
Part 4 · Plan → validate → gate (the execution model)
The agent file says what the agent is; this flow controls when it may act. The named exam objective in our words: keep planning separate from doing — the agent produces a plan first, you validate it, and action stays blocked until it's approved.
- Planning agents are read-only —
tools: [read, search], noedit/execute. They literally cannot change files while planning. - Explicit handoff — execution does not start automatically; a deliberate step (approval, merge) moves plan → implementation.
- Tool gating — the orchestrator (the lead agent that coordinates the other agents) disables execution tools during planning, enabling them only once the plan is accepted. ("Plan mode" = generate a plan and stop.)
Agents should NOT act immediately after planning. Action is blocked until the plan is validated/approved. "A plan was produced" ≠ "the plan was approved."
How the plan becomes enforceable (not just hoped-for):
| Mechanism | File / setting | What it enforces |
|---|---|---|
| Plan artifact | PR body, or .github/pull_request_template.md | Every PR carries a structured plan (goal, scope, steps, success criteria, risks, rollback) + evidence |
| Plan gate | .github/workflows/plan-gate.yml | Fails the PR if the plan section is missing |
| Required status check | ruleset / branch protection (admin task) | Upgrades the gate to "PR cannot merge without it" |
| CODEOWNERS | CODEOWNERS | Auto-requests reviewers by path — only blocks if paired with required-review policy |
| Approve-and-run | repo setting | Human must approve before workflows run on an untrusted/agent PR |
| Environment approval | protected environment + reviewers | Job pauses for human approval before secrets / deploy |
The safe agent workflow end-to-end: create branch → open PR with plan → reviews → required checks → wait for all checks and approvals → merge. Use plan-first always for workflows, infrastructure, authentication, and production changes.
"Telling an agent 'don't edit this' is just guidance (easily bypassed). Tool allowlists and gates are the actual enforcement." The agent file's tools list and the required checks are the wall; the prose persona is not.
The cert-language version
A custom agent is a Markdown file with YAML frontmatter at
.github/agents/*.agent.md(org/enterprise:/agents/in.github-private). Required key:description(nameoptional);toolsis an allowlist — omit it → all tools;[]→ none — plusmcp-servers,target,model,disable-model-invocation,user-invocable,metadata(handoffsignored by the cloud agent). Tool values:read,search(repo, not web),edit,execute(shell),agent(invoke subagent; aliasesagent/custom-agent/Task);web/todounsupported in the cloud agent. Instructions are separate —.github/copilot-instructions.md(repo-wide),.github/instructions/*.instructions.md(path-specific),AGENTS.md(root). The execution model keeps planning separate from doing: planners are read-only, the plan is a written artifact (PR body / template), and action is blocked until validated — enforced by a plan-gate workflow made a required status check, CODEOWNERS + required reviews, and environment approvals, never by instruction alone.Our summary · grounded in MS Learn — Designing Agent Architecture & SDLC Integration (units 1, 3–6, 9) + Foundations (unit 4) · gist (Tier-2, verified) · fetched 2026-05-31
Common confusions (read these or lose points)
- "
nameis the required key." No —descriptionis required;nameis optional display text. - "No
toolskey means the agent is locked down." Backwards — omittingtoolsgrants ALL tools. To grant nothing, usetools: []. - "
searchsearches the web." No —searchis repo search;webis the web tool, not available in the cloud agent today. - "Agent A can just call agent B." No — you must list the
agenttool; it isn't automatic. - "
copilot-instructions.mdis the agent profile." No — that's an instructions file. The agent profile is.github/agents/*.agent.md. - "The agent planned, so it can start." No — action is blocked until the plan is validated/approved. A produced plan is not an approved plan.
- "Adding
plan-gate.ymlblocks bad merges." Not by itself — a workflow only enforces once an admin makes it a required status check. Same for CODEOWNERS: it auto-requests reviewers but only blocks when paired with a required-review policy. - (Study guide suggests)
.github/prompts/*.prompt.md,.github/skills/<skill>/SKILL.md, nearest-AGENTS.mdprecedence, and the Lab-1github.head_refcheckout are gist framing — learn the concepts, hold the exact strings loosely.
Ticks this lesson done on the home roadmap. Saved in this browser.