https://github.github.io/gh-aw/#gallery down the page has a list of concrete applications

For examplpe, https://github.github.io/gh-aw/blog/2026-01-13-meet-the-work... has several examples of agentic workflows for managing issues and PRs, and those examples link to actual agentic workflow files you can read and use as a starting point for your own workflows.

The value is "delegate chores that cannot be handled by a heuristic". We're figuring out how to tell the story as we go, appreciate the callout!

Hello HN! The Agentic Workflows project has been on the githubnext.com website for a while, and we recently moved the documentation and repo over to the `github` org.

This is early research out of GitHub Next building on our continuous AI [1] theme, so we'd love for you to kick the tires and share your thoughts. We'd be happy to answer questions, give support, whatever you need. One of the key goals of this project is to figure out how to put guardrails around agents running in GitHub actions. You can read more about our security architecture [1], but at a high level we do the following:

- We run the agent in a sandbox, with minimal to no access to secrets

- We run the agent in a firewall, so it can only access the sites you specify

- We have created a system called "*safe outputs*" that limits what write operations the agent can perform to only the ones you specify. For example, if you create an Agentic Workflow that should only comment on an issue, it will not be able to open a new issue, propose a PR, etc.

- We run MCPs inside their own sandboxes, so an attacker can’t leverage a compromised server to break out or affect other components

We find that there's something very compelling about the shape of this — delegating chores to agents in the same way that we delegate CI to actions. It's certainly not perfect yet, but we're finding new applications for this every day and teams at GitHub are already creating agentic workflows for their own purposes, whether it's engineering or issue management or PR hygiene.

> Why is it on github.github.io and not github.com?

GitHub Pages domains are always ORGNAME.github.io. Now that we've moved the repo over to the `github` org, that's the domain. When this graduates from being a technology preview to a full-on product, we imagine it'll get a spot on github.com/somewhere.

> Why is GitHub Next exploring this?

Our job at GitHub is to build applications that leverage the latest technology. There are a lot of applications of _asynchronous_ AI which we suspect might become way bigger than _synchronous_ AI. Agentic Workflows can do things that are not possible without an LLM. For example, there's no linter in existence that can tell me if my documentation and my code has diverged. That's just one new capability. We think there's a huge category of these things here and the only way to make it good is to … make it!

> Where can I go to talk with folks about this and see what others are cooking with it?

https://gh.io/next-discord in the #continuous-ai channel!

[1] https://githubnext.com/projects/continuous-ai/

[2] https://github.github.io/gh-aw/introduction/architecture/

(edit: right I forgot that HN doesn't do markdown links)

Nope, it uses Copilot CLI under the hood (with your token)

Any github pages site is, by default, ORGNAME.github.io.

We recently moved this out of the githubnext org to the github org, but short of dedicating some route in github.com/whatever, github.github.io is the domain for pages from the github org.

Also espressif RISC V mcu's like the ESP32-C3 and -C6 are fantastic.

Some Nordic MCUs are easy too, specifically nrf52840.

Have fun!