GitHub Agentic Workflows

I noticed this unusual line in go.mod and got curious why it is using replace for this (typically you would `go get github.com/Masterminds/semver/v3@v3.4.0` instead).

  replace github.com/Masterminds/semver/v3 => github.com/Masterminds/semver/v3 v3.4.0

I found this very questionable PR[0]. It appears to have been triggered by dependabot creating an issue for a version upgrade -- which is probably unnecessary to begin with. The copilot agent then implemented that by adding a replace statement, which is not how you are supposed to do this. It also included some seemingly-unrelated changes. The copilot reviewer called out the unrelated changes, but the human maintainer apparently didn't notice and merged anyway.

There is just so much going wrong here.

[0] https://github.com/github/gh-aw/pull/4469

Github should focus on getting their core offerings in shape first.

I stopped using GH actions when I ran into this issue: https://github.com/orgs/community/discussions/151956#discuss...

That was almost a year ago and to this date I still get updates of people falling into the same issue.

> GitHub Agentic Workflows deliver this: repository automation, running the coding agents you know and love, in GitHub Actions, with strong guardrails and security-first design principles.

GitHub Actions is the last organization I would trust to recognize a security-first design principle.

I am somehow close to what MSFT and GitHub are doing here, mostly because I believe it is a great idea, and I am experimenting on it myself.

Especially on the angle of automatic/continuos improvement (https://github.github.io/gh-aw/blog/2026-01-13-meet-the-work...)

Often code is seen as an artifact, that it is valuable by itself. This was an incomplete view before, and it is now a completely wrong view.

What is valuable is how code encode the knowledge of the organization building it.

But what it is even more valuable, is that knowledge itself. Embedded into the people of the organization.

Which is why continuos and automatic improvement of a codebase is so important. We all know that code rot with time/features requests.

But at the same time, abruptly change the whole codebase architecture destroys the mental model of the people in the organization.

What I believe will work, is a slow stream of small improvements - stream that can be digested by the people in the organization.

In this context I find more useful to mix and control deterministic execution with a sprinkle of intelligence on top. So a deterministic system that figure out what is wrong - with whatever definition of wrong that makes sense. And then LLMs to actually fix the problem, when necessary.

Alternative, less phishy link: https://github.com/github/gh-aw

This is on GitHub's official account. For some reason GitHub is deploying this on GitHub pages without a different domain?

What timing. I used the whole weekend building a CI agentic workflow where I can let CC run wild with skip-permissions in isolated vms while working async on a gitea repo. I leave the CC instance with a decent sized mission and it will iterate until CI is green and then create a PR for me to merge. I'm moving from talking synchronously to one Clade Code to manage a small group of collaborating Claudes.

This is an extension for the gh cli that takes markdown files as input and creates github actions workflow files from them. Not just any workflow files, but 1000-line beasts that you'll need an LLM to explain what they do.

I tried out `gh aw init` and hit Y at the wrong prompt. It created a COPILOT_GITHUB_TOKEN on the github repo I happened to be in presumably with a token from my account. That's something that really should have an extra confirmation.

Stuffing agents somewhere they don't belong rather than making the system work better with the agents people already use. Obvious marketing driven cash grab.

The landing page doesn't make it clear to me what value this is providing to me (as a user). I see all of these things that I can theoretically do, but I don't see (1) actual examples of those things (2) how this specific agentic workflow helps.

I find this confusing: I can see the value in having an LLM assist you in developing a CI/CD workflow, but why would you want one involved in any continuous degree with your CI/CD? Perhaps it’s not as bad as that given that there’s a “compilation” phase, but the value add there isn’t super clear either (why would I check in both the markdown and the generated workflow; should I always regenerate from the markdown when I need changes, etc.).

Given GitHub’s already lackluster reputation around security in GHA, I think I’d like to see them address some of GHA’s fundamental weaknesses before layering additional abstractions atop it.

This is a solid step forward on execution safety for agentic workflows. Permissions, sandboxing, MCP allowlists, and output sanitization all matter. But the harder, still unsolved problem is decision validation, not execution constraints. Most real failures come from agents doing authorized but wrong things with high confidence. Hallucinations, shallow agreement, or optimizing for speed while staying inside the permission box.

I’m working on an open source project called consensus-tools that sits above systems like this and focuses on that gap. Agents do not just act, they stake on decisions. Multiple agents or agents plus humans evaluate actions independently, and bad decisions have real cost. This reduces guessing, slows risky actions, and forces higher confidence for security sensitive decisions. Execution answers what an agent can do. Consensus answers how sure we are that it should do it.

I feel like this solution hallucinated the concept of Workflow Lock File (.lock.yml), which is not available in Github Actions. This is a missing feature that would solve the security risk of changing git tag references when calling to actions like utility@v1

I tested it a bit yesterday, and it looks good—at least from a structural perspective. Separating the LLM invocation from the apply step is a great idea. This isn’t meant to replace our previous deterministic GitHub Actions workflow; rather, it enables automation with broader possibilities while keeping LLM usage safer.

Also, a reminder: if you run Codex/Claude Code/whatever directly inside a GitHub Action without strong guardrails , you risk leaking credentials or performing unsafe write actions.

I think it is funny they all these companies are spending a ton and racing to have a AI story. It’s almost like none of the executives understand AI.

If you are changing your product for AI - you don’t understand AI. AI doesn’t need you to do this, and it doesn’t make you a AI company if you do.

AI companies like Anthropic, OpenAI, and maybe Google, simply will integrate at a more human leave and use the same tools humans used in the past, but do so at a higher speed, reliability.

All this effort wasted, as AI don’t need it, and your company is spending millions maybe billions to be an AI company that likely will be severely devalued as AI advances.

I want to see where we're at in 2 years, because these last couple of months have been pretty chaotic (but in a good sense) in terms of agents doing things with other agents. I think this is the real wake-up-call, that these dumb and error-prone agents can do self-correcting teamwork, which they will hopefully do for us.

Two years, then we'll know if and how this industry has completely been revolutionized.

By then we'd probably have an AGI emulator, emulated through agents.

I’d appreciate if they fix the log viewer in GH actions. That would have a larger impact, by far.

It looks like it does have an MCP Gateway https://github.com/github/gh-aw-mcpg so I may see how well it works with my MCP server. One of the components mine makes are agent elements with my own permissioning, security, memory, and skills. I put explicit programatic hard stops on my agents if they do something that is dangerous or destructive.

As for the domain, this is the same account that has been hosting Github projects for more than a decade. Pretty sure it is legit. Org ID is 9,919 from 2008.

Does this products directly compete with GitHub Models [1]?

[1] https://github.com/marketplace?type=models

Link to github.com: https://github.github.com/gh-aw/

Somehow i want to ask what's the actual job of those former software engineers. Agents everywhere, on your local machine, in the pipeline, on the servers, and they are doing everything. Yes, the specs also.

Wasnt GitHub supposed to be doing a feature freeze while they move to Azure?(1) They certainly could use it as their stability has plummeted. After moving to a self-hosted Forgejo I'll never go back. My UI is instant, my actions are faster than they ever were on GH (with or without accelerators like Blacksmith.sh), I dont constantly get AI nonsense crammed into my UI, and I have way better uptime all with almost no maintenance (mostly thanks to uCore)...

GH just doesnt really have much a value proposition for anything that isnt a non-trivial, star gathering obsessed, project IMO...

1: https://thenewstack.io/github-will-prioritize-migrating-to-a...

Edit: typo

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)

Surely this won't be a security nightmare.

Soon: AgentHub Git Workflows

Go: check

YAML: check

Markdown: check

Wrong level of abstraction: check

Shit slop which will be irrelevant in less than a year time: check

Manager was not PIP'd: check

since generation is not deterministic, how do they verify the lock file?

Apologies for the bad language but this can fuck off. They need to fix everything before pasting more shit on top.

I’m getting to the point of throwing Jenkins back in it’s that bad.

GitHub gives git a bad name and reputation.

This is insane stuff. Why are they pushing this nonsense on developers when the real money is in surveillance and web indexing?

People like Nadella must think that developers are the weakest link: Extreme tolerance for Rube Goldberg machines, no spine, no sense of self-protection.

I'll cancel my paid GitHub account though.

GitHub fix your uptime then come talk to me about agentic workflows

Ah yes, lovely. That's what I want in my CI/CD...hallucinations that then churn through I don't know how many tokens trying to "fix it".

Not confirmed that it's by Github, phishy domain.

[dead]