Harness orchestration
GitHub Agentic Workflows and UHP
GitHub Agentic Workflows compiles declarative Markdown agent tasks into standard GitHub Actions workflows and runs multiple coding-agent engines behind a security-oriented orchestration layer. Reviewed primary sources do not establish native UHP, ACP or A2A-protocol support, a HarnessRouter backend or UHP conformance evidence.
Status first
Section titled “Status first”GitHub Agentic Workflows (gh-aw) is an agent-workflow compiler and GitHub Actions orchestration layer, not a UHP implementation. GitHub defines an agentic workflow as Markdown plus YAML frontmatter. The gh-aw GitHub CLI extension validates that source and compiles it into a standard GitHub Actions .lock.yml workflow.
The latest stable release observed at this cutoff is v0.88.7, published 8 September 2026 at 15:34:49 UTC. Tag v0.88.7 points to bde367913adeb3132f0a171594c88a17f4b7d08c. Checked upstream main is 099efdda60fe970829f53f29f726c35615cd55eb at the 10 September cutoff, so stable release evidence and post-release current-main development are kept separate.
Why gh-aw matters to harness architecture
Section titled “Why gh-aw matters to harness architecture”GitHub Agentic Workflows sits one orchestration level above a single coding harness. Stable v0.88.7 supports built-in engines for GitHub Copilot, Claude Code, OpenAI Codex, Google Gemini and Pi. The workflow source chooses an engine, tools, permissions and triggers; the compiled GitHub Actions workflow then launches the selected agent under gh-aw’s security and side-effect controls.
That makes gh-aw useful for understanding a recurring architecture pattern: workflow policy outside, complete agent harness inside. UHP standardizes a different boundary — client → UHP server → configured complete harness. A future integration could place a UHP-served harness behind such a workflow, but reviewed first-party sources do not establish that integration today.
Boundary map
Section titled “Boundary map”| Layer | Primary job | Verified gh-aw relationship |
|---|---|---|
| GitHub Agentic Workflow source | Declarative trigger, permissions, tools, engine and natural-language task | Native authoring surface. Markdown + YAML frontmatter. |
gh aw compile | Validate source and generate executable workflow | Native compiler. Produces standard GitHub Actions .lock.yml. |
| GitHub Actions | Job scheduling and execution substrate | Native runtime substrate. Conventional Actions remain appropriate for deterministic CI/CD work. |
| Coding-agent engine | Model/tool loop and coding behavior | Pluggable inner engine. Stable docs list Copilot, Claude Code, Codex, Gemini and Pi. |
| MCP Gateway | Configure and spawn isolated MCP-server containers | First-party orchestration component. Used with the agent workflow firewall and tool allowlisting. |
| SafeOutputs | Buffer, validate and externalize configured writes | First-party side-effect boundary. Agent jobs remain read-only while separate scoped jobs perform approved writes. |
| ACP | Editor/client-to-agent protocol | Not established by reviewed first-party sources. |
| A2A protocol | Agent-to-agent interoperability | Not established by reviewed first-party sources. |
| UHP | Client → UHP server → complete configured harness | No native adoption established. |
| HarnessRouter | UHP reference implementation → backend adapters | gh-aw is not in the released ten-backend set at this cutoff. |
Compilation separates intent from executable workflow
Section titled “Compilation separates intent from executable workflow”GitHub recommends conventional GitHub Actions for deterministic builds, tests, linting, deployments and reproducible scripts, and agentic workflows for reasoning-heavy work such as issue triage, pull-request review, CI failure investigation, documentation maintenance, dependency analysis and repository reporting.
An agentic workflow therefore has two representations:
- authoring source — YAML frontmatter configures triggers, permissions, tools and the selected AI engine, while Markdown describes the goal;
- compiled workflow —
gh aw compilevalidates the source and writes a standard GitHub Actions.lock.ymlworkflow for execution.
This is a compiler/orchestration contract, not a new agent wire protocol. The generated Actions YAML is an execution artifact; it does not imply that the selected coding engine natively implements gh-aw, UHP, ACP or A2A.
SafeOutputs creates a separate write boundary
Section titled “SafeOutputs creates a separate write boundary”Stable security documentation describes a plan-level SafeOutputs subsystem. The agent can operate with read-only access and produce requested external changes as buffered artifacts. Those artifacts pass through deterministic filters and analyses, and separate jobs with narrowly scoped permissions perform the actual GitHub writes after the agent stage.
This separation matters because successful agent reasoning is not the same thing as authorization to mutate external state. gh-aw makes the externalization step explicit and separately permissioned. That is a GitHub Agentic Workflows security/side-effect model; UHP 2026-08-11 does not standardize SafeOutputs or GitHub Actions job permissions.
Stable v0.88.7 tightens this boundary further: its release notes say workflows now fail fast when an agent reports incomplete work, and agent artifact packaging is restricted to known files to reduce accidental exposure. The release also hardens malformed OTLP authorization-header handling and related provisioning/retry paths.
Runtime isolation includes MCP-specific infrastructure
Section titled “Runtime isolation includes MCP-specific infrastructure”The stable security architecture describes layered isolation rather than treating a coding agent as the only trusted component. Its execution model includes:
- an Agent Workflow Firewall (AWF) that controls the agent runtime and network egress;
- a model API proxy;
- an MCP Gateway that configures and spawns isolated MCP-server containers;
- explicit tool allowlisting and network-domain policy;
- Docker as the default agent isolation boundary, with documented gVisor, Docker sbx microVM and preview Cloud Hypervisor alternatives for compatible runners.
When MCP is enabled, the architecture routes agent-to-server access through the controlled gateway/firewall topology rather than granting unrestricted host access. These are gh-aw runtime/security implementation choices; they do not modify MCP wire semantics and do not make MCP part of the UHP conformance contract.
Release and security boundaries
Section titled “Release and security boundaries”The project README records a security advisory affecting versions >=0.83.3 and <0.85.4, and says those releases were retired. Stable v0.88.7 is outside that affected version range.
The checked post-release main commit 099efdda is newer than the stable tag. This page therefore does not silently attribute post-release current-main changes to v0.88.7; stable behavior is sourced from the tag/release while the moving branch is recorded only as a separate research coordinate.
Evidence boundaries
Section titled “Evidence boundaries”- Stable:
v0.88.7, published 8 Sep 2026 at 15:34:49 UTC. - Stable tag target:
bde367913adeb3132f0a171594c88a17f4b7d08c. - Checked
main:099efdda60fe970829f53f29f726c35615cd55ebat this cutoff. - Workflow compiler: established by the stable README and documentation.
- Built-in engines: Copilot, Claude Code, Codex, Gemini and Pi are established by the stable README.
- MCP: the stable security architecture establishes an MCP Gateway and isolated MCP-server execution.
- SafeOutputs / read-only agent jobs: established by stable README/security documentation.
- ACP: not established by reviewed first-party sources.
- A2A protocol: not established by reviewed first-party sources.
- Native UHP: not established.
- HarnessRouter backend: not present in
v0.15.7’s ten released backends. - UHP conformance evidence: none attributed to GitHub Agentic Workflows.
Related pages
Section titled “Related pages”Read harness composition for nested execution topology, remote harness execution for non-local harness boundaries, Codex, Claude Code and Pi for individual engine surfaces, UHP vs MCP for the tool-protocol boundary, and ecosystem for adoption classifications.