Agentic Workflows in GitHub: Issues, Agents and Review

An agentic workflow in GitHub is a loop with four stops: an issue that describes the work, an agent that does it, a pull request that carries the result, and a review that decides whether it merges. GitHub now supplies a part for each stop — agents you can assign issues to, agents that run inside GitHub Actions, and branch rules that stop anything merging without a person’s approval. It also has a feature literally named GitHub Agentic Workflows, which is narrower than the phrase suggests and worth understanding on its own terms.

The loop

1. Issue: somebody writes down what is wrong or wanted, with enough detail to act on.
2. Agent: an agent is given the issue — by assignment, by a mention, or by a workflow trigger — and works on a branch.
3. Pull request: the agent’s changes arrive as a pull request, with its explanation and the checks’ results.
4. Review: a person reads the diff, asks for changes or approves, and only then does it merge.
5. State: labels, assignees and project boards say where each piece of work is in between.

The feature called GitHub Agentic Workflows

GitHub announced Agentic Workflows in technical preview↗ (opens in a new tab) in February 2026. You write a workflow as a Markdown file in .github/workflows/: YAML frontmatter says when it runs, what it may read and what it may write, and the body says in plain language what the agent should do. The gh aw command-line extension compiles that file into an ordinary Actions workflow, a .lock.yml, and both files are committed. The changelog lists GitHub Copilot CLI as the default engine, with other coding agents supported.

---
on:
  issues:
    types: [opened]
permissions:
  contents: read
  issues: read
safe-outputs:
  add-labels:
    allowed: [bug, enhancement, question]
  add-comment:
    max: 1
---

# Triage new issues

Read the new issue. Add exactly one label: bug, enhancement or question.
If the issue is missing steps to reproduce, comment asking for them.
Do not close issues and do not promise dates.

The part that makes it safe to run is the write path. The project’s own introduction to agentic workflows↗ (opens in a new tab) describes the agent as read-only by default, with writes going through “safe outputs”: the agent is not given write access itself, it asks for a label, a comment, an issue or a pull request, and only the kinds of write listed in the frontmatter are carried out. Install it with gh extension install github/gh-aw, then gh aw compile after each edit. Because it is a preview, check the documentation for its current status before you depend on it.

It suits jobs that need judgement on a schedule or an event — triage, a daily report, a first look at a failing build. It is one way to put an agent in the loop, not the loop itself.

Stop one: the issue is the brief

Whatever agent you use, the issue is most of what it knows. GitHub’s page on using Copilot cloud agent↗ (opens in a new tab) (the agent formerly called Copilot coding agent) says it receives the issue title, the description, the comments that exist at that moment and any extra instructions — and that comments added after assignment do not reach it. So write the issue as you would brief a new colleague: what is wrong, where, how you will know it is fixed. How to write a task for an AI agent has a template.

Stop two: handing it to an agent

• Assign the issue to Copilot. From the issue’s Assignees menu; it works in its own Actions-powered environment and opens a pull request. The Copilot coding agent post walks through it.
• Mention an agent in a comment. The Claude Code GitHub Action↗ (opens in a new tab) runs Claude Code in your workflows: mention @claude on an issue or pull request and it can implement the change and push commits, or give it a prompt to run on any event.
• Trigger it from a workflow. An agentic workflow like the one above can label an issue, comment on it, or open a pull request when an event fires.

Stop three: the pull request

The pull request is where agent work becomes reviewable. GitHub’s risks and mitigations page↗ (opens in a new tab) for Copilot lists the guard rails around it: only people with write access can hand it work, it can push only to its own copilot/ branch, the person who asked for the pull request cannot approve it, and by default Actions workflows do not run on its code until someone with write access presses Approve and run workflows. It is also subject to the repository’s branch protections and required checks.

Stop four: review is the gate

The human gate is not a habit; it is a setting. On the branch you merge into, GitHub’s protected branches↗ (opens in a new tab) let you require a number of approving reviews, dismiss approvals when new commits change the diff, require code owners to approve changes to their code, require the most recent push to be approved by someone other than the person who pushed it, and require status checks to pass. Turn those on before the first agent opens a pull request, not after the first surprise.

• Require at least one approving review on the default branch.
• Dismiss stale approvals, so an agent’s later push is reviewed again.
• Require your test and lint checks to pass.
• Use code owners for the paths where a mistake is expensive: payments, authentication, migrations.

Keeping state: labels and projects

Between the stops, somebody needs to know where each piece of work is. In GitHub that is usually labels and a project board: a label such as agent-ready on issues that are written well enough to hand over, the agent as assignee while it works, the linked pull request while it waits for review. These are conventions you choose, not built-in states, so write them down where everyone, and every agent, will read them.

The weakness is that the state is spread across three objects — the issue, the pull request and the Actions run — and across repositories. A change that touches the web app and the API is two pull requests in two places. Work that is not code at all, such as a decision, a support reply or a content change, has no pull request to hang off.

When the loop needs a board above it

That is where teams add a board that spans repositories. On fenbs, each piece of work is one task — a feature, an enhancement or a bug — in To Do, Next Up, In Progress or Completed. The task’s plan says what will be done; a person can press “Let AI do this” to pre-approve that plan for any connected AI assistant, which works it, fills in how it was tested and moves it to Completed, where the card says “AI done · check it” until a person confirms. fenbs does not merge or deploy anything; GitHub’s review rules still decide what reaches the default branch. The board records who moved what, including every change an assistant made on someone’s behalf.