Agentic Workflows in CI

The Problem

Every playbook in this hub so far shares one assumption: an engineer is present. The review skill runs when someone types it. Spec Kit runs when someone starts a plan. Agent Teams need a lead session to spawn them. That ceiling is real, and it is not a model limitation. It is an attention limitation.

So the work that most benefits from a tireless reader never gets one. Issues sit unlabeled until a maintainer has an hour. The nightly CI failure gets a "flaky, rerun it" until the third time. Docs drift from the code for a quarter. Nobody is going to spend their morning on any of it, which is exactly why it is agent-shaped work.

The usual fix is to bolt an agent CLI into a hand-written GitHub Actions job. That works, and this repository has three of them, but you own all the glue: the checkout, the auth, the prompt file, the permissions, the guardrails that keep a comment on a fork from making the agent do something expensive. Every workflow reinvents it, and the security posture is whatever the person who wrote the YAML happened to think about that day.

What It Is

GitHub shipped Agentic Workflows into technical preview on 13 February 2026 and calls the category Continuous AI: the same relationship to the development lifecycle that CI has, applied to work that needs reasoning rather than a deterministic script. It is explicitly not a replacement for build, test and release. It is for triage, review, CI investigation, documentation, dependency analysis and reporting.

A workflow is one markdown file in .github/workflows/. YAML frontmatter configures it, the markdown body is the instruction:

1---
2description: 'Flag design system drift on incoming pull requests'
3on:
4  pull_request:
5    types: [opened, synchronize]
6    roles: [admin, maintainer, write]
7permissions:
8  contents: read
9  pull-requests: read
10engine: claude
11timeout-minutes: 15
12max-ai-credits: 300
13network:
14  allowed:
15    - defaults
16    - node
17tools:
18  github:
19    toolsets: [default]
20  bash: ['npm run lint', 'npm run typecheck']
21safe-outputs:
22  create-pull-request-review-comment:
23    max: 10
24  add-labels:
25    max: 2
26---
27# Design System Drift Review
28
29Review the changed files in this pull request against `app/lib/design-tokens.ts`.
30
31For every raw hex color, hardcoded spacing value, or one-off component that
32duplicates something already in the design system, leave one review comment on
33the exact line. Name the token or component that should have been used.
34
35Say nothing about style, naming or formatting. If the diff is clean, add the
36`design-system-ok` label and leave no comments.

gh aw compile reads that and writes design-system-review.lock.yml next to it: a standard GitHub Actions workflow, committed to the repository, reviewable in a pull request like any other CI change. The generated file is the artifact your security team reads. The markdown is the file your team edits.

Getting It Running

1gh extension install github/gh-aw
2gh aw init --engine claude          # or copilot, codex, gemini, pi
3gh aw add githubnext/agentics/issue-triage
4gh aw compile

githubnext/agentics is the sample pack: issue triage, CI doctor, PR review, doc updaters, accessibility checks, weekly reports. Issue triage is the honest starting point, low risk and immediately useful.

Once workflows are live, the operational commands are the reason this beats hand-rolled YAML:

1gh aw status                 # which workflows are active
2gh aw logs ci-doctor -c 10   # last 10 runs, with cost and token counts
3gh aw audit <run-id>         # full trace of one run
4gh aw audit <id1> <id2>      # diff two runs against each other

The Security Model Is the Point

This is the part worth reading even if you never install it, because it is the shape any team running unattended agents eventually has to build.

• The agent job is read-only and sandboxed.It cannot write to the repository. Not by policy, by construction.
• Writes go through safe outputs.The agent emits a request. A separate job validates it and performs it with its own narrow permissions. There is a fixed catalogue of what can be requested (create-pull-request, add-comment, add-labels, create-pull-request-review-comment, push-to-pull-request-branch and roughly forty more), each with a max: ceiling. A compromised prompt cannot invent a new capability.
• Network egress is an allowlist.All engines run behind AWF, a firewall wrapper that permits domains by ecosystem (defaults, node, python, github, containers) plus anything you name. Everything else is refused and logged.
• Triggers are gated by role.roles: [admin, maintainer, write] means a comment from a stranger on a fork does not start an agent run. This is the single most common way a naive agent-in-CI setup gets abused.
• Secrets stay out of the model's context.Workflow-level env: must not carry ${{ secrets.* }}, because that puts them in front of the agent.
• Spend has a ceiling by default.20 minute timeout, 1,000 AI credits per run and 5,000 per workflow per day, where one credit is one US cent. max-ai-credits and max-daily-ai-credits tighten it. A runaway loop costs you a capped amount and an issue, not a bill.

None of that removes the need for judgement. The project's own README says it plainly: this requires careful attention to security and careful human supervision, and things can still go wrong.

Test It Without Touching Your Repository

gh aw trial runs a workflow against a temporary private repository, so the issues, comments and pull requests it would have created land somewhere disposable:

--logical-repo makes the agent behave as though it is operating on your repository while side effects stay in the trial host. --repeat runs it several times, which is how you find out whether the instruction is actually stable or just worked once. Results land in trials/. Do this before every prompt change to a workflow that comments on customer-visible issues.

Why This Matters for Senior Teams

• It attacks the merge bottleneck, not the writing bottleneck.Generation was already cheap. The expensive half is everything between "a pull request exists" and "it is safe to merge": the review pass, the drift check, the flaky-test triage. Those are exactly the jobs that fit a scheduled or event-triggered agent, and moving them off human attention is where the throughput actually comes from.
• Non-engineers can define the process.The file is English with a small config header. A product manager who has never written YAML can describe how their team wants issues triaged, or what a design review should catch, and have it enforced on every pull request from then on. That is the same claim as everything else here: the person who knows the rule writes it down, and the system carries it.
• Guardrails become reviewable code.The compiled .lock.yml is committed. What the agent may touch, which domains it may reach, what it may write, and how much it may spend all live in a diff with an author and a reviewer. "What does our automation actually do" has a file to point at.
• You get the evidence trail governance asks for.gh aw logs and gh aw audit produce per-run traces, costs and diffs between runs. When a client's ISO 42001 or SOC 2 review asks how AI-authored changes are controlled and monitored, that is the answer, and it is generated rather than written.
• Rollout is per-repository and reversible.One workflow, one low-risk trigger, on one repository. Delete the file to stop. There is no platform decision to make first.

Where It Fits in the Stack

• It is the CI rung of the Autonomy Ladder.Same question, different setting. Nobody is there to answer a prompt, so the boundary has to be structural: read-only agent, scoped write job, egress allowlist, spend cap.
• Golden-PR Evals get a harness.gh aw trial --repeat against a fixed repository state is a real eval loop for a prompt you are about to run unattended a hundred times.
• CLAUDE.md and AGENTS.md carry over.The agent job checks out your repository and reads the same committed context your local sessions do. One source of conventions, two runtimes.
• Skills install into the run.The skills: frontmatter field pulls skills from a repository before the agent starts, so the review standard you already encoded runs in CI at a pinned version rather than being restated in the prompt.
• Plugins remain the local half.Plugins standardise what every engineer's agent does at their desk. Agentic workflows standardise what happens after they push. A team wants both, holding the same rules.
• Agent Teams are the interactive twin.Parallel agents with a human lead for exploratory work, scheduled single-purpose agents for the recurring work. Do not use a team where a cron job would do.

When Not to Use It

• Not for anything deterministic.If a script can do it, a script should do it. Lint, format, typecheck and test stay plain Actions. Reasoning is the whole justification for the cost.
• Not on high-frequency triggers.Every push on a busy repository is a bill and a queue. Prefer a schedule, a label, or a slash command in a comment.
• Not in the release path.Keep it advisory. An agent that opens a pull request or leaves a review is recoverable. An agent inside your deploy is a different risk conversation.
• Not while it is still in preview on your most sensitive repository.Start where a wrong comment is embarrassing rather than expensive.

Source

• github/gh-awgithub.com (opens in a new tab)
• GitHub Agentic Workflows documentationgithub.github.com (opens in a new tab)
• Agentic Workflows are now in technical previewgithub.blog (opens in a new tab)
• githubnext/agentics, the sample workflow packgithub.com (opens in a new tab)