GitHub Agentic Workflows is generally available with Markdown-defined coding agents in GitHub Actions
GitHub Agentic Workflows is now generally available. GitHub announced the change in its official changelog on October 28, 2026, on the same day as its other Universe releases, moving the open-source project from GitHub Next out of public preview. The tool lets teams describe repository automation in plain Markdown, compile it into a standard GitHub Actions workflow, and hand the reasoning part of the job to a coding agent, either GitHub Copilot or another supported engine. GitHub positions it for tasks that are hard to express as fixed if-then rules: triaging new issues, analysing CI failures, keeping documentation current, writing tests and producing recurring status reports.
The general availability release covers github.com accounts on GitHub Free, Team and Enterprise. The project itself is free and open source, but running it is not: every workflow consumes GitHub Actions minutes like any other job, and every agent run consumes model inference, which with the default Copilot engine requires a Copilot license and is counted in AI Credits. That combination of an open tool, a metered runtime and an AI engine chosen per workflow is what developers and platform teams need to understand before switching it on across repositories.
The design choice that sets the product apart is that the agent never receives write access directly. It runs read-only inside a sandbox, proposes its actions as structured "safe outputs", and separate, permission-scoped jobs apply those actions only after validation and a threat-detection scan. In practice this means that an agent asked to triage an issue can suggest labels and a comment, but cannot push code, read repository secrets or call arbitrary network endpoints unless the workflow author explicitly allows it.
··········
HOW A MARKDOWN WORKFLOW BECOMES A GITHUB ACTIONS JOB.
Each agentic workflow is a single Markdown file stored in the repository's .github/workflows/ directory. The file has two parts. The YAML frontmatter between --- markers declares when the workflow runs (on:), what it is allowed to read (permissions:), which tools the agent can use (tools:), and which write operations it may request (safe-outputs:). The Markdown body underneath contains the task itself, written as natural-language instructions, for example a request to summarise the last 24 hours of merged pull requests, closed issues and blockers in a new issue.
The gh aw compile command, provided by the gh-aw extension for the GitHub CLI, turns that Markdown file into a .lock.yml file, which is an ordinary GitHub Actions workflow with security hardening added by the compiler. The documentation tells users to commit both files: the Markdown file is the source that people edit, while the lock file is what Actions actually executes and should not be edited by hand. Because the output is a normal Actions workflow, triggers, runners, logs, runner groups and organisation policies all behave as they already do, and the agent layer sits on top of that existing infrastructure rather than beside it.
GitHub's quickstart, which uses a ready-made daily repository status report from the GitHub Next agentics repository, takes four commands. The wizard checks permissions, asks for an engine, helps store the required secret and can trigger a first run; according to the documentation, a run typically takes two to three minutes and ends by opening an issue titled "Daily Repo Report".
gh extension install github/gh-aw
gh aw add-wizard githubnext/agentics/daily-repo-status
gh aw compile
gh aw run daily-repo-statusThe compile step is only needed again when the frontmatter changes. For monitoring, the extension adds gh aw status, gh aw logs and gh aw audit <run-id>, the last of which breaks a single run down by tokens, AI Credits and agent turns.
··········
WHICH AI ENGINES CAN RUN A WORKFLOW.
GitHub Copilot is the default engine, but the engine: field in the frontmatter can select another agent per workflow. The project documentation lists five built-in options, each with its own credential. Teams that already pay for an Anthropic, OpenAI or Google API account can therefore run agentic workflows without routing inference through Copilot, in which case the provider bills inference directly.
........
Engine | engine: value | Credential |
GitHub Copilot (default) | copilot | copilot-requests: write permission or COPILOT_GITHUB_TOKEN |
Claude Code | claude | ANTHROPIC_API_KEY or Anthropic WIF |
OpenAI Codex | codex | CODEX_API_KEY or OPENAI_API_KEY |
Google Gemini | gemini | GEMINI_API_KEY or Google WIF |
Pi | pi | Copilot, Anthropic or OpenAI/Codex auth, depending on model |
........
For organisation-owned repositories with a Copilot plan, GitHub's documentation recommends the built-in GITHUB_TOKEN with the copilot-requests: write permission, which requires an organisation administrator to enable the relevant Copilot CLI billing policies. Where that is not possible, the fallback is a separate fine-grained personal access token stored as COPILOT_GITHUB_TOKEN. Among the changes shipped since the preview, GitHub lists a refreshed model inventory, model provider selection per workflow, and a model router that picks a model based on the type and difficulty of the task. With a dynamic selector such as model: auto, inference is charged at the catalogue rate of whichever model is actually used.
··········
THE SECURITY MODEL: READ-ONLY AGENTS AND SAFE OUTPUTS.
GitHub describes five built-in safeguards in the general availability announcement. Agents access GitHub content under integrity filter rules, which limit what content the agent sees based on the trust level of its author; they run with read-only permissions by default; they execute in a sandboxed container behind the Agent Workflow Firewall, which can restrict outbound traffic to allowed domains; their outputs pass through the safe outputs process; and a threat-detection job scans every proposed change before it is applied. The general availability release adds stronger isolation options, with agents able to run inside Cloud Hypervisor or NVX micro-VMs, and enclaves designed to prevent data leaks in workflows that span several repositories.
Safe outputs are the mechanism that replaces direct write permissions. The agent emits a structured request, for example to create an issue or add labels, and a downstream job holding only the permission that operation needs, such as issues: write, carries it out. Each output type has a default maximum per run. A workflow without a safe-outputs: section gets create-issue enabled with a maximum of one issue, so authors who want different behaviour must declare the outputs explicitly.
........
Safe output type | Default max per run |
create-issue | 1 |
add-comment | 1 |
add-labels | 3 |
create-pull-request | 1 |
create-pull-request-review-comment | 10 |
close-pull-request | 10 |
add-reviewer | 3 |
merge-pull-request (experimental) | 1 |
create-code-scanning-alert | Unlimited |
........
The safe outputs layer also applies content rules and filters. An issue body, for instance, must be between 20 and 65,000 characters; options such as required-labels and required-title-prefix reject updates to items that do not match; and title-based deduplication is checked both when the agent calls the tool and again when the change is applied. Secrets stay in the isolated downstream jobs rather than in the agent runtime, and critical actions can be gated behind human approval through GitHub Environment protection rules.
The documentation is explicit about where this protection ends. Direct write permissions granted to the agent job and custom post-processing jobs sit outside the safe outputs boundary, and the project FAQ advises reviewing them carefully. That caveat matters given recent supply-chain incidents in AI developer tooling, such as the malicious Claude Code extension distributed through Cursor's marketplace: the read-only default reduces the damage a prompt-injected agent can do, but only as long as workflow authors do not undo it.
··········
WHAT IT COSTS TO RUN AN AGENTIC WORKFLOW.
The cost of a workflow has two components. The first is GitHub Actions minutes: each run has a pre-activation job of 10 to 30 seconds and an agent job of one to fifteen minutes, and each of those jobs carries about one and a half minutes of runner setup overhead, billed at standard Actions rates. The project FAQ notes that Actions minutes are free for public repositories and metered for private ones. The second component is inference, which the project measures in AI Credits (AIC), where one AIC equals $0.01. With the default Copilot engine, GitHub's documentation says AIC usage maps to AI credits in Copilot billing; with a third-party engine, the provider bills inference directly, and GitHub warns that its AIC figures are best-effort estimates that may not match provider invoices.
The tool ships with default guardrails that bound both time and spend. Authors can change the per-run and daily caps with max-ai-credits and max-daily-ai-credits in the frontmatter, and cap agent turns with max-turns.
........
Default guardrail | Value | Equivalent in USD |
Per-run inference budget | 1,000 AIC | $10.00 |
Per-workflow daily budget (24 hours) | 5,000 AIC | $50.00 |
Threat-detection budget per run | 400 AIC | $4.00 |
Agentic step timeout | 20 minutes | Not applicable |
Agent job timeout | 60 minutes | Not applicable |
Detection job timeout | 10 minutes | Not applicable |
........
These defaults are ceilings rather than typical costs, but they give a useful worst-case picture. A single run that hits both the main and detection caps would consume 1,400 AIC, or $14 of inference. A workflow that reached its 5,000 AIC daily cap every day for 30 days would consume the equivalent of $1,500 in a month, which is why the daily guardrail exists. GitHub notes that the daily cap is skipped for workflow_call, repository_dispatch and workflow_dispatch runs, so manually or externally triggered workflows rely on the per-run cap alone.
On the Actions side, the project's own scenario estimates are modest: about one minute per month for a weekly digest that runs four times, about ten minutes for issue triage running 20 times, and about 100 minutes for a pull request review that runs on every push, around 100 times a month. The documentation lists inference cost for those scenarios only as variable, because it depends on model choice and task length. Its recommendations are practical: gate agents with skip-if-match or skip-if-no-match before they start, use cheaper models for routine tasks, begin with schedule or workflow_dispatch triggers rather than high-frequency events such as push, batch work into scheduled runs, and use per-user rate limits. The gh aw forecast command, which GitHub says is no longer experimental, now estimates threat-detection credits and monthly spend ranges before a workflow is deployed.
··········
AVAILABILITY, PLANS AND REQUIREMENTS.
GitHub Agentic Workflows is generally available on github.com for GitHub Free, Team and Enterprise. Using the default GitHub Copilot CLI engine requires a Copilot license; running the workflow with Claude Code, Codex or Gemini requires an account and API key with that provider instead. The repository must have GitHub Actions enabled, the user needs write access and the GitHub CLI version 2.0.0 or later, and local setup works on Linux, macOS or Windows with WSL.
There are runtime constraints to plan around. Workflows need Linux runners, because the sandbox relies on container jobs, so macOS runners are not supported. Private repositories are supported. Since the preview, the project has added support for Actions Runner Controller self-hosted runners, including Docker-in-Docker setups, which matters for enterprises that keep CI on their own infrastructure. GitHub Enterprise Server is supported as well, although instances older than the @actions/artifact v2.0.0 release need a compatibility mode, which gh aw init detects and configures automatically. Reading from other repositories requires a personal access token with access to them.
Some GitHub documentation pages still carried the public preview label when this article was written, while the October 28 changelog entry states general availability. Teams that track documentation for compliance reviews should expect the pages to be updated, and should treat the changelog as the reference for the product's status.
··········
HOW IT DIFFERS FROM SHARED COPILOT AUTOMATIONS.
On the same day, GitHub also introduced shared Copilot Automations, which can look similar at first glance because both run AI-driven tasks on repository events. The two products sit in different places. Agentic Workflows are versioned files that compile to GitHub Actions and run on Actions runners, with a choice of engine. Copilot Automations combine prompts, triggers and tools that Copilot runs autonomously in GitHub's cloud, and the new shared type makes them repository-owned rather than personal.
........
Aspect | GitHub Agentic Workflows | Shared Copilot Automations |
Defined as | Markdown file compiled to .lock.yml | Prompt, trigger and tools configured in GitHub |
Runs on | GitHub Actions runners, Linux | Copilot cloud agent |
AI engine | Copilot, Claude Code, Codex, Gemini or Pi | Copilot |
Plans | Free, Team, Enterprise; Copilot license for Copilot engine | Copilot Pro, Pro+, Max, Business, Enterprise (rolling out) |
Billing | Actions minutes plus inference in AIC | AI credits charged to the repository owner |
Status | Generally available | Rolling out |
........
For shared automations, AI credits are charged to the organisation or user that owns the repository, actions are attributed to Copilot rather than to the creator, and the automation keeps running if its creator leaves. In organisation-owned repositories, an administrator must enable the policy that allows the Copilot cloud agent to be billed to the organisation. The choice between the two is largely one of control: Agentic Workflows give platform teams code review over the automation itself, a choice of model provider and the full Actions policy stack, while Copilot Automations require less setup. Both arrive alongside other changes to how GitHub bills AI usage, including Copilot access bundled into GitHub Enterprise with AI credits billed from the first request and the general availability of Copilot Fusion's automatic model routing.
··········
WHAT IS ESTABLISHED AND WHAT REMAINS OPEN.
What is established is the product's status and architecture. GitHub's changelog confirms general availability on GitHub Free, Team and Enterprise as of October 28, 2026, and the project documentation describes in detail how Markdown workflows compile to hardened Actions workflows, how read-only agents request writes through validated safe outputs, and which default limits bound time and spend. The engine choice is broad, the default per-run budget of 1,000 AIC corresponds to $10 of inference, and the tooling for logging, auditing and forecasting cost is part of the release rather than a later promise. The only customer result cited in the announcement is a qualitative statement from a senior manager at Accenture describing reduced development time, higher team velocity and fewer production errors, with no figures attached.
What remains open is how these controls perform at scale. The AIC figures are estimates that GitHub itself says may differ from provider invoices, so actual spend for teams using Claude, Codex or Gemini will only be visible on those providers' bills. The effectiveness of the threat-detection job and integrity filtering against determined prompt injection has not been measured publicly, and the protections deliberately stop at any direct write permission or custom job an author adds. For teams evaluating the tool, the sensible starting point is the one GitHub recommends: scheduled or manually triggered workflows with explicit safe outputs and tight credit caps, expanded to event-driven triggers only once real usage data from gh aw logs shows what each workflow costs.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
