A tradesperson shows up at a building site. Before they pick up a single power tool, ask the simpler question: how do they touch the building at all?
With their hands, and the site's standard equipment — the door, the freight elevator, the loading dock, the work-order clipboard. They don't teleport through walls. They don't cut a secret back entrance. They use the same doors every other worker uses, and the site rules — who's allowed on which floor — apply to them exactly the same.
An AI agent on GitHub is that worker, and its hands are GitHub's APIs and workflows. Before the fancy tools (the rest of Domain 2), see the plain truth: an agent never reaches outside GitHub. It opens the same doors a human developer opens — branches, commits, pull requests — through the same machinery. That's the foundation the whole domain stands on.
The idea, in plain English
Three words first, because the exam leans on them:
- API (Application Programming Interface) — a way for one program to ask another to do something in code instead of by clicking. GitHub's API is how a program (a script, or an agent) can "create a branch" or "open a PR" without a person on the website.
- Workflow — a YAML file that runs a set of jobs when an event happens. (You met this in Phase 0, lesson 0.7. YAML = the indented plain-text settings format.)
- Runner — the throwaway computer GitHub spins up to actually run a workflow's steps.
An agent acts on a repo through three layers — APIs, Actions workflows, and agentic workflows — and all three are the same mechanisms humans already use. The agent gets no special back door: the same permissions and the same audit trail apply automatically.
The three layers (the agent's "hands")
| Layer | What it is | Its job |
|---|---|---|
| GitHub APIs | the direct reach | read repo state + perform actions: create branches/commits, read files, open/update PRs, trigger workflows. The hand that grabs. |
| Actions workflows | the execution layer | run the agent's steps inside a controlled runner — a sandboxed computer with a scoped token. The bounded, logged workbench. |
| Agentic workflows | the orchestration layer | describe agent behavior that runs over time, reacting to repo events. GitHub calls this "Continuous AI" — it extends CI/CD, doesn't replace it. |
All of this runs through the platform's own structures — they apply the same permissions, give the agent a place to run, and route its changes through pull requests. Translation: the same guardrails that govern humans govern the agent automatically — because it's using the same doors. Big for GH-600.
How the hands actually move — the five-step change
When an agent changes code it does nothing exotic. It follows the exact sequence a human follows, and each step is a specific API call:
| # | What happens | Which API area |
|---|---|---|
| 1 | Pick a base branch (e.g. main) | Git references |
| 2 | Create a working branch | Git references |
| 3 | Modify / create files | Repository contents |
| 4 | Commit the changes | Repository contents |
| 5 | Open a pull request | Pull requests |
Same five moves you learned for humans in Phase 0 (branches → commits → PRs). The agent just makes them as API calls instead of clicks.
Three ways a workflow gets kicked off (its trigger types — memorize these):
- Automatic — a repo event fires it (
push,pull_request). - Manual — a person presses a button (
workflow_dispatch). - Programmatic — another program calls the API to start it.
Worked example — the agent's hands, made literal
A minimal Actions workflow that uses the GitHub CLI (gh) to open an issue — exactly the kind of "hand" an agent uses. Every line annotated:
# .github/workflows/file-a-bug.yml ← workflows MUST live here, .yml/.yaml
name: File a bug # label shown in the Actions tab (optional)
on: # WHAT triggers this run …
workflow_dispatch: # … a human pressing "Run" (manual trigger)
permissions: # what the run's token is ALLOWED to do …
issues: write # … least-privilege: only write issues, nothing else
jobs:
open-issue:
runs-on: ubuntu-latest # the throwaway runner (the workbench)
steps:
- uses: actions/checkout@v4 # step 1: download the repo onto the runner
- run: gh issue create --title "Found a bug" --body "details…"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} # the scoped token = permission to actRead it as a sentence: "When a human presses Run, spin up a runner, check out the repo, and — using a token that can only write issues — create an issue." That GITHUB_TOKEN is the load-bearing idea: the hands can only do what the token permits. No token power → no action. (We go deep on tool permissions in 2.2.)
And the addresses those hands dial into come from the github context: github.api_url → https://api.github.com (REST), github.graphql_url → https://api.github.com/graphql.
A traditional Actions workflow is deterministic: you write every step, trigger, and condition in YAML; it does exactly that, every time. An agentic workflow hands some of the decision-making to the agent at run time — it analyzes and plans rather than following a fixed script. Same engine (Actions, runners, tokens), different driver. Either way it's still GitHub's machinery — still permissioned, still logged.
The cert-language version
GitHub supports agents through three layers: APIs (read state + act), Actions workflows (execute in a controlled runner), and agentic workflows ("Continuous AI" — orchestrate over time, extending CI/CD). Agents use the same mechanisms developers use — branches, commits, pull requests — and act through structures that enforce permissions and remain auditable. They do not operate outside the platform.
Our summary · grounded in MS Learn — Agent tooling, MCP, and execution environments + GitHub Docs (Actions workflow syntax, contexts) · fetched 2026-05-31
Common confusions (read these or get them wrong on the exam)
- "The agent has its own special access / a private channel." No. It uses the same APIs, branches, and PRs as humans and is bound by the same permissions — there is no bypass.
- "Agentic workflows replace CI/CD." No — they extend it ("Continuous AI"). Your CI still runs; the agent adds to it.
- "API and workflow are the same thing." No. The API is the direct programmatic reach (do one action now). A workflow is a YAML process that runs jobs on a runner when an event fires. An agent uses both.
"workflow_dispatch"is automatic. No — that's the manual ("press Run") trigger. Automatic = repo events likepush/pull_request.
Ticks this lesson done on the home roadmap. Saved in this browser.