Skip to content
agentic-job
This text was generated by an LLM (how cgwalters uses LLMs). cgwalters has not reviewed it yet.

Comparison with GitHub Agentic Workflows and gh-cao

gh-aw (GitHub Agentic Workflows) is the source of the safe-output format, of the collector collect ports and check runs here, and of the handlers apply runs. gh-cao (GitHub Central Agentic Ops) is a GitHub Next research prototype layered on gh-aw. It adds campaigns across repositories, a catalog and a dashboard. This page compares features. It is not deployment advice. The README explains why this project uses a host-user sandbox rather than gh-aw's container runtime.

The gh-aw descriptions come from its documentation and the release notes up to v0.92.6, a pre-release of 2026-10-20; the latest full release is v0.92.0 of 2026-10-15. The gh-cao descriptions come from its README of the same week. agentic-job pins gh-aw's setup action at v0.91.12 plus seven commits (safe-outputs.md). Statements about this repository were checked against its code when this page was written; the code wins where they differ. Issue numbers are the ones that tracked each gap. All of them are closed, even where part of the gap remains.

Shape of a workflow

gh-aw compiles Markdown with YAML frontmatter into a locked Actions workflow. Its compiler selects the engine, permissions, firewall, activation, detection and output jobs. It also lints workflows: v0.92.6 adds AST linters for checkout trust, prompt expressions and secret-leak taint. Imports compose prompts and configuration.

agentic-job has no compiler and no prompt language (compiler.md). A caller writes ordinary YAML that calls the reusable workflow at a pinned commit. Its bounds TOML files set the limits check enforces. The caller supplies one standing task. The opt-in workflows check enforces job shape: pins, no persisted credentials, no secrets in secure-host jobs and no unsandboxed agent actions. This repository runs it in its required ingress vet job.

Sandbox and network

gh-aw's default runtime is AWF, its Agent Workflow Firewall, a rootless container with a domain allowlist. Two runtimes are in preview: a cloud-hypervisor VM and the nvx microVM. AWF's API proxy holds the model credential on the runner.

agentic-job uses no container: the agent shares the kernel of a disposable host, and keeps rootless podman and host KVM. Under the reusable workflow, secure-host first removes general root access and the metadata service, and the agent then runs as the runner's user. That job holds nothing the agent may not read: read-only permissions, no id-token and no secret but the run token (workflow.md). The CLI's run without --runner-home instead runs the agent as a second Unix user, with nftables rules keyed on that user's uid (sandbox.md); the reusable workflow does not offer that mode. [egress] write-policy, off by default, holds the runner's user to the same egress policy (egress write policy). Egress goes through the binary's own Rust proxy (the policy file). mitmproxy remains only behind [egress] rust-proxy = false. By default, reads go to any host not on a pinned threat feed, and writes need a [[write]] rule. gh-aw's style of domain allowlist is opt-in: mode = "allowlist" (opt-in domain allowlist).

gh-aw runs on private repositories as on public ones. Here runs are public-only, and the reusable workflow refuses a private target or caller whatever the bounds say. An agent job of the caller's own, with a second user, can opt in through every bounds file. It then also needs the allowlist, may target only the caller's own repository, and hands back no patch (private repositories).

Under the reusable workflow the model key never reaches the runner: it stays with a broker on another machine. A register job of its own registers the run with GitHub OIDC, and the agent's job, which has no id-token, gets only a token for that one run (the run token, inference.md). plain and token-file registration also exist. The reusable workflow refuses the CLI's provider-API-key mode, which would serve the key on the runner.

Engines

gh-aw supports six engines: Copilot CLI (the default), Claude Code, Codex, Gemini CLI, Agy and Pi. Others, OpenCode and Goose among them, are unsupported samples, imported as Markdown engine definitions.

gh-aw marks Agy experimental and Gemini CLI soft-deprecated.

agentic-job drives every agent over ACP, with the commands in agents.toml and versions pinned where the policy and setup install them. The agents are Claude Code, opencode, Mistral Vibe and a scripted fake agent for tests. Codex and Gemini are not included. A new agent needs code, not a caller-supplied command.

Triggers and admission

Both implement role and bot checks, fork restrictions, slash commands, reactions and a status comment. Both consume a trigger label: agentic-job's activate job removes the label, and the run does not start if removal fails (events.md).

gh-aw has more triggers and guards: skip-if-match, search guards and spending guards. Its work queues, which gained trusted dispatch in v0.92.0, claim items for workers. The only time guard in agentic-job is a stop-after deadline (events.md). Cooldowns and per-user quotas were removed rather than shipped (plan.md, #466). A caller's concurrency group is not a quota. Claims and budgets belong to agent-board, described below.

Event text written to the task file has its control characters, format characters, ANSI escapes and line separators stripped. It is then capped and fenced (context.rs). URLs and mentions are left as written there. gh-aw's full sanitizer is applied to outputs instead, by a Rust port of gh-aw's collector.

Tools available to the agent

gh-aw gives the agent a GitHub MCP server, or the gh CLI through its proxy, and a gateway that holds the secrets of other MCP servers. mcp-scripts and Playwright are also available.

agentic-job gives the agent the job's own read-only token as GH_TOKEN (GitHub reads). It was chosen over gh-aw's CLI proxy (#112). That proxy's startup is Docker-specific, and its command sidecar could not safely run as the token holder. Its gateway forwards API paths, so it cannot carry git's HTTPS reads. The egress proxy refuses REST writes to GitHub. GraphQL POSTs pass, so GitHub's refusal of a read-only token is what stops a mutation.

[mcp.NAME] serves one remote MCP server through a loopback proxy that admits only an exact list of tools. The agent never holds that server's credential (mcp.md). The reusable workflow does not accept it yet. There are no stdio servers or Playwright.

Outputs

gh-aw's agent calls a safe-outputs MCP server, which validates each request as it is made. gh-aw has well over fifty types. Among them are Jira, Linear and Azure DevOps items, discussions, releases, workflow dispatch, code-scanning alerts and custom jobs.

In agentic-job, the agent writes JSONL to a file, and check validates it on another machine after the run, with a port of the same pinned collector. There are 24 types: 21 actions plus noop, missing_tool and missing_data (OUTPUT_TYPES). Each one is off until the bounds enable it, and the bounds cap the count of each and, for most actions, their targets (safe-outputs.md).

Additions of agentic-job's own:

  • Patches are parsed strictly as git reads them, under byte and file caps. gh-aw's protected-file list is extended with paths that are always protected.
  • Replacing a branch's commit series is off by default. Each commit is checked, and the push holds an exact head lease.
  • A completion checkpoint decides draft or ready.
  • Apply-time base and changed-path checks.

v0.92.0 ties gh-aw's apply to the validated bytes. Here, apply downloads the artifact by the ID and digest that check released.

Staged mode is gh-aw's staged mode as the apply-staged input (trying a caller without writes). gh-aw applies to GitHub, Jira, Linear and Azure DevOps. agentic-job applies to GitHub with gh-aw's handlers, and posts add_comment and create_pull_request to Forgejo with its own code (publishing to Forgejo).

Threat detection, memory and conclusion

Threat detection. gh-aw's detection job is on by default. It asks the workflow's engine for three flags (prompt_injection, secret_leak, malicious_patch) and supports pre- and post-steps for scanners. In the default warn mode, its reference says, both a detected threat and a detection failure still let reviewable outputs apply, annotated with a warning, and a push to a branch becomes a pull request for review. Strict mode blocks them.

agentic-job's detect job is off unless the repository variable AGENTIC_JOB_DETECT_MODEL is set (optional threat detection). It sends one tool-less request through the broker, asking for the same three flags. A flag, a malformed answer or a failed request blocks apply; there is no warn mode. It runs after the deterministic check, which refuses private keys and warns of other secret-shaped strings.

Memory. gh-aw has repo-memory, files kept on a Git branch and pushed after detection, and cache-memory in the Actions cache. agentic-job checks a handed-back memory.json against gh-aw's repo-memory defaults of 100 files and 100 KiB each, plus a 1 MiB total of its own. It does not yet store that file or restore it for the next run, though #119 is closed (safe-outputs.md, plan.md). It has no cache-memory.

Conclusion. gh-aw's conclusion job reports failures, as issues among other ways. With notify: comment or notify: reaction (the default is none), agentic-job's conclude job edits the run's one status comment, or reacts, with the outcome; a missing_data run gets a comment even without them. That covers the pull request or result link, check's refusal reason, a stop at a limit, a secret found or the missing_data reason. It opens no issues.

Steering. gh-aw's experimental steer: creates a steering issue for each run. agentic-job's [session] watch-item forwards new comments on the run's own item to the agent, and is off by default (harness.md). An operator can also give a run further prompts over the tailnet after its task's turn (interactive.md). That needs an agent job with a second user: the reusable workflow has a session input, but its run --runner-home refuses a session.

Audit. gh aw logs and gh-aw's audit tooling read run history. The offline agentic-job audit command reads one run's downloaded artifacts and reports tool errors, denials, refusals and estimated cost (auditing artifacts). Missing evidence does not count as success. OpenTelemetry export is not implemented.

Apply credentials. gh-aw computes the union of the permissions its output jobs need and can mint a GitHub App token. Here, apply uses the job token or SAFE_OUTPUTS_PAT, which three output types require. Minting a GitHub App token is not implemented (the apply job and its token).

Across repositories: gh-cao and agent-board

gh-cao runs from one control repository. A Go gh extension handles setup, authentication and diagnostics. Its Actions collect gh-aw run history into SQLite snapshots and publish a dashboard to GitHub Pages. Agents can query the evidence through gh cao query or a read-only MCP server. Campaigns package recurring work over a set of target repositories, under gh-aw's safe-output boundaries. A public catalog offers examples such as Repo Assist. Its installer verifies signed build provenance.

agentic-job runs one task on one machine. Across repositories, it offers only operator dispatch of a single task, whose item may live in another repository (dispatch.md). It has no campaigns, catalog or dashboard. Its sibling agent-board takes the coordinator's role, using a Projects v2 board as its record. Its design calls for the following:

  • reconcile(snapshot, policy, now) -> plan is a pure function.
  • One trusted job admits work, and records the claim before launch.
  • Budgets are reserved in advance, and unknown usage holds admission.
  • Each worker run goes through agentic-job.

That is a design. Its read commands work against a live board. Its README lists what does not work yet, such as reconcile repairs that are previewed but not applied. Where gh-cao starts by observing runs and adds operations later, agent-board starts with admission and has no dashboard beyond the board itself and the reports of its CLI, such as supervise health. hive.md compares it with another coordinator.

What to borrow

  • A cross-run evidence store. Gather agentic-job audit --json output from many runs and repositories into one queryable snapshot, as gh-cao does for gh-aw. Suggested issue: "audit: Aggregate run audits across repositories into one snapshot".
  • Read-only query access for a coordinator. Give agent-board's coordinator that snapshot through a read-only tool, as gh cao mcp does, instead of having it re-read job logs. Suggested issue (agent-board): "Query past run evidence read-only".
  • The model that answered. Since v0.92.0, gh-aw's Copilot engine refuses a run whose configured model was silently swapped for another. audit could compare the model named in the inference responses with the configured one. Suggested issue: "audit: Report a run served by a model other than the configured one".
  • Deterministic scanners in detection. gh-aw's detection post-steps run scanners such as TruffleHog alongside the model. A fixed, pinned scanner in detect would not depend on a model's judgement.
  • Memory store and restore. Adopt gh-aw repo-memory's branch layout and its compare-and-swap push so the checked memory.json reaches the next run. Suggested issue: "apply: Store checked memory on a branch and restore it to the next run".
  • A catalog of caller examples. gh-cao's catalog shows each campaign's scope and ceilings. The caller examples in .github/workflows/ could be listed with their bounds on the docs site.

cgwalters-forge/gh-aw is an earlier fork with a host-user runtime. It is not the code agentic-job runs. bootc-dev/gh-agentic-workflows uses stock gh-aw, not this project.