GitHub Agentic Workflows

Blog

Agent of the Day – May 26, 2026

[!NOTE] This post references historical Effective Tokens (ET) metrics. gh-aw now uses AI Credits (AIC) as the primary cost metric.

Every morning someone at GitHub opens their laptop and wonders: how well did the coding agents do yesterday? Did they ship? Did they stall? Did they create more work than they saved? These questions used to require manual spelunking through dashboards, cross-referencing merged PRs with author names, and guessing at patterns from vibes alone.

Not anymore.

Agent of the Day: Copilot Agent PR Analysis

Section titled “ Agent of the Day: Copilot Agent PR Analysis”

The Copilot Agent PR Analysis workflow runs daily at 6pm UTC with a single mandate: understand how GitHub’s own coding agents are performing in the wild. It watches copilot-swe-agent-authored pull requests, tracks their lifecycle from open to merge (or close), and surfaces patterns that would otherwise vanish into the noise of a busy repository.

Run 26415065259 on May 25th tells the story. Six minutes. Nineteen agent turns. Nearly a million tokens processed. And at the end, a GitHub Discussion summarizing everything the agents accomplished in the last 24 hours—merge rates, review turnaround, file change distributions, the works.

Workflow activity chart

What makes this run interesting isn’t just the output—it’s the mechanics underneath. The workflow starts by reading pre-fetched PR data from /tmp/gh-aw/agent/pr-data/copilot-prs.json, a file populated by an earlier step that batches GitHub API calls. This matters because API rate limits are a real constraint when you’re analyzing dozens of PRs daily. By front-loading the data fetch, the Claude Opus 4.7 model can focus on analysis rather than pagination logistics.

From there, the agent orchestrates across 16 different tool types. github-list_pull_requests and github-search_pull_requests pull in the raw data. github-get_file_contents adds context when the agent needs to understand what a PR actually changed. push_repo_memory persists metrics for trend analysis—because spotting a single bad day matters less than spotting a three-week decline. And create_discussion posts the findings where the team can actually see them.

The token economics tell their own story. Of the 947,148 tokens consumed, over 3 million effective tokens came from cache reads—a 63% hit rate. That’s not an accident. The workflow’s prompt structure and tool imports are designed to maximize cache reuse across runs. At $1.53 per execution, this is the kind of analysis that would cost ten times more if you rebuilt context from scratch each day.

Nineteen turns might sound like a lot, but the average inter-turn time of 19.8 seconds reveals something important: this agent is thinking, not thrashing. It’s making deliberate tool calls, waiting for responses, incorporating results, and planning next steps. The turn count reflects adaptive planning—the kind of reasoning that adjusts when it finds fewer PRs than expected or more activity in an unexpected repository corner.

PR #34947, merged just one day after this run, shows the feedback loop in action. Titled “Normalize copilot-session-insights discussion output hierarchy and disclosure,” it refined how the analysis gets presented—making the daily summaries easier to scan and the trend data more accessible. The workflow’s own output informed improvements to the workflow itself.

This is what continuous observability looks like for AI systems. Traditional software gets monitored with APM tools, error rates, and latency percentiles. But when your “software” is an autonomous agent making judgment calls about code, you need a different kind of visibility. You need to know: are the agents getting better at writing tests? Are they over-indexing on certain file types? Are their PRs sitting in review limbo, or are humans accepting them quickly?

The Copilot Agent PR Analysis workflow answers these questions daily, automatically, without anyone remembering to ask.


Curious about building workflows that watch your workflows? Explore the full gh-aw project at github/gh-aw—where agentic automation meets operational insight.

Agent of the Day – May 25, 2026

Some days the agent has nothing to report, and that’s exactly the point. I pulled up run 26407385057 this morning — 3.8 minutes, clean sweep. No violations. The Architecture Guardian looked at everything that landed in the last 24 hours and came back with a simple verdict: all changed files are within configured thresholds. In a codebase that moves this fast, that outcome doesn’t happen by accident.

The Architecture Guardian runs every weekday around 14:00 UTC. Its job is unglamorous and essential: scan every .go, .js, .cjs, and .mjs file touched in the last 24 hours (tests and vendor excluded) and ask whether the code is still structurally sound. It’s the kind of review that humans intend to do and quietly skip.

The mechanics are deliberate. A bash pre-step calls git log --since="24 hours ago" to build the file list. From there it computes line counts, function sizes, and export counts for each file, then runs go list ./... to catch import cycles before they calcify. Everything lands in /tmp/gh-aw/agent/arch-metrics.json. A lightweight sub-agent — violation-classifier, running on a small model — reads that JSON and applies a three-tier severity ladder:

  • BLOCKER — files exceeding 1,000 lines or any import cycle
  • ! WARNING — files over 500 lines or functions over 80 lines
  • INFO — files exporting more than 10 identifiers

If it finds something, it opens a GitHub issue with a structured report, tagged architecture, automated-analysis, and cookie. If not, it calls noop and gets out of the way. There’s also a guard against noise: a shared skip-if-issue-open.md import prevents the agent from filing duplicate issues when a violation is already being tracked.

Workflow activity chart

What stands out about today’s run isn’t the clean result — it’s the efficiency behind it. 121,425 input tokens processed, but 75,961 of those came from cache reads. That’s roughly 63% cache hit rate, which means the agent isn’t re-reading static context on every run; it’s built to reuse it. Total AI turns: 3. GitHub API calls: 4. The whole thing resolved in under 4 minutes with 307 output tokens — barely a paragraph’s worth of text to confirm the codebase is healthy.

That ratio matters. The Architecture Guardian isn’t trying to be clever. It’s trying to be cheap and reliable — the kind of automation you can run daily without flinching at the cost or the alert fatigue. Thresholds live in .architecture.yml, so teams can tune what counts as a violation without touching the workflow itself. The 2-day expiry on issues (via daily-issue-base.md) keeps the tracker clean even when something does slip through.

I’ve seen codebases where large files and tangled imports accumulate like sediment — not because anyone chose it, but because nobody had a lightweight, automatic way to notice. This workflow is that noticing mechanism. It doesn’t replace a thoughtful architecture review. It makes sure the small things don’t compound into the kind of mess that makes a real review feel hopeless.

Today it found nothing. Some days it will. Either way, it showed up.


Explore the full workflow and the rest of the gh-aw suite at github/gh-aw.

Weekly Update – May 25, 2026

It’s been a productive week in github/gh-aw — six pre-releases landed on top of the stable v0.74.8, culminating in v0.75.4 on May 24th. Here’s what shipped.

v0.75.4 is the headline pre-release of the week, rolling up improvements across the Codex engine, observability, and the compiler.

  • Codex harness hardened (#34459): The Codex engine now includes secret diagnostics, missing-key fast-fail, and --json streaming mode. If OPENAI_API_KEY is absent, you’ll get a clear error instead of a mysterious silence — and dev.md has been switched to Codex for a better developer experience.
  • OTel child SDK correlation (#34450): OTEL_RESOURCE_ATTRIBUTES are now injected into gh-aw workflows, so child processes using the OpenTelemetry SDK automatically inherit trace context. End-to-end distributed tracing just got a whole lot more useful.
  • Go 1.26 (#34318): The project has migrated to Go 1.26.
  • Gemini chunked threat-detection parsing (#34509): Gemini’s stream-json responses were sometimes arriving as fragmented chunks, causing detection to report a missing verdict. That’s fixed.
  • Codex default model set to gpt-5.3-codex (#34518): No more empty-string fallback crashes when engine.model is unset for the Codex engine.
  • First-class engine.permission-mode (#34525): Claude’s permission mode (acceptEdits vs bypassPermissions) was previously derived implicitly from bash wildcard detection, which could silently disable --allowed-tools enforcement. You can now set engine.permission-mode explicitly in your workflow frontmatter, giving you a clear, auditable security boundary.
  • add-wizard github.com org fallback for GHE (#34526): Shorthand workflow specs from public sources were resolving on the active GHE host and returning confusing 404s. The resolver now falls back to github.com for org-less shorthands.
  • PR Sous Chef startup crash context (#34524): AWF startup failures were showing up as generic Copilot termination with stdout/stderr: undefined. Failure context is now surfaced correctly.
  • FAQ condensed ~21% (#34488): Verbose multi-paragraph answers have been collapsed into tight, scannable responses. Less scrolling, same information.

The workflow that turns your codebase’s bad habits into laws.

This week linter-miner went on a deep dive through the gh-aw codebase, mining for antipatterns ripe for static analysis enforcement. It zeroed in on the fmt.Fprintln(w, fmt.Sprintf(...)) redundancy — a pattern that allocates an intermediate string, then allocates again to append a newline, when a single fmt.Fprintf call would do the job cleanly. The result: a brand-new fprintlnsprintf linter, complete with a bundle of existing violations for the PR reviewer to clean up. It took 39 turns and 10.8 minutes, burning through over a million tokens with the dedication of an engineer who really cares about unnecessary heap allocations.

Notably, it failed twice before nailing it on the third run — apparently even automated linter writers need a couple of drafts before the code compiles.

Usage tip: Linter miner is most valuable right after a refactor or new abstraction lands — that’s when consistent usage patterns (and consistent antipatterns) start to crystallize, and the window to enforce them early is at its widest.

View the workflow on GitHub

Check out v0.75.4 or the stable v0.74.8 — and as always, contributions and feedback are welcome in github/gh-aw.

Agent of the Day – May 20, 2026

You know that sinking feeling when your CI pipeline kicks off a full build-test-deploy cycle because someone fixed a typo in the README? Or when your security scanner churns through every line of code at 2 AM, finds nothing new, and emails you a 47-page report that’s identical to yesterday’s?

Yeah, we’ve all been there. The robot dutifully did its job. You dutifully archived the notification. Nobody won.

Enter Architecture Guardian, a scheduled workflow that’s learned the ancient DevOps virtue of knowing when not to run.

This workflow runs every weekday around 14:00 UTC with a straightforward mission: scan Go and JavaScript source files for architecture drift, naming violations, or structural anti-patterns that might’ve slipped through code review. It’s the kind of governance check that should run regularly—but doesn’t need to re-analyze the entire codebase when nothing has changed.

On run 26171885477, Architecture Guardian demonstrated exactly how a smart agent should behave: it showed up, looked around, realized there was no work to do, and gracefully bowed out.

The Smart Skip: 5.5 Minutes of Doing Nothing (Efficiently)

Section titled “The Smart Skip: 5.5 Minutes of Doing Nothing (Efficiently)”

Here’s what happened under the hood:

The workflow spun up, spent three agent turns checking for recent changes, and concluded: zero Go or JavaScript files modified in the last 24 hours. Instead of proceeding with the full architecture scan—parsing files, running static analysis, generating reports—it called safeoutputs.noop with a clear message:

“No Go or JavaScript source files changed in the last 24 hours. Architecture scan skipped.”

Total runtime? 5.5 minutes. Token usage? 123k—mostly spent confirming the skip was valid. No unnecessary compute, no noise in the logs, no pointless notifications.

Compare that to a naïve scheduled job that runs the full analysis every single day regardless of activity. Over a month of weekdays (roughly 22 runs), this skip-when-idle logic could save hours of compute time and thousands of tokens on quiet days.

The Read-Only Posture: Analysis, Not Automation Chaos

Section titled “The Read-Only Posture: Analysis, Not Automation Chaos”

Architecture Guardian operates in read-only mode—it never writes back to GitHub, never auto-fixes violations, never opens PRs. It’s pure analysis. When it does find issues, it surfaces them cleanly for human review. When it finds nothing (or nothing new), it stays silent.

This run hit some network friction—3 blocked requests out of 8 total, a 38% block rate—but still completed successfully. The agent adapted, worked within constraints, and delivered its finding: nothing to report.

Two anomalous event patterns flagged during the run suggest the reliability monitoring is working as intended, catching edge cases for future iteration.

Why This Matters: Respecting Developer Time

Section titled “Why This Matters: Respecting Developer Time”

The real win isn’t the 5.5 minutes saved on one run. It’s the cognitive load reduction. When your scheduled jobs only notify you about actual changes, you start trusting them again. The alert fatigue drops. The “mark all as read” reflex fades.

Architecture Guardian isn’t trying to impress you with how much work it can do. It’s trying to impress you by doing only the work that matters.

That’s automation maturity.

Architecture Guardian workflow metrics


Want workflows that know when to quit while they’re ahead? Check out the gh-aw project on GitHub and see how agentic workflows can respect your time as much as your architecture.

Agent of the Day – May 15, 2026

Every open-source repo has the same invisible tax: someone has to watch the door. Label the PR. Check if the commenter is a member or an outsider. Hide the policy violation before it spreads. Flag the ambiguous case for a human. It’s repetitive, important, and easy to miss at 2 AM when CI is green and you’re trying to ship.

That’s the gap the AI Moderator workflow fills — automatically, on every event, before a human even opens their notifications.


The AI Moderator is a Codex-powered agentic workflow in the github/gh-aw repository. It fires on pull requests, new issues, and comments — running a structured investigation each time to determine who’s knocking, what they brought, and what action to take. Label it. Hide it. Escalate it. Or stand down.

It’s not a simple rule-based bot. It reasons.

On a recent run — Actions run 25924881974 — the agent woke up when PR #32406 landed: a work-in-progress branch titled “Experiment with output format in daily compiler quality” from copilot/ab-advisorexperiment-output-format. Sixteen turns later, it had done its job.

The agent didn’t guess. It looked things up.

It started by orienting itself — calling github___get_me to confirm its own identity, then github-search_repositories to verify the repo context it was operating in. From there it fanned out: github-list_branches, github-list_tags, github-list_releases, github-get_teams, github-get_team_members. It was building a picture of who belongs here and what the repo looks like right now.

Then it turned to the PR itself. It pulled the PR details with github___pull_request_read, searched related issues with github___search_issues and github___search_pull_requests, reviewed the commit history via github___list_commits, and read any linked issue context through github-issue_read. That’s a broad sweep — the kind a human reviewer would do informally, but inconsistently. The agent did it every time, in the same order, with a logged record of each step.

The conclusion: action_required. The agent applied labels through safeoutputs-add_labels, hid at least one comment using safeoutputs___hide_comment, and raised a flag with safeoutputs-report_incomplete to signal that follow-up was needed. Where checks passed cleanly, it called safeoutputs-noop — explicit confirmation that nothing warranted action, not just silence.

The audit system tracks behavioral baselines. On the same day, a reference run (25924730956) completed with zero turns and a success conclusion. This run took 16. The delta was flagged automatically as a turns_increase requiring review.

That flag matters. It means the system caught a meaningful deviation in how the agent behaved — not a failure, but a signal worth inspecting. Did the PR have unusual characteristics? Was the team membership lookup more complex than usual? The audit trail is there. The observation is already logged.

This is what makes agentic workflows different from scripts: the behavior changes with the input, and the monitoring has to account for that.

Community moderation is one of those problems where the cost of under-investing is invisible until it isn’t. A missed label means a misrouted PR. A comment that should have been hidden lingers. An external contributor gets treated the same as a maintainer when they shouldn’t.

The AI Moderator closes that gap without requiring a human to be on-call for it. It checks team membership — not just assumed from a username, but verified against github-get_team_members. It applies structured outputs through the safeoutputs interface, which means every action is auditable. And when it can’t confidently resolve a case, it says so explicitly via report_incomplete, rather than silently doing nothing.

Fast, too. This run completed in seconds.

The workflow is part of the github/gh-aw agentic workflows project — a growing collection of Codex-powered agents built to automate the unglamorous parts of software engineering. If your team maintains a repository and you’re tired of playing gatekeeper manually, this is a good place to start.

Head to github.com/github/gh-aw to see the workflows, read the specs, and explore what’s already running in production.


Agent of the Day is a recurring look at agentic workflows built and run inside the GitHub engineering org.