By the end of this chapter you can say precisely what an agentic workflow is, explain why the repository's outer loop is where it earns its keep, and judge when to reach for GitHub Agentic Workflows (gh-aw) instead of plain GitHub Actions. This is the vocabulary chapter: the terms defined here — outer loop, Continuous AI, safe-by-default — are used as settled language for the rest of the book.
Everything here targets gh aw v0.81.6 (Public Preview). You won't write a workflow yet — that is Chapter 2. First, the idea.
Think about how work actually moves through a repository. There is the inner loop: the fast, interactive coding you do at your desk — edit, run, debug, repeat — minute to minute. And there is the outer loop: the repository's slower, collaborative life that surrounds and outlives any one editing session — issues filed, pull requests opened and reviewed, discussions, releases, CI results, and docs that quietly drift out of date. You leave the inner loop every time you close your laptop. The outer loop keeps going.
CI/CD automated half of the outer loop
Continuous integration and deployment were a triumph of outer-loop automation — but only for the deterministic half. A build, a test suite, a release: these “do exactly what you tell them, every time, in the same way” (How They Work). That determinism is precisely what you want when correctness means identical behavior on every run.
But a large, genuinely useful class of outer-loop work is not like that. Reading a new issue and deciding whether it's a bug or a feature request. Asking a reporter for the missing reproduction step. Keeping the docs honest as the code changes. Investigating why CI went red. None of these can be written as a fixed if/then rule, because the right action depends on unstructured context you can only interpret. That is judgment work, and CI/CD was never built to express it — so it fell to already-overloaded humans, or it simply didn't get done.
Where the throughput actually stalls
This is the gap the book is about. Individual AI productivity has advanced quickly, but GitHub Next observes that faster inner-loop coding “can shift burdens to other team members, or to later stages in software projects” — more code generated means more to review, triage, document, and maintain (Continuous AI). The bottleneck moves outward, into the collaborative loop, and that is exactly the loop CI/CD left to human judgment.
GitHub Next gives this idea a name: Continuous AI — “all uses of automated AI to support software collaboration on any platform.” It is deliberately named to rhyme with CI/CD: “Just as CI/CD transformed software development by automating integration and deployment, Continuous AI covers the ways in which AI can be used to automate and enhance collaboration workflows” (Continuous AI). The framing is a third leg alongside CI and CD — and, notably, a category rather than a product: “not a term GitHub owns, nor a technology GitHub builds.”
An agentic workflow, defined
An agentic workflow is the concrete unit that practices Continuous AI. GitHub defines these as “automated, intent-driven repository workflows that run in GitHub Actions, authored in plain Markdown and executed with coding agents” (launch blog). You describe the outcome you want in natural language; a coding agent interprets that intent and carries out the multi-step work. Where traditional automation follows fixed logic, an agentic workflow has agency — it can “understand context, make decisions, and generate content by interpreting natural language instructions flexibly” (How They Work).
That makes it three things it is often confused with, but isn't:
Not a chatbot or an IDE assistant. Those are interactive and human-driven, turn by turn. An agentic workflow is standing and event-driven: it wakes on a repository event, does one job unattended, and proposes a result.
Not a fully autonomous agent. It runs in a bounded sub-loop “under defined terms,” and “pull requests are never merged automatically — humans must always review and approve” (launch blog).
Not a replacement for GitHub Actions. Which brings us to how it actually runs.
It compiles to GitHub Actions
Here is the key architectural fact, and the reason gh-aw is additive rather than a competitor to your existing pipelines. You author a Markdown file; the gh aw compile command turns it into an ordinary, security-hardened GitHub Actions workflow that GitHub runs. “The .md file is the editable source of truth, while .lock.yml is the compiled GitHub Actions workflow with security hardening” (How They Work). Agentic workflows “run on GitHub Actions because that is where GitHub provides the necessary infrastructure for permissions, logging, auditing, sandboxed execution, and rich repository context” (launch blog). So gh-aw adds three things Actions alone lacks — an agentic engine that reasons over context, a natural-language authoring surface, and a security model — on top of the substrate you already trust. The compile model is Chapter 3.
Safe by default (a first look)
Letting a standing agent act in your repository sounds risky until you see the boundary. The agent runs read-only by default — it “can read repository state, but it cannot push commits or write to issues directly” (gh-aw). Anything it wants to change, it requests as a structured safe output, which a separate, permission-scoped job validates before applying — so that “even a fully compromised agent cannot directly modify repository state” (Security Architecture). The agent proposes; a mediated boundary disposes. That is the whole safety thesis in one line; the mechanism is Chapter 6 and the threat model behind it is Chapter 7.
The mental model GitHub offers is refreshingly simple: “if repetitive work in a repository can be described in words, it might be a good fit for an agentic workflow” (launch blog). More precisely, a task fits when it has all three of these traits:
It's judgment work — subjective and repetitive, the kind of task “that traditional CI/CD struggle to express” because there's no fixed rule to encode.
Exact reproducibility isn't the point — triage, drafting docs, researching dependencies, proposing improvements for review. A slightly different (good) answer each time is fine.
Actions are low-stakes and reviewable — a comment, a label, a draft PR. Best practice is to “start with low-risk outputs such as comments, drafts, or reports before enabling pull request creation.”
When to reach for something else
Agentic workflows are additive, not universal. Keep the work in deterministic GitHub Actions — or a human's hands — when:
The task must be exactly reproducible. Builds, tests, and releases must behave identically every run. GitHub is explicit: don't use agentic workflows “as a replacement for GitHub Actions YAML workflows for CI/CD”; the use cases “largely do not overlap” (launch blog).
The action is high-stakes or hard to reverse. Publishing a release, deleting data, force-pushing — if a mistake can't be shrugged off with a click, it isn't a starting point.
Success must be 100% correct with no human in the loop. The value here is throughput on reviewable proposals, not unsupervised perfection.
One workflow is trying to do everything. The unit is one teammate, one job. Start narrow and let patterns emerge.
There's a deeper reason the human stays central. The impact study of GitHub Next's real repository assistant found that throughput was gated less by the model than by “how often human maintainers chose to act on the agent's proposals” (Repo Assist impact report). Agentic workflows don't remove humans from the loop — they make the humans' judgment the scarce, valuable input.
Concepts land when you see them in one artifact. Here is the book's running example — the Repo Assistant, an agentic workflow that triages a newly opened issue. You'll build and ship it in Chapter 2; right now we're just reading it, because every concept from this chapter is visible in these few lines.
examples/ch02/repo-assistant-triage.md — read it as five concepts in one file
---
on:
issues:
types: [opened] # (2) an OUTER-LOOP trigger: a new issue
workflow_dispatch: # also runnable by hand
permissions:
contents: read # (5) READ-ONLY: the agent cannot write directly
issues: read
engine: copilot # (1) the ENGINE: the judgment that reads the issue
network: defaults
safe-outputs: # (5) mediated writes: proposed, then applied by a scoped job
add-comment:
max: 1
add-labels:
allowed: [bug, enhancement, question, documentation]
max: 1
---
# Repo Assistant — triage a new issue
You are the **Repo Assistant**. A new issue was just opened.
Read its title and body, decide what kind of issue it is, post one short
triage comment, and apply at most one label from the allowed set.
Five concepts, one artifact
(1) Agentic workflow. The whole file is one: YAML frontmatter that configures it, plus a natural-language body that states intent. No if/then logic — just “triage it.”
(2) Outer loop. The on: issues: [opened] trigger binds it to a collaborative, outer-loop moment — a new issue — not to your keystrokes. Triggers are Chapter 4.
(3) Continuous AI. This is Continuous Triage, one of the named patterns, expressed as a single workflow.
(4) Compiles to Actions. Running gh aw compile turns this Markdown into a hardened .lock.yml that GitHub Actions executes — the subject of Chapter 3.
(5) Safe by default.permissions are read-only; the only writes are one comment and one allow-listed label, requested through safe-outputs and applied by a separate scoped job. Full mechanism in Chapter 6.
You now have the vocabulary the rest of the book stands on:
The inner loop is your interactive coding; the outer loop is the repository's collaborative life. CI/CD automated the outer loop's deterministic work and left its judgment work to humans.
An agentic workflow is intent-driven, event-triggered repository automation authored in Markdown and run by a coding agent — a standing teammate that proposes, not a chatbot and not an unsupervised agent.
Continuous AI is GitHub Next's name for applying AI to that outer loop — a third leg beside CI/CD — and gh-aw is how you practice it.
gh-aw compiles to GitHub Actions; it is additive, adding an engine, a natural-language surface, and a security model on top of the substrate you already trust.
The agent is read-only by default and every write is a mediated, reviewable proposal — which is what makes standing automation safe to trust.
What's next. Enough theory — time to ship. In Chapter 2: The 10-Minute Win you'll install the gh aw CLI and get this exact Repo Assistant running end to end, triaging a real issue through the safe-by-default boundary.