Part 3 — GitHub Copilot, in depth

If you read Part 2, you know the Claude Code side of the harness. Copilot’s system has the same seven primitives — but different surface area, different governance controls, and a few sharp edges that will catch you if you don’t know about them. This section maps the whole thing.

Q3.1 — How does Copilot's instruction file hierarchy work?

Copilot has the most flexible instruction system of any agent in 2026, with several layers:

• .github/copilot-instructions.md — repository-wide, always applied.
• .github/instructions/**/*.instructions.md — path-scoped files. Each carries an applyTo glob in its frontmatter, so a rule can target only certain files. This works for the Copilot cloud agent, code review, and IDE chat in VS Code / Visual Studio.
• AGENTS.md — supported at the repo root and in nested folders. This is the cross-vendor standard (covered in Part 5).
• Org-level custom instructions — set in the GitHub UI, applied across all repos.

Priority is Personal > Repository > Organization.

---
applyTo: "internal/payments/**/*.go"
---
- All monetary values are int64 minor units; never floats.
- Every transaction mutation must call audit.Emit().
- New payment endpoints require sign-off from the payments team.

One sharp edge: Copilot code review only reads the first 4,000 characters of an instruction file. The coding agent and Chat have no such limit, but if you care about code-review behavior, front-load the important rules.

Q3.2 — What are Copilot custom agents and how do they compare to Claude subagents?

Custom agents went GA across Copilot surfaces during 2026. You define them in .github/agents/<name>.agent.md (project scope) or ~/.copilot/agents/<name>.agent.md (user scope). Organization- and enterprise-wide custom agents live in a special .github-private repository and become available across all repos.

---
name: security-scout
description: Reviews PRs for security regressions in auth and payment paths.
tools: [codebase, search, problems]
model: claude-4.7-sonnet
---
You review diffs only. Report severity, location, risk, and fix.
Escalate any hard-coded secret as CRITICAL.

Agents are invoked via @-mention (@security-scout), the agent picker, /agent in Copilot CLI, or by assigning the agent to a GitHub issue (which kicks off the cloud coding agent).

Compared to Claude subagents: the concept is the same — scoped persona, scoped tools, chosen model. The differences are surface and frontmatter schema. Claude subagents are deeply integrated into an interactive pipeline with context forking; Copilot custom agents shine when assigned to issues for autonomous, asynchronous work. In the common harness you’ll keep one shared prompt body and two thin frontmatter wrappers.

Q3.3 — What are prompt files and chat modes?

These are the lower-level building blocks beneath custom agents:

• .github/prompts/*.prompt.md — reusable, invokable prompts. They show up as slash commands in the IDE. Good for repeatable chores like scaffolding a new service module per your template.
• .github/chatmodes/*.chatmode.md — persona definitions with a tools: array (codebase, search, usages, problems, runCommands, runTasks, findTestFiles, etc.). They change how Chat behaves for a working session.

Both are supported in VS Code, Visual Studio, and JetBrains. In harness terms, prompt files map roughly to Claude slash commands, and chat modes map roughly to a subagent’s persona and first-message behavior.

Q3.4 — How does MCP work in Copilot, and how do I govern it?

Copilot supports MCP across local stdio servers, remote HTTP (Streamable), and the older SSE transport. Configuration lives in ~/.copilot/mcp-config.json (CLI), .vscode/mcp.json (workspace), or the GitHub MCP Registry / VS Code MCP gallery. The remote GitHub MCP server is built into Copilot CLI and the cloud agent.

Governance is via the MCP servers in Copilot organization/enterprise policy. It’s disabled by default and applies only to Business/Enterprise plans. Admins specify a registry URL allowlist and can enforce “Registry only.”

Important honesty from GitHub’s own Well-Architected guidance: registry enforcement matches on server name, can be bypassed, and does not apply to the cloud agent. Treat it as a governance signal and an IDE discoverability layer — not a hard security boundary. For a real boundary, run MCP servers behind a controlled gateway you operate.

Q3.5 — How does Copilot's automated code review work?

Copilot code review is the AI-review automation layer. You customize it with the same instruction files as everything else — .github/copilot-instructions.md repo-wide, .github/instructions/**/*.instructions.md path-scoped.

You make it automatic through repository rulesets: enable “Automatically request Copilot code review”, with sub-options “Review new pushes” and “Review draft pull requests.” The AI review is non-blocking by design — it’s an extra reviewer, not a gate.

Two operational notes to plan for:

• From June 1, 2026, Copilot code-review runs consume GitHub Actions minutes.
• Copilot Autofix (for Code Scanning alerts) is a separate, security-targeted system that ships with GitHub Advanced Security — it’s not the same thing as code review.

Q3.6 — What are GitHub Agentic Workflows, and are they the same as Claude hooks?

GitHub Agentic Workflows (gh-aw), in technical preview since February 2026, are the event-driven automation substrate for Copilot. You write a workflow in natural-language Markdown and the gh-aw compiler turns it into a hardened, locked GitHub Actions workflow (.lock.yml).

They are read-only by default.Any write operation goes through “safe outputs” — sanitized, declarative operations like add-comment or create-pull-request with hard limits. There are five security layers: a read-only token to the agent, secrets isolated into post-agent jobs, a network firewall (a Squid proxy with a domain allowlist), a containerized per-server MCP gateway, and a trusted compiler that pins actions to SHAs and runs linters (actionlint, zizmor, shellcheck, poutine). Always compile with gh aw compile --strict.

Are they the same as Claude hooks? No — they’re complementary. Claude hooks run inside the agent loop, per tool call, in the developer’s interactive session — they’re inner-loop gates. Agentic Workflows run as standard CI jobs triggered by GitHub events (issue opened, PR pushed, schedule) — they’re outer-loop automation.

In the common harness: Claude hooks enforce per-edit policy on the developer’s machine; Agentic Workflows handle repo-wide autonomous chores. A typical starter set: auto-triage-issues.md, security-guard.md, docs-sync.md, agents-md-maintainer.md, dependency-update.md.

Q3.7 — What are GitHub Enterprise AI Controls?

Enterprise AI Controls and the “agent control plane” reached general availability on February 26, 2026. It’s a suite giving enterprise admins deeper control and greater auditability over AI agents in the platform.

Concretely, you get:

• Audit-log fields that distinguish agent activity: actor_is_agent, plus user/user_id, and an agent_session.task event.
• An agents page whose audit log auto-prefilters Copilot and third-party agents.
• Session visibility beyond the old 1,000-record limit (all sessions in the last 24 hours).

GitHub’s Well-Architected “Governing agents in GitHub Enterprise” guidance (April 2026) maps these into SIEM detections — for example, git.push combined with actor_is_agent to monitor high-risk files, copilot.mcp_* events for MCP policy changes, and repository_ruleset.* with actor_is_agent to catch bypass attempts.

One caveat to design around: the MCP enterprise allowlist remained in public preview even at the broader GA. Don’t make it load-bearing without a fallback.