Investigate: how g1t runs GitHub Agentic Workflows (write-up before building) #186

Investigate GitHub Agentic Workflows and decide how g1t should support them, then write up the plan. Investigation first: the deliverable is a recommendation the owner can approve, with the shape of the build. Write no code until the owner approves. If you prototype, do it in your own worktree.

What they are (GitHub, public preview as of 2026-10)

Overview: https://docs.github.com/en/copilot/concepts/agent-capabilities/agent-powered-workflows-and-operations/about-github-agentic-workflows Full reference: https://github.github.com/gh-aw/ (engines, security architecture, cost management, frontmatter reference).

• A workflow is a markdown file. Its YAML frontmatter has on: triggers such as daily, permissions:, engine: (copilot | claude | codex | gemini), tools: (MCP servers and GitHub toolsets among them), network:, safe-outputs: and max-ai-credits:. The body is natural language that the agent follows.
• gh aw compile turns it into a hardened .lock.yml Actions workflow, and both files are committed. It runs as an ordinary Actions run.
• Security: read-only by default. Every write (issue, comment, pull request, label) goes through a declared safe output. A separate job holds the credentials the agent never sees, and it applies the writes after threat detection scans what the agent proposed. The agent runs in a firewalled container with a network allowlist.
• Cost: Actions minutes plus inference (AI Credits, 1 AIC = $0.01), capped per run. gh aw logs and gh aw audit RUN-ID report it.
• Uses: issue triage, CI failure investigation, daily status reports, keeping docs in sync with code, test coverage.

Why it matters

Teams moving from GitHub will bring these files. "An agent on a trigger that can write only through reviewable outputs" is also where g1t is heading: agents as members, and every change through pull requests and checks. g1t should run these workflows, and run them better, because its sessions, claims, decisions and merge queue are the record GitHub lacks.

Principles to design within

• g1t runs no models of its own. The thinking is done by the workspace's own AI provider (-/ai) or by the person's own agent.
• There is no model picker and no "number of agents" control: g1t routes the model.
• Checks are ordinary CI. .g1t/workflows report checks on pull requests, branch protection picks the required ones, and agents revise until they pass. There are no agent-only acceptance gates.
• The session is the unit of agent work. A work item exists once the work is a change others should know about.
• Runner work runs in host-proof sandboxes.
• Hosted runners act like GitHub's: standard-4 machines, and no network allowlists for ordinary CI.
• Billing: every cost is metered and passed through with overhead. There is no per-seat pricing, and spend limits apply.

Read first

• g1t Actions: crates/actions (workflow schema, syntax, cron.rs), services/actions, apps/docs/src/content/docs/guides/actions.md. Workspace managed workflows exist (MCP workflow → add_managed_workflow).
• Agents g1t already starts: services/integrations/src/agent_sessions.rs. It runs Claude Managed Agents on the workspace's own Anthropic key, records each run as a g1t session, and keeps the token in a vault the model never sees. Guides: ai.md, bring-your-own-agent.mdx, guardrails.md, sessions.md.
• The sibling design, Routines (#198), overlaps with this: both are an agent on a trigger writing through reviewable outputs. Say whether one should be built on the other.

Answer, with evidence from the code

1. Can g1t run a compiled .lock.yml as it is today? Run gh aw's compiler on its own examples, parse the output with crates/actions, and list every construct that fails or is unsupported. Also say where g1t looks for workflows: .g1t/workflows, and .github/workflows on import.
2. Should g1t compile the markdown itself (accept .md workflows natively, with no lock file), run gh aw's compiled output, or do both? Recommend one.
3. Engines: map engine: onto what g1t has. Claude could run through the workspace's own provider and the agent_sessions machinery. Copilot can't run here, so say what happens to engine: copilot files on import.
4. Safe outputs: say which ones map onto existing writes (issues, comments, pull requests through the draft-PR-with-fork flow, labels), and where the separate credentialed job lives. Map threat detection onto crates/scan (secrets, redaction) and guardrails.
5. Sandbox and network: how runner sandboxes (standard-4, the egress proxy) provide the firewall and allowlist, and how an agentic run differs from ordinary CI, which has no allowlist.
6. Record: each run as a g1t session (harness, title, entries), linked to its Actions run and to whatever it opened.
7. Cost: how inference on the workspace's own key and runner minutes show up in billing, and a per-run cap like max-ai-credits.
8. Size: phases that each ship on their own, with what "done" means for each.

Deliverable

A write-up the owner can read and share, published as an artifact, that answers the questions above and makes a recommendation. Then stop and ask before building. Open build work items only for the directions the owner approves.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.