GitHub previews Agentic Workflows that run LLM-driven tasks inside GitHub Actions

agentic workflows are being domesticated by actions

GitHub's Agentic Workflows preview has the kind of headline that makes people reach for the wrong conclusion. Natural language Markdown can turn into GitHub Actions workflows. That sounds like "the YAML is going away." I do not think that is the interesting story. The interesting story is that the agent is not escaping the workflow engine. It is being pulled into it. That matters because a lot of agent demos still pretend the future is a smart process floating above the boring machinery: the agent understands the request, edits the repo, runs some commands, and hands back a neat result. Nice demo. Very clean. Production engineering is not clean like that. Production engineering has permissions, logs, runner groups, approval rules, secrets, firewalls, budgets, weird old repositories, compliance questions, and someone who has to explain what happened when the helpful automation did something surprising. So the shape of Agentic Workflows is useful precisely because it is less magical than the demo version. GitHub is putting agents inside the same CI/CD world that already carries a lot of organizational trust. That is the right direction. markdown is not the control plane The cute part is that a developer can describe a workflow in Markdown and have GitHub turn that into standard Actions YAML. That is useful. YAML is not a personality test, and most teams have better things to do than memorize every Actions syntax edge case. But Markdown is only the input surface. The control plane is still Actions. That distinction matters. If the generated workflow is a normal Actions workflow, then all the existing machinery can still matter: repository permissions, runner selection, logs, environments, approvals, branch protection, organization policy, and whatever security controls the company already built around CI. This is where I get more optimistic about agentic tooling. The bad version of agents asks every organization to trust a new, parallel execution model because the model can write a nice plan. The better version lets the agent help create and operate within the workflows the organization already governs. It is not "throw away CI because agents are smarter now." It is "let the agent speak CI." defaults are doing real work The preview details are full of boring words that are actually important: read-only defaults, sandboxed containers, firewall rules, output validation, and threat detection. That is not launch-page decoration. That is the product admitting the hard part. An agentic workflow is not just a script. It is automation that may interpret instructions, call tools, inspect a repository, generate files, and decide what to do next. If that runs with broad permissions and a casual network boundary, the organization has not gained an agent platform. It has created a very persuasive CI job with too much reach. The read-only default is especially important. Write access should be a decision, not an accident. Secret access should be a decision. Network access should be a decision. The ability to open pull requests, comment on issues, trigger deployments, or modify generated artifacts should be visible in the workflow definition and reviewable by people who own the repository. This is the same lesson we learned with CI, package registries, browser extensions, cloud IAM, and Kubernetes admission controls. The default boundary decides how many bad ideas become incidents. Agents make the boundary more important, not less. the old machinery keeps winning There is a funny pattern in AI developer tools right now. The front of the product gets new language: agents, tasks, skills, autonomy, natural language, context, reasoning. The back of the product keeps rediscovering old infrastructure: queues, tokens, logs, approvals, sandboxes, spend limits, role-based access, and audit trails. That is not hypocrisy. That is maturity. Agentic Workflows using GITHUB_TOKEN instead of long-lived personal access tokens is a good example. Nobody should be excited about passing PATs around as the foundation for organizational automation. It works until it does not. Then you get the classic mess: unclear ownership, overbroad scope, difficult rotation, and an audit trail that points to a person when the real actor was a workflow. GITHUB_TOKEN is not glamorous. It is exactly the kind of boring identity primitive agent systems need. Same for organization billing, cost centers, and per-run token caps. People want to talk about whether agents can finish bigger tasks. Fine. But if a company is going to run agentic workflows across many repositories, the questions become painfully practical: Who is paying for this run? Which team owns the budget? What happens when the token cap is reached? Can we distinguish one expensive useful workflow from ten noisy ones? Can a platform team shut this down without begging every repo owner? That is what real adoption looks like. Not one amazing workflow. A hundred normal workflows that need ownership. this is not just nicer workflow generation It would be easy to treat Agentic Workflows as a better workflow generator. "Describe what you want, get YAML." That is probably useful on day one. But the more interesting use case is not replacing copy-paste from documentation. It is creating a higher-level path for routine engineering automation. Imagine a repository owner saying: "Every Friday, inspect stale dependencies, propose safe upgrades, run the standard test matrix, and open a draft PR only when the change is low risk." Or: "When a flaky test is labeled, gather recent failures, isolate the likely files, and draft an investigation issue with links to logs and suspected causes." Or: "Before release, check docs, changelog, migration notes, and examples against merged pull requests, then prepare a reviewable patch." These are not huge science fiction tasks. They are the annoying glue work around software delivery. The important part is that the output still lands in a governed workflow. The agent does not become a mysterious background employee. It becomes a workflow step with logs, limits, identity, and review. That is less romantic. It is also much more likely to survive contact with a real engineering organization. approval is not a lack of trust GitHub also changed the posture for github-actions[bot] pull requests so they can run workflows after approval by someone with write access. That matches the same general direction as Copilot-generated pull requests. This is another boring rule that I like. Automation needs to be able to test its work. A bot-created PR that cannot run CI is often useless. But a bot-created PR that automatically reaches every secret and deployment-capable workflow is a different problem. The reasonable middle is human approval at the boundary where risk changes. That does not mean every agent PR needs a committee. It means the system should know when generated work is about to enter a more privileged part of the pipeline. The human is not there to admire the diff. The human is accepting the blast radius. This is the part agent tooling needs to get comfortable with. Approval gates are not anti-agent. They are how autonomous work becomes acceptable inside shared systems. what i would watch If I were evaluating this inside a company, I would not start by asking whether the generated YAML is pretty. I would ask where the policy shows up. Can platform teams define which runner groups agentic workflows may use? Can they set token caps by organization, repository, or workflow class? Can security teams see which workflows requested write access? Can logs explain what the agent read, generated, validated, and refused to do? Can repository owners understand the difference between a normal Actions failure and an agent decision that stopped early? The generated workflow is only one artifact. The evidence around the run is the part that will matter later. Six months from now, someone will ask why a workflow opened a PR, why it skipped a repo, why it spent more than expected, or why it had permission to touch a file. If the answer is "the agent decided," the platform failed. If the answer is in the workflow definition, run logs, approval history, token budget, and linked pull request, then we are at least playing the right game. the punchline Agentic Workflows are interesting because they do not replace GitHub Actions. They make Actions the place where agents become normal engineering automation. That is the part I would bet on. The future is not a swarm of free-floating agents doing whatever the prompt suggests. The future is agents squeezed through boring machinery: workflow engines, scoped tokens, runner policies, sandboxes, approvals, logs, budgets, and reviewable outputs. This will annoy people who want the AI story to stay magical. Good. Software delivery is already full of powerful automation. The lesson was never "make the automation as unconstrained as possible." The lesson was to make useful automation observable, governable, and boring enough that teams can depend on it. Agentic workflows are just the next version of that lesson. The Markdown prompt is the shiny part. The Actions control plane is the story. references GitHub Changelog: GitHub Agentic Workflows is now in public preview GitHub Changelog: Agentic workflows no longer need a personal access token GitHub Changelog: Bot-created pull requests can run workflows if approved GitHub Changelog: GitHub Actions minimum version enforcement timeline for self-hosted runners To test my projects, I use Railway. If you want $20 USD to get started, use this link.

6 hours ago

GitHub Actions is becoming the agent runtime

GitHub Agentic Workflows is now in public preview, and the most interesting part is not that agents can write workflow logic from Markdown. The interesting part is where GitHub chose to put them. Agentic Workflows are defined in natural language Markdown, then compiled into standard GitHub Actions YAML. They run through existing runner groups, organization policies, sandboxes, firewalls, output validation, and threat detection. A day later, GitHub also removed the need for a personal access token, letting these workflows use the built-in GITHUB_TOKEN, bill AI credits to the organization, and cap token usage per workflow run. That sounds like a set of product details. It is also a pretty clear architectural statement: the future of agent automation looks less like chat and more like CI/CD with a reasoning step inside it. And honestly, that is probably the right direction. the YAML was never the hard part There is an easy way to read this release: "AI can now write Actions workflows for you." That is the least interesting version. Writing YAML is annoying, but it is not the hard part of production automation. The hard part is deciding what the automation is allowed to do, where it runs, what secrets it can reach, how it is reviewed, how it is billed, and who owns the failure mode when it does something strange at 2 a.m. We already learned this with CI. The workflow file is just the visible artifact. The real system is branch protection, runner isolation, required checks, environments, secrets, approvals, logs, retry behavior, permissions, and the long tail of organizational defaults. Agents do not make that boring machinery obsolete. They make it more important. If an agent is going to triage issues, analyze CI failures, update documentation, or propose changes across repositories, I do not want it floating around as a magical side channel. I want it inside the same governance layer we already use for automation. That is what makes the Actions angle matter. actions is becoming an agent control plane GitHub Actions started as "run these jobs when this event happens." Over time it became the default place where many teams express engineering policy. Tests run there. Security scans run there. Release jobs run there. Preview environments get created there. Package publishing, dependency checks, compliance evidence, and deployment approvals often pass through that same system. Now agents are being pulled into the same shape. That is not accidental. A reasoning agent still needs a trigger, an execution environment, credentials, limits, logs, and a result. Actions already has language for most of that. The agent part is new. The operational container around it is not. This is the part I think many teams should pay attention to. The durable product category may not be "AI assistant." It may be "workflow engine where some steps reason over messy context." That sounds less exciting than the demo. It is much closer to how useful software gets adopted. getting rid of PATs matters The personal access token change is a bigger deal than it looks. Long-lived personal tokens were never a sane foundation for scaled automation. They are easy to create, easy to forget, and hard to reason about after the employee who created them changes teams or leaves the company. They also blur ownership. Is this automation acting as Paulo? As the repository? As the organization? Who pays for it? Who can revoke it without breaking unrelated workflows? Which audit trail tells the truth? Using GITHUB_TOKEN does not solve every problem, but it moves agentic workflows into a more normal automation model. The workflow gets an identity scoped to the repository and job permissions. The organization can own billing. Cost centers and per-run token caps can exist in the same conversation as runner policy. That is the boring enterprise feature. It is also the feature that makes the product real. If an agent still needs a developer's personal token to operate, it is not really production automation. It is a clever script with somebody's identity attached to it. That may be fine for experiments. It is not where I would build an organizational workflow. markdown is the interface, policy is the product I like the Markdown interface. It fits the way many engineers already describe operational intent: "When a new issue is opened, classify it, find related incidents, suggest labels, and ask for missing reproduction steps." "When CI fails on the main branch, inspect the failure, compare it to recent flakes, and open a draft investigation." "Once a week, check docs that mention deprecated APIs and propose updates." Those tasks are awkward to express entirely as deterministic YAML. They involve judgment, search, summarization, and a tolerance for partial answers. But the Markdown is only the friendly edge of the system. The important part is what happens after the task is described. Does it compile into something reviewable? Can the generated workflow be locked? Can a platform team constrain the runner group? Are permissions read-only by default? Are outputs validated before changes are applied? Is there a threat detection pass? Can the cost be capped? That is the difference between "we let the model do things" and "we built an automation system that includes a model." The second one is much more useful. this will create new review work There is a trap here. Because the workflow starts as natural language, it may feel less like code. That would be a mistake. An agentic workflow definition is still a production artifact. It can cause compute to run, credits to be spent, issues to be labeled, pull requests to be opened, and humans to spend review attention. It deserves review. Not in the same way as a low-level library, but with the same seriousness. Someone should read the task definition and ask: Is the job narrow enough? What input can trigger it? What repositories and files can it see? What permissions does it request? What happens when the answer is wrong? How much can it spend before stopping? Who owns the workflow when it gets noisy? This is where platform teams will matter. If every team invents its own agentic workflow style, organizations will end up with the AI version of abandoned CI jobs: half-useful automation nobody wants to delete because nobody remembers why it was created. The healthy version will look more like a catalog. Approved workflow patterns. Standard permission sets. Known runner groups. Required labels for agent-authored pull requests. Budget defaults. A small number of blessed ways to do common things. That sounds bureaucratic. It is also how shared infrastructure survives contact with real companies. the first workflows should be boring The best early use cases are not dramatic. I would not start with "refactor a service across 40 repositories." I would start with things that already have clear boundaries: issue triage that only labels and comments CI failure analysis that opens a draft report documentation drift checks dependency update summaries compliance evidence collection stale test investigation with no direct code changes The pattern is simple: let the agent gather context, produce a reviewable artifact, and stop. Do not let the first version directly merge changes. Do not let it silently mutate production configuration. Do not give it broad write permissions because the demo was impressive. The more autonomous the workflow becomes, the more boring the control plane needs to be. This is not pessimism. It is how you keep the useful parts. Agents are good at starting work that humans postpone because it is tedious. They can read logs, connect clues, summarize context, and draft the next step. That is valuable. But once the agent sits inside a scheduled or event-driven workflow, it becomes part of the engineering system. The system needs limits before the novelty wears off. the punchline GitHub Agentic Workflows are interesting because they make agents less special. The agent is not a separate magical coworker hovering outside the process. It is a workflow step running inside Actions, behind policies, with permissions, billing, logs, and validation. That is the right kind of boring. The companies that get value from this will not be the ones that write the fanciest natural-language workflows. They will be the ones that treat those workflows like production automation: narrow jobs, scoped tokens, reviewable outputs, explicit owners, budget caps, and boring defaults. The future of agent work may still have chat windows. But the version that survives inside real engineering organizations is going to look a lot like CI. references GitHub Changelog: GitHub Agentic Workflows is now in public preview GitHub Changelog: Agentic workflows no longer need a personal access token GitHub Next: Agentic Workflows To test my projects, I use Railway. If you want $20 USD to get started, use this link.

1 day ago

prompts are becoming CI/CD configuration

GitHub Agentic Workflows is now in public preview, and the headline version is easy to understand. You write a natural-language Markdown file that describes a reasoning-based automation. GitHub compiles it into Actions YAML. The agent runs inside the Actions world, using the runners, permissions, policies, and review machinery teams already have. That sounds like "AI for GitHub Actions." I think the more interesting version is slightly more uncomfortable: Prompts are becoming CI/CD configuration. Not prompts in the casual chat window sense. Not "please summarize this issue" typed by one developer on a Tuesday afternoon. I mean prompts as durable, reviewed, repeatable inputs to the delivery system. They live in the repository. They describe work. They decide which tools an agent can use. They affect code, issues, documentation, triage, security checks, and pull requests. They can spend organization money. They can be triggered by workflows. At that point, a prompt is not a suggestion. It is infrastructure. markdown was the easy part There is a very nice developer-experience trick here. Markdown feels harmless. Everyone knows how to read it. A workflow written in Markdown looks less intimidating than a page of YAML, shell scripts, permissions, and matrix jobs. That is useful. A lot of CI/CD configuration became painful because it asked every team to think like a build-platform engineer. If a product engineer can describe a narrow piece of maintenance work in plain language and have it compile into a normal Actions workflow, that is a real improvement. But the plain-language surface should not fool us. The system still needs all the boring parts underneath: which events can start the workflow which repository contents the agent can read which tools it can call which runner group it uses which secrets it cannot reach which output is considered safe which lockfile represents the compiled behavior which human is responsible when it gets weird The prompt is friendly. The operational shape is not casual. This is the part that engineering organizations need to internalize. The prompt is now one layer of a control plane. It is closer to Terraform, GitHub Actions YAML, CodeQL configuration, or policy-as-code than it is to a chat message. Readable does not mean low risk. compiled prompts need code review The phrase "compiled into Actions YAML" matters. Compilation creates a useful boundary. It means the natural-language file is not the only artifact that should be understood. There is a generated workflow shape too, and that workflow has permissions, jobs, runners, and execution behavior. That should sound familiar. We do not review Kubernetes manifests only by asking whether the app developer had good intentions. We look at the resources, probes, ports, environment variables, service accounts, and network exposure. We do not review Terraform by saying the description felt reasonable. We inspect the plan. Agentic workflows need the same discipline. If someone changes the prompt from "triage stale issues" to "fix stale issues," that may be a huge behavior change. If someone adds a tool, broadens a path pattern, changes a permission, or swaps the model used for the task, the diff can look small while the blast radius gets much larger. Natural language makes this trickier because tiny wording changes can matter. "Update documentation when APIs change" is different from "update documentation and examples when APIs change." One writes prose. The other may touch executable code. "Open a draft pull request" is different from "open a pull request." "Suggest labels" is different from "apply labels." This is not a reason to avoid the feature. It is a reason to stop treating prompt review as vibes. The reviewer should ask boring questions: What is this workflow allowed to change? What evidence does it need before changing it? Does it produce a draft or a final artifact? Are generated changes clearly labeled? What happens when the agent is uncertain? Can the team reproduce the behavior from the committed files? That is code review. It just happens to include English. the personal token going away is a big deal The related GitHub change may be even more important: agentic workflows can now use the built-in GITHUB_TOKEN instead of a long-lived personal access token. That sounds like plumbing because it is plumbing. It is also exactly the kind of plumbing that separates hobby automation from company infrastructure. Long-lived personal access tokens are a bad foundation for shared automation. They blur ownership. They outlive people. They hide inside secrets. They make it too easy for "Paulo's token" to become the thing that keeps a business process running. Moving agentic workflows to GITHUB_TOKEN puts them into the normal Actions identity model. The repository and organization can own the automation. Permissions can be scoped. Billing can attach to the organization instead of a person. Policies can decide whether Copilot CLI usage is allowed. This is less flashy than an agent writing code. It is also the maturity moment. Agents stop being toys when they stop using your personal token. That does not make them safe by default. It makes them governable in a way that enterprises can understand. budgets are part of the workflow file now Organization billing changes the conversation too. If an agentic workflow runs as part of Actions and consumes AI credits, the cost is no longer an individual developer experimenting with a tool. It is a property of the delivery pipeline. That means it needs the same treatment as other metered CI resources. Some workflows are worth running on every issue. Some should run nightly. Some should run only when a maintainer asks. Some should run on a small model. Some should spend more because the work is security-sensitive or touches a critical path. None of that should be discovered from the invoice. The uncomfortable part is that AI cost will often be mixed with human attention cost. A workflow that opens five low-quality pull requests a week is not cheap just because the model bill is small. It spends reviewer time. It creates notification noise. It teaches the team to ignore agent output. That is why the owner matters. Every agentic workflow should have someone who can answer three questions: Is this still useful? Is this still worth what it costs? Is this still operating inside the intended boundary? If nobody owns those answers, the workflow is just another piece of automation drifting toward background noise. safe outputs are the new build artifacts GitHub's announcement spends time on safeguards: read-only defaults, sandboxed containers, a firewall, safe outputs, and threat detection scanning proposed changes before they are applied. That is the right direction. It also hints at the real problem. Once an agent can reason over repository content and generate changes, the output itself becomes something that needs validation before the rest of the pipeline trusts it. This is very similar to build artifacts. A compiled binary is not trusted because the source code looked nice. It is trusted because it came from a known process, in a known environment, with checks, signatures, provenance, and review rules around it. Agent output needs that mindset. The question is not only "did the agent produce a useful diff?" The better questions are: What input did it see? Which tools did it use? Which files did it touch? Which checks ran after it produced the result? Was the output constrained before it reached a privileged workflow? Can a reviewer understand why the change exists? This is why putting agentic workflows inside Actions is smart. It gives the ecosystem a familiar place to put these controls. But teams still have to use them. what i would do first I would not start with a workflow that rewrites production code. Start with something useful and boring. Issue triage is a decent first candidate. Documentation drift is another. Weekly dependency-report generation is probably fine. Release-note preparation can work if the output is explicitly a draft. The important part is to keep the first workflow narrow enough that a reviewer can tell when it misbehaves. For example: It can only comment, not edit code. It can only touch files under docs/. It can only open draft pull requests. It cannot run on untrusted external input. It has a named owner. It has a budget. It has a clear delete condition. That last one is underrated. Automation should have a delete condition. If the workflow creates more review burden than value for a month, turn it off. If the team ignores every output, delete it. If it needs a human to rewrite everything, tighten the task or stop pretending it is automation. Engineering maturity is not keeping every clever workflow alive forever. the punchline Agentic Workflows are interesting because they make prompts durable. A prompt can now sit in a repository, compile into a workflow, run on organization infrastructure, use organization identity, spend organization money, and produce changes that enter the same review process as human work. That is a real shift. It is also a warning label. If prompts are becoming CI/CD configuration, they need the habits we already learned from CI/CD: review, ownership, least privilege, budgets, lockfiles, sandboxing, rollback, and deletion when the value is gone. The pleasant fiction is that natural language makes automation simple. The more useful truth is that natural language makes automation easier to author, which means we will have more of it. More automation is good only when the operating model keeps up. references GitHub Changelog: GitHub Agentic Workflows is now in public preview GitHub Changelog: Agentic workflows no longer need a personal access token To test my projects, I use Railway. If you want $20 USD to get started, use this link.

2 days ago