AI Agents + GitHub

Everything before this cluster has a human in the loop while the work happens. Chat suggests and you type. Agent mode edits and you approve. The CLI runs a command and you watched it ask.

Delegation removes that. You describe a task, something else does it, and you see the result. The controls move from supervision during to scope before and review after — and getting those two right is the entire content of this cluster.

Start with AI Coding Agents Explained

What changes when nobody is watching

Three things, and they are the reason this cluster is the most demanding one.

Permissions become the primary control. With a human approving each step, an over-broad permission is caught by the human. Without one, the permission is the boundary.

Untrusted input becomes reachable. A delegated agent reads issues, comments, pull request descriptions and repository content. Anyone who can open an issue can write text an agent will read.

Auditability stops being optional. “What did it do and why” is a question you will be asked, and the answer has to come from logs, commits and a pull request rather than from anyone’s memory of watching.

The good news is that GitHub’s model is well shaped for this: the agent works on a branch, in an isolated environment, and returns a pull request. That means the output enters your process at exactly the point your process already inspects things.

The delegation loop

Delegated work, from task to merge

A vertical chain: issue or task, agent assignment, isolated environment, repository analysis, plan, code changes, tests, pull request, AI review, human review, repository policy, merge.

Read the last four stages: they are identical to the ones a human contribution goes through. That is the design. An agent’s output is a pull request, and a pull request is a thing your repository already knows how to be sceptical about.

The surfaces

Surface	Runs	Supervision	Output
Agent mode	Your workspace	Continuous, you approve	Local edits
Copilot CLI	Your terminal	Continuous, you approve	Local edits, commands
Copilot cloud agent	GitHub-hosted environment	None during; review after	A branch and a pull request

GitHub’s documentation is explicit that the cloud agent “is distinct from the agent mode feature available in your IDE” — it works autonomously in a GitHub Actions-powered environment on tasks assigned through issues or Copilot Chat, while agent mode “makes autonomous edits directly in your local development environment”.

This cluster is mostly about the third row. Copilot Cloud Agent covers it in full.

The lessons

1. 01Lesson 1: 01. AI Coding Agents ExplainedWhat a software-development agent actually is — the loop, the boundaries, how the three GitHub Copilot agent surfaces differ, and the engineering conditions under which delegation works.Intermediate13 min read
2. 02Lesson 2: 02. The Copilot Cloud AgentDelegating work to the GitHub-hosted Copilot coding agent — assignment, the ephemeral environment, its documented limits, permissions.Advanced16 min read
3. 03Lesson 3: 03. Repository Agent ConfigurationConfiguring agents at the repository level — AGENTS.md, custom agent definitions in .github/agents/, scoped tool lists, hooks that enforce rather than suggest, and how the layers combine.Advanced15 min read
4. 04Lesson 4: 04. Reviewing Agent Pull RequestsHow to review a pull request nobody watched being written — the reading order, the failure modes to check for, why green CI carries less information, and where accountability sits.Advanced14 min read
5. 05Lesson 5: 05. Agentic CI/CDWhere AI belongs in a delivery pipeline and where it must not — advisory analysis versus blocking gates, running agents in Actions with scoped permissions.Advanced15 min read
6. 06Lesson 6: 06. The GitHub MCP ServerGiving agents access to GitHub through Model Context Protocol — what the server exposes, read-only mode, lockdown, toolset scoping, the untrusted-content trust model and where the real boundary sits.Advanced16 min read
7. 07Lesson 7: 07. Agent SkillsPackaging reusable capability for agents — the SKILL.md format, required frontmatter, allowed-tools scoping, when a skill beats an instruction, and distributing skills across a team.Advanced14 min read
8. 08Lesson 8: 08. Issue to Pull RequestWriting issues that produce good delegated work — the components of a delegable task, issue templates for agent assignment, what to keep for humans.Intermediate14 min read
9. 09Lesson 9: 09. Repository Maintenance AgentsScheduled agents for the work nobody prioritises — dependency updates, documentation drift, dead code, test coverage and stale configuration.Advanced14 min read
10. 10Lesson 10: 10. AI Release EngineeringUsing AI across the release cycle — change summaries, risk surfacing, release notes, upgrade guides and incident timelines — while every gate that decides whether to ship stays deterministic.Advanced15 min read

Lesson 1 defines what an agent actually is, which is worth doing before deciding what to let one do. Lesson 2 covers the cloud agent specifically. Lesson 3 is repository configuration — agents, skills, hooks and the permission boundaries around them. Lesson 4 covers what an agent-authored pull request needs from review. Lesson 5 applies agents to CI/CD, carefully. Lesson 6 is MCP, the cornerstone for external tools. Lesson 7 covers skills. Lessons 8 and 9 are the end-to-end workflows — issue-to-PR and ongoing maintenance. Lesson 10 closes the pillar with release engineering, which pulls together Pillars 3, 4 and 5.

What makes a task delegable

The single best predictor of whether delegation works is not the model’s capability. It is whether the task can be judged without having watched it.

Good candidates share three properties:

Clear acceptance criteria. “The failing test in auth_test.go passes and no other test breaks” is judgeable. “Improve the auth module” is not.

Bounded scope. One repository, a known set of files, no ambiguity about whether a related system should also change.

Cheap verification. Tests that cover the area, a CI pipeline that runs, a diff a reviewer can read in ten minutes.

Poor candidates are the mirror image. Exploratory debugging where the goal shifts as you learn. Refactors whose right shape emerges from doing them. Anything where the hard part is deciding what to build rather than building it. Changes whose correctness depends on knowledge that exists in somebody’s head rather than in the repository.

The useful test before delegating: write down how you will decide whether the result is acceptable. If you cannot, the task is not ready — and that is a finding about the task rather than about the agent. It is also, not coincidentally, the same test that distinguishes a good issue from a bad one.

The maintenance question nobody asks first

Delegation produces pull requests, and pull requests need reviewers. That arithmetic is worth doing before scaling anything up.

An agent that can produce six pull requests a day on a team that reviews four is not a productivity gain; it is a queue. And a review queue under pressure is precisely the condition under which review gets lighter — which removes the control that made delegation safe in the first place.

Practical consequences:

Start with work that reduces review load rather than adding to it. A dependency bump somebody was going to do anyway is net positive. Speculative refactors are not.

Batch where batching is honest. Ten formatting fixes in one pull request is one review. Ten unrelated changes in one pull request is one review that misses things.

Watch the ratio. Agent pull requests merged versus opened, and time-to-review. Both falling is the signal that you have exceeded the team’s capacity to supervise.

Bound the volume deliberately. Autonomous maintenance covers rate limits and change-size limits as first-class guardrails, because “how much can it produce” is a control alongside “what can it touch”.

The security architecture

The shape that makes delegation defensible. Every element is something the previous five pillars already taught.

AI agent
   ↓  scoped permissions        — least privilege, no standing production credentials
   ↓  repository instructions   — what it should do
   ↓  tool restrictions         — what it can do
   ↓  isolated branch/environment — where mistakes are contained
   ↓  tests                     — the first thing that can say no
   ↓  security scans            — code scanning, dependency review, secret scanning
   ↓  pull request              — the reviewable artefact
   ↓  human review              — the accountable layer
   ↓  ruleset                   — what actually decides the merge

Two lines are worth dwelling on.

Tool restrictions are separate from instructions. Instructions say what an agent should do and are followed probabilistically. Tool restrictions and hooks say what it can do and are enforced. When something must not happen, it belongs in the second category.

The ruleset is the last word. Not the agent’s confidence, not the AI review, not the passing tests. Rulesets are the mechanism that decides what reaches your default branch, and they apply to an agent exactly as they apply to a person.

Architectures to refuse

Some configurations are not a trade-off; they are a mistake with an explanation attached.

• Unreviewed write access to the default branch. Delegation’s whole safety property is that output arrives as a pull request.
• Standing production credentials. No task in this cluster requires them.
• Broad cloud credentials in an agent environment. Scope to the task, expire quickly, prefer OIDC.
• Organisation-admin permissions. An agent that can change repository settings can change the rules meant to constrain it.
• Write-capable MCP tools connected because they were available. Each one expands what a compromised or misled agent can do.

Where an advanced scenario genuinely needs something on this list, the justification belongs in writing, next to the configuration.

Availability

Copilot cloud agent is available on paid Copilot plans, and administrators must enable it for Business and Enterprise. Agent skills, hooks, plugins and MCP have their own availability and preview status, which differ by surface. Confirm the current position in the Copilot cloud agent documentation.

Prerequisites

Before you start

• The Copilot CLI cluster — the permission model, at a smaller scale
• GitHub Actions — the cloud agent’s execution environment
• Least-privilege GitHub access — the identity model
• Repository rulesets for security — the enforcement layer
• Secure release pipelines — assumed by lesson 10

This is the most demanding cluster on the site. It assumes you can reason about permissions, read a workflow file, and evaluate a pull request you did not write.

Common mistakes

Delegating an underspecified task. An agent will produce a confident answer to whatever it thinks you asked. Acceptance criteria are the difference between delegation and a lottery.

Reviewing agent pull requests more lightly than human ones. The reasoning tends to be “the tests passed” — which was equally true of every human pull request that broke production.

Letting instructions do a permission’s job. “Do not modify the deployment configuration” is a suggestion. A tool restriction is a control.

Connecting MCP tools speculatively. Each connected tool is capability and attack surface at once.

Forgetting that issue text is untrusted. Anyone who can open an issue can write text a privileged agent will read.

Skipping CI because the agent ran the tests. The agent’s report is a claim; the CI run is evidence.

Scaling up before one workflow works. One well-scoped, well-reviewed delegated task teaches you more than ten simultaneous ones.

After this cluster

This is the final cluster of Pillar 6 and the end of the current curriculum — from what Git is, through how teams use it, to how AI participates in that work without weakening it.

Back to the AI Engineering overview