GitHub Agentic Workflows Setup for Automating Issue Triage and CI Failures

GitHub Agentic Workflows setup for automating issue triage and CI failures starts with a different kind of repository automation: developers describe a task in Markdown, then compile it into a GitHub Actions workflow. The approach gives teams a way to delegate interpretation-heavy work, such as sorting an issue or investigating a failed build, to an AI agent within an Actions workflow.

GitHub announced the public preview on June 11, 2026. The feature is in preview, so its behavior and documentation may change.

Workflow aspect	What GitHub documents
Authoring	Markdown instructions with YAML frontmatter are compiled into GitHub Actions workflows.
Issue triage	A sample examines issues, applies bounded labels, checks for duplicates and can ask clarifying questions.
CI investigation	A sample examines failed jobs and logs and can produce diagnostic issues or comments.
Guardrails	Read-only defaults, sandboxing and safe outputs constrain how an agent interacts with a repository.

What changed with GitHub Agentic Workflows?

The public preview follows GitHub's February 13, 2026 technical-preview announcement, which described tasks including issue triage and CI investigation. The later announcement presents these as repository workflows that combine natural-language instructions with the scheduling and execution capabilities of GitHub Actions.

That distinction matters because a failed build often needs interpretation before a maintainer can act: an agent can examine logs and repository context, then report a possible explanation. For incoming issues, it can interpret the description and route information through configured outputs. The CI investigation example and issue-triage example show these as separate workflows.

GitHub's architecture documentation describes controls for engines and tools, alongside sandboxing and safe outputs. Teams mapping these automations to existing responsibilities can use a project consultation to clarify workflow requirements before implementation.

Prerequisites and first setup

Start in a repository where GitHub Actions is enabled and you have write access. Install GitHub CLI version 2.0.0 or later, then authenticate with the GitHub account you will use for the repository. GitHub's setup tutorial covers repository access, authentication, engine configuration and the credentials needed to run a workflow.

Authenticate the CLI and install the GitHub Agentic Workflows extension:

gh auth login
gh extension install github/gh-aw

Run these commands in a terminal and follow the authentication prompts. The first command connects the CLI to GitHub; the second adds the workflow tooling. GitHub's quickstart describes supported operating systems and the first-run setup.

Choose an engine and prepare the workflow

Select an AI engine your account or organization can use, and configure its required credential or permission. GitHub documents built-in support for GitHub Copilot, Claude Code, OpenAI Codex, Google Gemini and Pi. Engine access and credentials depend on the provider and account, so check the setup tutorial for the option you select.

Workflow source files use Markdown with YAML frontmatter. The frontmatter defines configuration, while the Markdown body describes the task for the agent. This separation lets a team express repository-specific instructions alongside settings that control execution. When deciding which tasks need interpretation, teams can also consider the scope of generative AI services alongside their existing automation requirements.

After creating or changing a workflow, compile it with gh aw compile. GitHub's workflow creation guide explains the generated .lock.yml file and the files to commit. The compiled file is the GitHub Actions workflow; the Markdown file remains the editable source.

Set up automated issue triage

GitHub’s issue-triage sample is a starting point for repositories that receive questions, bug reports and other requests through issues. Add the githubnext/agentics/issue-triage sample with the workflow wizard, then adapt its instructions to the way maintainers classify and respond to incoming work.

The sample runs when an issue is opened or reopened. It examines the issue and relevant repository context, checks for possible duplicates and can ask for clarification when the report does not contain enough information. It can also apply labels from a bounded set rather than choosing arbitrary labels. Its reports give maintainers a starting point for deciding what to do next.

Adapt labels and instructions to your repository

Before enabling the workflow, align its allowed labels and priority definitions with the repository’s conventions. The labels must already exist: GitHub warns that applying a missing label can fail. A useful instruction can distinguish a request for help from a report of broken behavior, for example, while leaving ambiguous cases for a maintainer to assess.

The workflow uses safe outputs for repository changes such as labels and comments. Review its triage decisions, particularly duplicate suggestions and requests for clarification, before treating them as authoritative. A duplicate suggestion can help a maintainer find a related report, but the maintainer still needs to decide whether the two issues describe the same problem.

For teams deciding where issue handling connects to broader delivery work, the company’s services overview describes its development and support capabilities. Within the repository, keep the triage instructions focused on information maintainers can act on: the reported problem, relevant context and the next question that would make the issue easier to understand.

Investigate CI failures with CI Doctor

The CI Doctor example provides a starting point for investigating failed GitHub Actions runs. Add the githubnext/agentics/ci-doctor sample, then configure it around the workflows and repository practices your team uses. Its purpose is to produce a useful investigation for a maintainer, while the existing CI workflows continue to run the checks themselves.

The sample uses a workflow_run trigger to investigate failures in monitored workflows. It reads failed jobs and their logs, then considers relevant repository changes to build a diagnosis. That additional context can help distinguish a failure associated with a recent code change from one that needs a closer look at the job environment or its dependencies.

Make the investigation useful to maintainers

Set the monitored workflow names to match the Actions workflows you want investigated. Choose names that correspond to checks your team actively maintains; otherwise, a failure may never reach the investigation workflow. Describe repository conventions in the workflow instructions so the report uses terms and points of contact familiar to the people who will read it.

CI Doctor can report its findings by creating an issue or commenting through configured safe outputs. A useful report identifies the failed run, points to the evidence it considered and expresses confidence in its diagnosis. Generated diagnoses are suggestions rather than proof of root cause, so check the relevant logs and code before acting on them.

For an application team, the investigation can become part of the maintenance process described on the application development page: a diagnostic report gives the person responsible for the application a starting point for examining a failed check. After changing the sample’s configuration or instructions, compile the Markdown source again and commit the resulting workflow file so Actions can run the updated configuration.

Availability, billing and operating limits

GitHub Agentic Workflows is in public preview, and the gh-aw extension is free and open source. Running a workflow can still incur charges in two places: GitHub Actions provides the compute, while the selected AI engine handles inference. GitHub’s billing documentation explains these separate cost categories.

The inference billing path depends on the engine and credentials. GitHub documents organization AI Credits or a user token as possible paths for Copilot; other engines bill through their providers. Check the applicable account and provider terms before estimating a rollout, because there is no single all-inclusive price or universal quota.

Estimate the cost of a run

GitHub describes a typical run as including a pre-activation job lasting about 10–30 seconds and an agent job lasting about 1–15 minutes. It also estimates approximately 1.5 minutes of runner setup overhead per job. These are planning figures, not a promise of how long a particular repository’s workflow will run; the workflow’s duration and Actions usage affect its compute costs.

A practical budget starts with the number of events likely to trigger a workflow and the amount of investigation each run requires. A busy repository may need a different spending allowance from one that receives occasional reports. GitHub’s agentic workflows FAQ points to native Actions spending limits as one way to manage usage. For a broader assessment of workflow scope and rollout, the project consultation page describes the available planning support.

Keep verification in deterministic CI

Agentic workflows add interpretation to repository automation; they do not make builds, tests, linting or deployments reproducible by themselves. Keep those checks in deterministic workflows, where the same defined commands can verify a change. Use the agent’s output to inform a maintainer’s investigation and the existing CI results to establish whether the required checks passed.

When to adopt GitHub Agentic Workflows

Choose a GitHub Agentic Workflows setup for automating issue triage and CI failures when interpreting reports or investigating failures is the bottleneck, while keeping code-changing and release-critical decisions subject to deterministic checks and human review.

As a next step, add one sample workflow to a low-risk repository, compile it, run it and inspect its first output.