AI & Agents
Agentic Workflows
GitHub Agentic Workflows (gh-aw) let you author an agent task as a markdown file — with YAML frontmatter — under .github/workflows/. GitHub compiles that source into a <name>.lock.yml GitHub Actions workflow, which is what actually runs.
CodeCargo detects and catalogs these files so admins get a consolidated view of them across the organization — and imports each agentic source into the Agent Catalog as a GitHub Actions-engine agent. Once an admin reviews and publishes an imported agent, CodeCargo can trigger its compiled workflow directly, from an Agentic Job or a Dispatch plan step. How running works — dispatch mechanics, the compiled-state badge, and what "the prompt is not delivered" means — is covered in Agent Engines → GitHub Actions.
Govern + Invoke, not author
CodeCargo classifies agentic workflows, surfaces their governance metadata, and can invoke published ones — but it never authors, edits, or compiles gh-aw files, and runtime tool enforcement remains GitHub's. Compiling is done with the gh aw CLI.
How Detection Works
During an organization workflow sync, CodeCargo scans for gh-aw source files (.md), their compiled .lock.yml output, and shared MCP configuration files (shared/*.md), pairing each source file with its compiled lock file by basename. Each file is classified into one of four types:
| Type | Description |
|---|---|
| Standard | A regular GitHub Actions workflow (not gh-aw) |
| Agentic source | The markdown source that defines an agentic workflow |
| Agentic lock | The compiled .lock.yml Actions workflow generated from a source file |
| Shared MCP | Shared MCP server configuration referenced by agentic workflows |
If a gh-aw file can't be parsed, it's still cataloged — marked as unparsed — rather than being dropped from the scan or failing it outright.
gh aw compile also writes .github/workflows/agentics-maintenance.yml (or .yaml) from the expires and safe-outputs.noop settings across the repository's agentic workflows. CodeCargo catalogs that file as an agentic lock, with no paired source. Its Agentic tab is titled Generated maintenance workflow: to change the file, edit those settings in the sources and recompile. A workflow you maintain yourself at that path stays a standard workflow.
Governance Metadata
For each agentic workflow, CodeCargo extracts governance-relevant metadata from the frontmatter, including:
- Engine / model — which AI engine and model the workflow declares
- MCP servers — declared servers, their transport, read-only status, and allowed tools (secret key names only — CodeCargo never stores or displays secret values)
- Tool grants — which tools the workflow is permitted to use
- Safe outputs — declared safe-output configuration
- Network config — declared network access
- Timeout and concurrency — execution limits declared in the frontmatter
Any frontmatter fields CodeCargo doesn't yet recognize are preserved as opaque passthrough data rather than discarded.
Viewing Agentic Workflows
In the Workflows inventory (organization or project level), agentic files carry the gh-aw mark next to their name and a badge in the Traits column: Agentic for a source file, Compiled for its lock file, and Shared MCP for shared configuration. Filter the Traits column by Agentic or Standard to narrow the list.
Opening an agentic workflow's detail page adds an Agentic tab alongside the standard workflow detail tabs, showing the extracted engine, model, MCP server, tool grant, and network metadata for that workflow.
Guardrail Evaluation Scope
Workflow Compliance evaluates standard GitHub Actions workflows only. Agentic sources, compiled locks, and shared MCP files are cataloged but not scored. They are left out of coverage and the Compliance Workflows tab. On the workflow detail page the Compliance tab is hidden, and the guardrail column in the Workflows inventory reads Not applicable.
A compiled lock is generated from its markdown source. Edit that source and recompile — you can't run an evaluation or a remediation on the lock, including from Dispatch.
