GitHub declared Agentic Workflows generally available on October 28 for GitHub Free, Team and Enterprise. A workflow is a Markdown file that gh aw compile turns into Actions YAML; the agent then runs in a sandboxed container, read-only by default, and anything it wants to change goes out through a safe-outputs step and a separate threat-detection job. The day before, GitHub put server-to-server authentication for Copilot into public preview, so a GitHub App can call the Copilot SDK with no user seat and have the usage billed to the organization that installed it. And on October 28 GitHub said the GitHub Copilot SDK is becoming the Microsoft Copilot SDK, with no dates. Agentic Workflows changelog · Server-to-server changelog · SDK changelog
Our October 28 Fusion and billing piece gave each of these a line in its Universe roundup. This is the longer read for teams about to turn them on. For a platform team the three fit together: workflows put an agent into CI, server-to-server auth runs one outside CI without a person’s token, and the rename is why to pin the SDK before either goes into production. S5 Labs has not run any of it. The caps, permissions and quotes below come from GitHub’s changelogs and docs as read on October 30, and the one customer figure is Accenture’s own.
What the compiler produces, and where the agent runs
The Markdown file states what the workflow should do in plain language; gh aw compile turns it into what the docs call a “hardened, pinned Actions workflow” (the compile step is labelled “Pinned, validated GitHub Actions YAML”). The compiled YAML runs on your existing runner groups under your existing policy constraints, and the agent can be Copilot or your own coding agent. The docs list Copilot, Claude Code, Codex, Antigravity and Pi as engines; Kiro, OpenCode and Cursor appear only as “(sample)”. The changelog says using the default Copilot CLI engine “requires a Copilot license”, so a workflow on a Free org still needs a Copilot license. Agentic Workflows changelog · gh-aw docs
The docs describe six security layers, and the GA post repeats most of them: compile-time validation; a sandboxed agent with read-only access; credential isolation; integrity filtering; a threat-detection job; and safe outputs, the path by which the agent’s proposed changes reach the repository. The container sits behind what GitHub calls the Agent Workflow Firewall, and “a dedicated threat detection job scans all proposed changes before they are applied.” Setting staged: true previews the outputs without applying them, which is the setting to leave on for the first week. Agentic Workflows changelog · gh-aw docs
The isolation runtime is where the GA label needs reading against the docs:
| Runtime | Where | Status in the docs |
|---|---|---|
| Docker container | Any runner | Default |
| Cloud Hypervisor micro-VM | GitHub-hosted Ubuntu runners with KVM | Preview |
| NVX micro-VM | Linux x86_64 runners with KVM | Preview |
| Enclaves for cross-repository workflows | Not described | Not in the docs we read |
The changelog lists micro-VMs and enclaves among the GA highlights without labelling either as preview; the docs call both micro-VM runtimes preview and do not mention enclaves at all. Treat the Docker sandbox as the GA product and the micro-VMs as the preview the docs say they are. Agentic Workflows changelog · gh-aw docs
What GA adds, and what the release notes say
The changelog’s list of changes since public preview: Actions Runner Controller and Docker-in-Docker support; gh aw forecast is “no longer experimental” and now covers threat-detection credits and monthly ranges; the micro-VM runtimes and enclaves above; a model router that picks by task type and difficulty; and new templates through gh aw add-wizard. The project is open source from GitHub Next, and the post links the githubnext/agentics repository alongside it. Agentic Workflows changelog · githubnext/agentics
The release page says less. The latest tag is v1.0.1, published October 27, and the visible part of its notes (the page truncates the full list) does not mention GA, forecast, micro-VMs, enclaves or the add-wizard. The post does not say what GA covers, either: there is no run pricing and no list of which runtimes are inside the GA line. gh-aw releases · Agentic Workflows changelog
The post’s customer evidence is one person’s. Ben Alton, a senior manager in Strategy, Architecture & Innovation at Accenture, estimates the workflows save him 29 hours a week on his own development work, and says “measured velocity has more than doubled on average”, AI authors 91% of the team’s commits, and production errors fell from about 11,000 a day to under 1,000. GitHub supplied the quote; none of the figures is independently measured. Agentic Workflows changelog
The credit caps are guardrails, not a bill
Agentic Workflows counts spend in AI credits, where “One AIC equals $0.01 USD.” The docs set defaults that stop a runaway agent, and they are per workflow, not per org:
| Guardrail | Default |
|---|---|
| Credits per workflow run | 1,000 AIC ($10) |
| Credits per workflow per day, 24-hour window | 5,000 AIC ($50) |
Threat-detection credits (safe-outputs.threat-detection.max-ai-credits) | 400 AIC ($4) |
| Agentic step timeout | 20 minutes |
| Agent job timeout | 60 minutes |
| Detection job timeout | 10 minutes |
The two credit caps can be changed in a workflow’s frontmatter or through GH_AW_DEFAULT_MAX_AI_CREDITS and GH_AW_DEFAULT_MAX_DAILY_AI_CREDITS, and -1 disables a cap. Twenty workflows at the daily default can spend $1,000 a day between them, because the 5,000 AIC window is per workflow; nothing in the docs sums across an org. gh-aw cost management
The same page says “AIC values are computed on a best-effort basis” and “may not exactly match your provider’s actual billing”, and that daily totals are “guardrail accounting, not provider billing.” Actions minutes for the runner are billed separately. What neither the changelog nor the docs say is how a run on the default Copilot engine maps to Copilot AI credits in the org’s bill, whether through a user’s plan allowance, the org budget or something else. Since GitHub Enterprise now meters Copilot from the first request, that mapping is the number a platform team needs before turning workflows on across an org. The changelog says gh aw forecast now covers threat-detection credits and monthly ranges; the cost-management page describes AIC as best-effort and does not describe the forecast output. gh-aw cost management · Agentic Workflows changelog
Server-to-server auth: a seat is no longer the unit
The preview lets a Copilot SDK service run without a signed-in user’s credentials, which is to say without a seat or a person to attribute the usage to. There are two token paths:
| Path | Token | Permission | Org setting | Notes |
|---|---|---|---|---|
| GitHub Actions | Built-in GITHUB_TOKEN | copilot-requests: write on the job | “Allow use of Copilot CLI billed to the organization” | For agents inside a workflow |
| GitHub App | Installation token (ghs_) | organization_copilot_requests: read on the App | Org must allow Copilot requests from GitHub App installations | Token expires after one hour; pass it to the SDK with useLoggedInUser: false |
In the changelog’s words the App permission is the read-only “Copilot Requests” organization permission, and usage is “attributed and billed to the organization that owns the installation.” Model policies, budgets and spending controls apply, and owners cut access by suspending or uninstalling the app. Server-to-server changelog · Server-to-server tokens how-to
The admin doc adds the limits, and they decide whether this is usable for you:
- It “is in public preview and subject to change.”
- Only apps installed on an organization work: “Personal account and enterprise installations cannot use this authentication method.”
- Usage counts against the org’s Copilot budget, and “You cannot create a budget for an individual app or installation.” One noisy app shares the budget with every developer in the org.
- “A budget that only sends alerts does not stop spending.” Requests stop only if “Stop usage when budget limit is reached” is enabled.
- App attribution appears in the AI usage CSV export through the
app_client_idfield, “not in the AI usage view on GitHub.” The field is blank for user-attributed usage, GitHub Actions, other GitHub-owned apps and usage before attribution started. To name the app, matchapp_client_idtoclient_idfrom the “List app installations for an organization” API and readapp_slug.
No plan requirement, rate limit or minimum SDK version is stated on either page. Manage app Copilot access · Server-to-server tokens how-to
The gap is the same one as for workflows: the posts say usage is billed to the org and counts against its budget, and they stop there. There is no rate for app-attributed usage distinct from the per-model rates Copilot already publishes, and no statement of whether a request made with an installation token costs the same as one made from a seat. Until the CSV shows otherwise, assume parity and budget for it.
The SDK is moving to Microsoft on no stated date
“We’re transitioning GitHub Copilot SDK to Microsoft Copilot SDK,” the October 28 post says, and the repository is being prepared for “the upcoming move to the Microsoft organization.” The migration is phased, so “package names, namespaces, and some documentation may continue to reference GitHub Copilot SDK” for a while; “Support for the Copilot SDK remains the same” and “No immediate changes are required for existing users.” There are no dates and no new package names. SDK changelog
Nothing breaks today, which is the post’s point. A service built on the server-to-server path above still depends on the repo, the package and the namespace; the post says the repo is moving to the Microsoft organization and that package names and namespaces may still show the old branding during a phased migration, with no schedule published. Pin the SDK to an exact version in every service that uses it, and put the rename on the same watch as the one you keep for Copilot model retirements. The same week’s Agent Merge, which has Copilot watch a pull request and fix failing Actions runs or merge conflicts on paid plans, carries no billing statement either; we covered it in the Fusion roundup.
What to do before an org-wide rollout
Compile, then read the YAML. The compiled workflow is the thing that runs. Review it like any Actions change. The docs call the output “pinned” without saying what is pinned, so keep a workflow lockfile on the repository whatever the compiler does.
Run staged for a week. staged: true shows what the agent would have changed. Count how often threat detection flags something and how often you would have merged the output as is.
Compare forecast to the CSV. Run gh aw forecast on each workflow, then pull the org’s AI usage export after a week and reconcile. GitHub has not published the gap between guardrail AIC and billed credits; your export is the only place to find it.
Set caps below the defaults for anything that fires on its own. A triage workflow that runs on every issue can reach 5,000 AIC in a day on its own, and the cap does not sum across workflows.
Prove the budget stops. Before installing a server-to-server app, set a small org budget with “Stop usage when budget limit is reached” on, drive the app into it, and confirm requests fail. An alert-only budget stops nothing.
Check the enterprise install. If your apps are installed at the enterprise level, this preview does not cover them; the app has to be installed on each organization whose budget should carry the usage.
Pin the SDK and watch the repo. Exact versions everywhere, and a subscription to the SDK repo’s releases, since the Microsoft move has no date.
Sources
GitHub changelog: GitHub Agentic Workflows generally available (October 28) · GitHub Copilot supports server-to-server authentication (October 27) · GitHub Copilot SDK is becoming Microsoft Copilot SDK (October 28) · Agent Merge watches and fixes pull requests in the cloud (October 28)
Agentic Workflows docs and code: gh-aw documentation · Cost management · gh-aw releases · githubnext/agentics
Copilot docs: Manage Copilot access for GitHub Apps in your organization · Server-to-server tokens for the Copilot SDK
Related S5 Labs coverage: Copilot Fusion and usage billing · GitHub Actions workflow lockfiles · Copilot model retirements