I opened GitHub on my phone before my morning coffee had finished brewing. There it was — a pull request, freshly opened, titled “chore: upgrade astro to v6.1.2”. I hadn’t asked anyone to do it. I hadn’t filed an issue, assigned a task, or written a single command. An agent had woken up, checked the npm registry, read the Astro changelog, inspected my codebase, applied the changes, run pnpm install, and handed me a PR to review. All I had to do was drink my coffee and click Merge.
This is the promise of what GitHub Next is calling Continuous AI — and it’s already working on my blog.
The Spark: Idan Gazit at the MVP Summit
The Microsoft MVP Summit is one of those rare, invite-only events where product teams and researchers share things that haven’t been announced yet. Normally those are under NDA, but this was already public. This year, Idan Gazit, Head of Research at GitHub Next, gave a live demo that made me set down my laptop and pay close attention.
He showed his personal blog repository — also powered by Astro — and walked us through a workflow file he had written in plain Markdown. On a schedule, it checks whether a new version of Astro has been published. If there is one, it fetches the changelog, reads the codebase, and opens a pull request with all the necessary changes already applied. No human involvement until the PR appears.
I started building my own version that same afternoon.
How I Used to Handle Astro Updates
Before I show you the workflow, let me describe the unglamorous reality of how this worked before.
I’d either stumble across a new Astro release in my timeline, or catch it in GitHub notifications when someone I follow merged an upgrade. I’d open my repository, create a GitHub Issue along the lines of “Upgrade Astro to vX.Y.Z”, and assign it directly to Copilot. Copilot would churn through the issue, figure out what needed changing, and eventually open a pull request.
That flow wasn’t bad — I genuinely liked it — but it required me to notice the release, decide to act, and manually kick off the dependency update process. Sometimes I’d be a few minor versions behind before I got around to it.
Now the agent does the noticing. I just show up for review.
What GitHub Agentic Workflows Actually Are
GitHub Agentic Workflows is a research demonstrator from GitHub Next, announced in February 2026 by Don Syme and Peli de Halleux. The core idea is elegant: instead of writing complex GitHub Actions YAML by hand, you describe your automation intent in a plain Markdown file with a YAML frontmatter block. You then run gh aw compile, which generates a .lock.yml file — a valid, fully inspectable GitHub Actions workflow YAML that you commit alongside it.
The Markdown file is the source of truth. The .lock.yml is its compiled output. Both live in .github/workflows/.
One of the most interesting aspects is the concept of safe outputs. By default, the agent running your workflow has read-only access to your repository. The only way it can write anything — create a PR, post a comment — is through pre-approved, sanitized channels declared in the frontmatter under safe-outputs. This is careful security architecture: it means the agent cannot do arbitrary things to your repository, regardless of prompt injection or edge cases. It goes through a defined, auditable channel or it does nothing.
And critically: PRs are never merged automatically. The agent opens the PR. You review and merge. That human checkpoint is a deliberate design principle, not an oversight.
This sits inside a broader research vision GitHub Next calls Continuous AI — the idea that AI-enriched automation in software collaboration will become as routine as CI/CD. Just as we don’t think twice about a test suite running on every push, we’ll eventually not think twice about an agent checking for outdated dependencies, summarizing PRs, or keeping documentation in sync with the code.
A Tour of My Workflow File
Here is the frontmatter of my astro-upgrade.md:
---
name: Astro Upgrade
description: Daily check for new Astro releases and automatic upgrade PR creation
on:
schedule: daily on weekdays
permissions:
contents: read
pull-requests: read
issues: read
tools:
github:
toolsets: [default]
web-fetch:
bash: true
edit:
network:
allowed:
- github
- docs.astro.build
- node
safe-outputs:
create-pull-request:
title-prefix: "chore: "
labels: [dependencies, astro]
draft: false
preserve-branch-name: true
max: 1
allowed-files:
- package.json
- pnpm-lock.yaml
- .github/workflows/astro-upgrade.lock.yml
- astro.config.mjs
- tsconfig.json
- src/**
protected-files: allowed
close-pull-request:
target: "*"
required-labels: [astro]
max: 5
add-comment:
target: "*"
max: 5
---Let me walk through the important pieces.
on: schedule: daily on weekdays — The workflow runs every weekday. If there is no new version of Astro, it stops immediately and does nothing. No noise.
permissions — Read-only on contents, pull requests, and issues. The agent cannot write to the repository directly. That access comes only through safe-outputs.
tools — I’m granting the agent the default GitHub toolset (for reading repo files and PR state), HTTP fetch capabilities, the ability to run bash commands, and the edit tool so it can modify files locally before creating the PR.
network.allowed — An explicit allowlist of external hosts. The agent can talk to GitHub, the Astro documentation site, and the npm registry. Nothing else. This is enforced at the network layer by what GitHub Next calls the Agent Workflow Firewall — it prevents the agent from reaching arbitrary external services.
safe-outputs.create-pull-request — This is where the write permission lives. The PR must have the title prefix "chore: ", will get the labels dependencies and astro, will never be created as a draft, and is capped at one open PR at a time (max: 1). The allowed-files list is the most important security control here: the agent can only include those specific files in the PR diff. If it tries to touch anything else, the PR creation is blocked. I added protected-files: allowed after an early version of the workflow failed to update astro.config.mjs — without that flag, protected config files are off-limits by default.
The body of the Markdown file describes the workflow in six steps, written in natural language. It reads almost like a runbook:
- Check for New Astro Releases — Read
package.jsonto find the current version. Fetchhttps://registry.npmjs.org/astro/latest. If already on the latest, stop. - Check for Existing Upgrade PRs — Before proceeding, search for any open PRs with the
astrolabel or a branch name starting withastro-upgrade/. If a PR already exists for the same version, stop immediately to avoid duplicates. If older version PRs exist, note their numbers for cleanup later. - Research the Upgrade — Fetch the Astro changelog from GitHub and the official upgrade guide at
docs.astro.build. Identify any breaking changes relevant to my installed version range, including required peer dependency updates. - Inspect the Codebase — Read
astro.config.mjs,package.json,tsconfig.json, andsrc/content/config.tsto understand what the blog actually uses. Search for patterns affected by breaking changes. - Plan the Upgrade — List all the package bumps (Astro core and all companion
@astrojs/*packages), configuration changes, and source code updates required. - Apply the Changes and Create a PR — Update the files, run
pnpm install, and open a pull request on the branchastro-upgrade/v{version}with a body that describes every change made. - Close Outdated Upgrade PRs — If any older Astro upgrade PRs were found in step 2, close them with a comment explaining they’ve been superseded by the new PR.
# Astro Upgrade Workflow
You are an Astro upgrade automation agent. Your job is to check for new Astro releases
and, if any are found, create a pull request with the necessary upgrade changes.
## Step 1: Check for New Astro Releases
Read the current `package.json` from this repository to identify all Astro-related
dependencies. Key packages to check include:
- `astro` (core)
- `@astrojs/mdx`
- `@astrojs/sitemap`
- `astro-auto-import`
- `astro-icon`
- `@astro-community/astro-embed-twitter`
- `@astro-community/astro-embed-youtube`
- `@tailwindcss/vite` (only if required by the new Astro version as a peer dependency)
- `tailwindcss` (only if required by the new Astro version as a peer dependency)
For the `astro` core package, check the latest release on npm:
`
https://registry.npmjs.org/astro/latest
`
Compare the latest published version of `astro` with the version currently specified
in `package.json`. If the versions are the same, stop — there is nothing to upgrade.
## Step 1.5: Check for Existing Upgrade PRs
Before proceeding, search for open PRs in this repository that:
- Have the `astro` label, **or**
- Have a branch name starting with `astro-upgrade/`, **or**
- Have a title containing "upgrade astro"
If an open PR already exists **for the same version** you are about to upgrade to,
**stop immediately** — the upgrade PR already exists.
If open PRs exist **for an older version**, note their PR numbers. You will close them
in Step 6 after creating the new upgrade PR.
## Step 2: Research the Upgrade
If a newer version of `astro` exists:
1. **Read the Astro changelog** to understand what changed:
Fetch: `https://raw.githubusercontent.com/withastro/astro/main/packages/astro/CHANGELOG.md`
Focus on the entries between the current version and the latest version.
2. **Read the Upgrading Astro guide** for official upgrade instructions:
Fetch: `https://docs.astro.build/en/upgrade-astro/`
3. Identify:
- All breaking changes that apply to this repository
- Required code changes (configuration, imports, API changes, etc.)
- Updated peer dependency versions (e.g., `@astrojs/*` packages that must be updated together)
- Any deprecated features being used in this codebase
## Step 3: Inspect the Codebase
Read the following key files to understand what needs to change:
- `astro.config.mjs` — main Astro configuration
- `package.json` — dependency versions
- `src/content/config.ts` — content collection schemas (if Astro content layer changed)
- `tsconfig.json` — TypeScript configuration
- Any other files mentioned in the changelog as likely requiring changes
Search the source code for patterns that are affected by breaking changes identified in Step 2.
## Step 4: Plan the Upgrade
Based on your research, create a detailed upgrade plan listing:
1. Which packages need version bumps (astro and all `@astrojs/*` companions)
2. Configuration changes required in `astro.config.mjs`
3. Code changes required in `src/` files
4. Any other file changes needed
## Step 5: Apply the Changes and Create a PR
Apply ALL the changes needed for the upgrade:
1. Update `package.json` with the new version of `astro` and any companion packages
2. Update `astro.config.mjs` if configuration changes are needed
3. Update any source files that require code changes
4. Run `pnpm install` to regenerate the lockfile (this project uses pnpm, as confirmed by `pnpm-lock.yaml`)
Then create a pull request with:
- **Branch name**: `astro-upgrade/v{new-version}` (e.g., `astro-upgrade/v5.0.0`)
- **Title**: `chore: upgrade astro to v{new-version}`
- **Body**: Include a summary of the upgrade, all breaking changes found, and the changes made.
Reference the changelog URL and the upgrading guide URL.
If there are breaking changes that you cannot automatically resolve (e.g., complex
API migrations that require human judgment), still create the PR with the partial
changes and clearly document the remaining manual steps in the PR body.
## Step 6: Close Outdated Upgrade PRs
If you noted any outdated open Astro upgrade PRs in Step 1.5, close each one now.
For each outdated PR:
1. **Add a comment** explaining that a newer version is available:
> Superseded by #NEW_PR — a newer Astro version (vX.Y.Z) is now available.
Replace `#NEW_PR` with the actual number of the PR you just created in Step 5.
2. **Close the PR** without merging.That’s it. No shell scripting, no GitHub Actions YAML gymnastics, no brittle regex for version parsing. Just an intention expressed clearly, with explicit constraints on what the agent is allowed to do. The workflow even handles its own housekeeping, preventing duplicate PRs and cleaning up outdated ones automatically.
What the PR Looks Like in Practice
The pull requests this workflow creates are genuinely good. The PR description documents the previous version, the new version, what changed in the Astro changelog, and a list of every file touched and why. It’s the kind of PR body I’d want to write myself but rarely do for a dependency bump.
When there are breaking changes — and Astro has had a few across its minor versions — the agent finds them in the changelog, checks whether they apply to my configuration, and applies the fix. When the upgrade is straightforward, the PR is minimal: a version bump in package.json and an updated pnpm-lock.yaml.
I’ve reviewed five Astro upgrade PRs since I set this up. Five merged without any changes on my part. That’s a good outcome.
Why This Feels Safe to Run
I know that “an AI automatically modifying files in my production repository” sounds alarming, so I want to be direct about the security design.
The agent has read-only permissions by default. The only write operation it can perform goes through the create-pull-request safe output channel, which is pre-declared in the frontmatter — not decided at runtime. The allowed-files list is evaluated at compile time, not by the agent. The network is allowlisted at the infrastructure layer. The agent’s execution environment is sandboxed.
The .lock.yml file is fully human-readable YAML. You can inspect exactly what GitHub Actions steps will run. gh aw compile generates it and you commit it — you are not running a black box.
And again: the PR is never auto-merged. Every one lands in my PR queue for review. I can close it, push changes to it, or merge it. The agent brings the work to me; it doesn’t bypass me.
Closing Thoughts
I’ve been following GitHub Next’s research projects for a while — Copilot Workspace, SpecLang, and now Agentic Workflows. What strikes me about this one is how immediately practical it is. This isn’t a speculative demo. It’s a workflow running on my real blog, every weekday, producing real PRs that I review and merge.
The authoring experience is also genuinely pleasant. Writing automation in natural language, with constraints expressed declaratively, is a fundamentally different experience from debugging complex GitHub Actions YAML at 11pm. The intent is readable. The constraints are visible. The output is auditable.
I’m already thinking about other automated dependency management workflows: automatically updating code base documentation, or auto-generating release notes. The pattern is clear and composable.
GitHub Agentic Workflows is still a research demonstrator — explicitly not a product, subject to significant change — so I’d read the announcement post and the GitHub Next project page before building anything critical on top of it. But for personal projects, blogs, and exploratory use, the experience is already compelling.
If you’re an Astro user, or just someone who wants to stop manually chasing dependency upgrades, I’d encourage you to look at my workflow file as a starting point. It took me an afternoon to get right, and the coffee the next morning tasted that much better for it.
Have you tried GitHub Agentic Workflows? What would you automate first? I’d love to hear what use cases you’re thinking about — drop a comment below.
You can get all the code on GitHub
