Agentic Foundations

Assistant versus agent

Most developers first meet AI in the assistant pattern: it responds to a prompt, produces output, and hands control back. An agent goes further. It holds a goal across multiple steps, decides the intermediate steps itself, uses tools, and changes durable artifacts — branches, commits, pull requests — iterating on feedback until the task is done. That shift turns AI from something that helps with development into something that participates in it, and participation is what has to be governed.

In GitHub, agent behaviour shows up in exactly the places developers already look: branches and commits (what changed), pull requests (what is proposed and why), workflows and checks (what evidence exists) and reviews (what humans accepted). An agent does not replace the workflow — it enters the workflow as a participant.

The plan → act → evaluate lifecycle

Agents do not make one decision and stop; they run a loop until the task meets its success criteria or is handed to a person. Each phase has a GitHub-native home, and a well-designed system makes all three phases visible.

flowchart TB
  GOAL["Goal<br/>issue · prompt · alert"] --> PLAN["Plan<br/>scope · steps · success criteria"]
  PLAN --> ACT["Act<br/>branch · commits · pull request"]
  ACT --> EVAL["Evaluate<br/>checks · scans · reviews"]
  EVAL -->|"criteria met"| DONE["Accept<br/>merge or hand off"]
  EVAL -.->|"same failure twice"| HUMAN["Escalate<br/>to a human"]
  EVAL -->|"checks fail"| PLAN

Plan

The agent interprets the goal and decides the steps. In a good system the plan is a reviewable artifact — a plan section in the pull request, a checklist in the issue, a plan.md — not a hidden internal state. Plans become reviewable when they state scope, success criteria, and a rollback or escalation path.

Act

The agent executes in the repository: creates a branch, changes files, pushes commits, opens or updates a pull request, responds to review feedback. Execution stays bounded: one repository, one branch, through pull requests — never uncontrolled writes to the default branch.

Evaluate

The agent and its supervisors judge the result with system signals: workflow runs and status checks, review outcomes, code scanning, secret scanning, dependency alerts. With rulesets or branch protection, required checks turn evaluation into an enforceable gate rather than a suggestion.

GitHub as system of record and control plane

The course's central idea is that GitHub plays two roles at once. As the system of record it stores every artifact through which work is proposed and judged — repositories, branches, commits, pull requests, issues, discussions, workflow runs, uploaded artifacts and review history — so agent behaviour can be inspected after the fact. As the control plane it provides the enforcement points that decide what an agent's contribution can and cannot do.

A typical agent pull request moves through the control plane like this:

1. The agent opens a pull request with its change and plan, making the work visible.
2. CODEOWNERS requests review from the owners of every sensitive path it touched.
3. Required workflows and scans run and report status checks.
4. The ruleset blocks merge until checks pass and approvals are in.
5. If the change deploys, an environment with required reviewers pauses the deploy job — and its secrets — until someone approves.

# .github/pull_request_template.md — gives every agent PR the same reviewable shape
## Plan (required)
- **Goal:**
- **Scope (paths):**
- **Steps:**
- **Success criteria:**
- **Rollback / escalation:**

## Evidence
- Workflow run:
- Scan results:

Accountability and the contributor model

Responsibility does not move with execution

An agent can create a pull request, revise code and answer feedback, but it does not own the outcome. The people and teams who defined the task, set the permissions, chose the controls and approved the change remain accountable. GitHub encodes this: Copilot cloud agent's commits are authored by Copilot with the person who assigned the task as co-author, and that person cannot approve the resulting pull request.

The minimum audit trail

For every agent contribution you should be able to reconstruct:

• A stated goal — the issue link or PR description.
• An inspectable plan — plan section or file.
• A bounded changeset — one branch, scoped commits.
• Automated evidence — workflow runs and uploaded artifacts.
• Human judgement — reviews and approvals.
• A clear outcome — merge, revert, or escalation.

The contributor model

The most reliable way to judge agent output is to stop treating it as categorically different: treat it as a contribution. A pull request answers the same questions whoever wrote it. The model avoids two opposite errors — excessive suspicion (rejecting work because an AI wrote it) and excessive trust (accepting it because automation produced it).

A well-supervised agent contribution is understandable, bounded, reviewable, policy-compliant and reconstructable. That is not a special standard for AI — it is the standard of a healthy engineering workflow, applied consistently.

Where Copilot agents run

"The agent" in an exam question can mean several different products, and each has a different execution context, trigger and governance boundary. Placing the scenario on the right surface is often half the answer.

flowchart TB
  subgraph GH["Runs on GitHub"]
    direction LR
    CCA["Copilot cloud agent<br/>Actions-powered sandbox"]
    AUTO["Automations<br/>scheduled or event-triggered cloud agent"]
    GHAW["GitHub Agentic Workflows<br/>markdown compiled to Actions"]
    TPA["Third-party agents<br/>Claude · Codex"]
  end
  subgraph LOCAL["Runs on your machine"]
    direction LR
    CLI["Copilot CLI<br/>interactive · -p · autopilot"]
    IDE["Agent mode in the IDE<br/>VS Code · JetBrains · Visual Studio"]
    SDK["Copilot SDK<br/>your app embeds the agent runtime"]
  end

The customization stack

Copilot's behaviour is shaped by several layers, each stored in a predictable place. The layers differ in one way that matters more than any other on this exam: whether they guide the model or enforce a boundary.

flowchart TB
  subgraph ENF["Enforcement — the platform blocks"]
    subgraph SHAPE["Capability — what it can attempt"]
      subgraph GUIDE["Guidance — what the agent is told"]
        INS["Custom instructions<br/>copilot-instructions.md · AGENTS.md"]
        AGP["Custom agent prompt<br/>.github/agents/*.agent.md"]
        SKL["Skills<br/>.github/skills/*/SKILL.md"]
      end
      TL["Tool allowlists<br/>tools: · --allow-tool · MCP tools"]
      ENV["Environment<br/>setup steps · firewall · Agents secrets"]
    end
    HK["Hooks<br/>preToolUse can deny"]
    RS["Rulesets · CODEOWNERS<br/>required checks · environments"]
  end
  INS ~~~ TL
  SKL ~~~ ENV
  TL ~~~ HK
  ENV ~~~ RS

Renames and naming traps

The GitHub agent platform moved fast during 2025–2026. The exam and the live documentation use the current names, but Learn modules, blog posts and third-party material still carry older ones.

Glossary

Agent profile

A Markdown file with YAML frontmatter (name, description, tools, mcp-servers…) that defines a custom agent.

Agent session

One interaction with an agent on a task — the unit you monitor, steer, stop, archive and audit.

Control plane

The set of GitHub enforcement points — rulesets, checks, CODEOWNERS, environments, permissions — that decide what agent work is accepted.

Execution context

Repository, branch, workflow and permissions an agent runs under. It determines both what it can see and what it can do.

MCP (Model Context Protocol)

An open standard for connecting AI clients to tools through MCP servers. Registries catalogue servers; allowlists decide which may run.

Safe outputs

In GitHub Agentic Workflows, the declared set of write operations (create issue, add comment, open PR) that a separate, gated job may perform on the agent's behalf.

Subagent

An agent spawned by a main agent to handle a subtask in its own context window, optionally in parallel.

System of record

The durable store of intent, action and evidence — for agent work, GitHub issues, PRs, commits, runs and reviews.