I have a Dependabot habit that I suspect most developers share: I glance at the PR title, check that the tests are green, and merge. It works fine for a patch bump of a library I barely think about. It is a terrible habit for the newest thing Dependabot just learned to update — because this time, the "dependency" is not a library. It is the instructions your AI coding agent follows.
On November 3, 2026, GitHub announced that Dependabot version updates now support Agent Package Manager, usually shortened to APM. If you declare AI agent skills, prompts and instructions in an apm.yml file, Dependabot will now open pull requests when newer versions of those packages appear, and it will regenerate your apm.lock.yaml when one is present. The feature is generally available on github.com for all plans, and GitHub says it will reach GitHub Enterprise Server in version 3.24. On the surface it looks like a small changelog entry — one more ecosystem in a list that already includes npm, Maven, Docker, Terraform and GitHub Actions. Underneath, it is the moment the software supply chain officially swallowed a new kind of dependency: the words your agent reads before it touches your code.
What APM actually is
Before the Dependabot part makes sense, the APM part has to. Agent Package Manager is an open-source project from Microsoft, and the shortest honest description of it is the one everyone keeps using: it is npm, but for agent context.
Here is the problem it solves. If you use an AI coding agent — GitHub Copilot, Claude Code, Cursor, Codex, Gemini, Windsurf, or any of the other harnesses APM supports — your agent's behaviour depends on more than the model. It depends on skills, prompts, instructions, plugins and MCP servers that live in your project. Until recently, those were scattered: a skill copied from a blog post into one repo, an instruction file pasted into another, a prompt your teammate swears by that exists only on their machine. When the upstream skill got better, nobody found out.
APM gives that mess a manifest. You declare the external skills, prompts, instructions, plugins and MCP servers your project needs in a single apm.yml file, and any developer on the team runs apm install to deploy each piece to the harnesses they use. The lockfile, apm.lock.yaml, records the resolved versions, the exact commits and the content hashes, so the next install is reproducible instead of a fresh surprise.
What Dependabot does with apm.yml
The mechanics are deliberately boring, and that is a compliment. Dependabot already tracks dozens of ecosystems; APM now joins that list with its own ecosystem value, apm, in the Dependabot configuration file.
You add an apm entry to .github/dependabot.yml, point it at the directory containing your apm.yml, and pick an update schedule — daily, weekly, monthly, whatever your team already uses for everything else. Something like this is all it takes:
version: 2
updates:
- package-ecosystem: "apm"
directory: "/"
schedule:
interval: "weekly"When Dependabot finds a newer release for a supported entry, it opens a pull request that edits apm.yml. When an apm.lock.yaml file is already present, Dependabot rebuilds that lockfile with the apm lock command, so your locked versions stay consistent without manual intervention. One detail worth knowing: it will not create a lockfile in a project that does not already have one. If you want the reproducibility guarantees, you have to opt in by generating the lockfile yourself first — no lockfile means no proof of currency, and the absence of a Dependabot PR does not prove your skills are up to date.
And one boundary GitHub is explicit about: this support covers version updates only, not security updates. Dependabot will tell you a newer version exists. It will not tell you the version you have is vulnerable, and it will not open a security fix PR for an APM dependency. It reads git dependencies under dependencies.apm and devDependencies.apm, but object-form and mcp: entries are excluded, and private git dependencies need git-registry access.
Why this matters more than a normal dependency bump
Here is the part I keep coming back to, because it is the reason I am writing this instead of just pasting the changelog. A normal dependency update changes code that runs. An agent-skill update changes the instructions that decide what code gets written, what commands get run, and what your repository's credentials get used for — without changing a single line of your application source.
That is why the practical guidance around this feature is unusually blunt for a Dependabot launch. The pull request diff may show only a one-line version bump in apm.yml, while the behaviour change is enormous and invisible unless you read the upstream change yourself. Before merging, review the package source, the version diff, the lockfile change, the permissions the skill requests, and run behavioural tests. A changed instruction can change what an agent does with your repo's credentials.
The context: November 3 was a big day for agent infrastructure
This did not land in isolation. November 3, 2026 was a busy day for the tooling around AI coding agents. The same day, GitHub shipped the Copilot usage metrics API change that separates bring-your-own-key usage from Copilot-hosted usage, so teams can finally tell their own model spend apart from GitHub's. And Dependabot's APM support fits the same pattern: the agent is no longer one model behind one subscription, and the tooling is racing to catch up with that reality.
Zoom out a little further and the direction is clear. Back in April 2026, GitHub made Dependabot alerts assignable to AI agents for remediation — you can now point Copilot, Claude or Codex at a vulnerability alert and get a draft pull request with a proposed fix. Now the agent's own dependencies get version updates too. The loop is closing: agents fix your dependencies, and Dependabot maintains your agents' dependencies. The human's job in that loop is increasingly the review — reading diffs, checking permissions, deciding what to trust.
What this means if you build WordPress and Elementor sites
If you are reading this site, there is a good chance your daily work is WordPress, Elementor, and client sites — not agent infrastructure. So why should you care about a GitHub changelog entry?
Because the way you build those sites is changing under your feet. Plenty of WordPress developers now do real work inside Copilot or Claude Code: scaffolding custom Elementor widgets, writing theme functions, debugging plugin conflicts, generating boilerplate for custom post types. The skills and instructions those agents use — your WordPress coding standards, your deployment checklist, your review prompt — are becoming part of your project's setup, just like composer.json or package.json.
If those skills live in an apm.yml, they now have a maintenance story. A shared WordPress skill maintained by the community gets a better approach to block themes, and Dependabot can bring it to your repo the same way it brings you a patched version of a PHP library. Your whole team stays on the same version of the same instructions instead of drifting apart one copied file at a time.
But the caution applies doubly in a client-services context. An agent skill that quietly changes how your agent handles a client's database credentials, or how it deploys to a production WordPress host, is a risk to someone else's business, not just your own repo. If you adopt APM for your WordPress workflow, adopt the review habit with it: read the upstream diff on every Dependabot APM pull request and test the new skill against a staging site before it touches a client project.
How to set it up this week
If you want to try this, the path is short. First, if you are not using APM yet, install it and declare your agent skills in an apm.yml at the root of a repository where you already use an AI coding agent. Run apm install and confirm your harness picks the skills up. Then generate the lockfile with apm lock so Dependabot has something to regenerate — remember, it will not create one for you.
Next, add the apm ecosystem to your .github/dependabot.yml with the directory that contains your apm.yml and a schedule you can live with. Weekly is a sensible starting point; agent skills change less often than JavaScript libraries, and weekly gives you a manageable review cadence. Then wait for the first pull request, and use it as a rehearsal: open the upstream repository, read what actually changed in the skill, look at the lockfile diff, and decide whether the new version deserves your trust before you merge.
A few habits will save you pain. Pin skills to SemVer tags rather than floating branches where you can, because branch pins can change what resolves underneath you without a version number ever moving. Keep your apm.yml small — every skill you add is another instruction set your agent loads into context and another upstream you are trusting. And keep security updates on a separate track: since Dependabot does not do security updates for APM, subscribe to the upstream repositories of the skills you depend on, so a vulnerability in a skill does not sit unnoticed while version updates flow past it.
Conclusion
Dependabot learning to update Agent Package Manager files is a small changelog entry with a large implication: the instructions your AI agent follows are now dependencies, with versions, lockfiles and automated update pull requests. That is good news. It means the skills your team relies on can stay current without anyone remembering to check, and it means every developer on a project can run the same version of the same instructions.
But it also means the review habit matters more, not less. A version bump in apm.yml can change what your agent does with your code and your credentials, and no green test suite will catch a skill that got subtly worse. Set up the automation, let Dependabot surface the updates — and then do the one thing it cannot do for you. Read the diff.
FAQ
What is Agent Package Manager (APM)?
APM is an open-source project from Microsoft for managing what AI agents depend on. You declare skills, prompts, instructions, plugins and MCP servers in an apm.yml file, run apm install to deploy them to your coding-agent harness, and apm.lock.yaml records the exact versions, commits and hashes. People describe it as npm for agent context, and it supports harnesses including GitHub Copilot, Claude Code, Cursor, Codex, Gemini and Windsurf.
What did GitHub announce on November 3, 2026?
Dependabot version updates now support APM. Dependabot opens pull requests to update supported git dependencies declared in apm.yml and regenerates apm.lock.yaml when the lockfile is present. The support is generally available on github.com for all plans and is planned for GitHub Enterprise Server 3.24.
How do I enable Dependabot updates for APM?
Add an apm entry to your .github/dependabot.yml, specify the directory containing your apm.yml, and choose an update schedule. Make sure you already have an apm.lock.yaml in the repository, because Dependabot regenerates the lockfile but will not create one if it is missing.
Does Dependabot handle security updates for APM dependencies?
No. GitHub is explicit that APM support covers version updates only, not security updates. You still need separate vulnerability intelligence and policy checks for agent packages, and you should watch the upstream repositories of the skills you depend on.
Why should I review a Dependabot APM pull request more carefully than a normal dependency update?
Because a changed skill or instruction can change your agent's behaviour without changing your application source code. The pull request diff may show only a version bump, while the upstream change alters how the agent writes code, runs commands, or uses credentials. Always review the package source, the version diff, the lockfile change and the permissions before merging.
Does this matter if I build WordPress sites?
Yes, if you use an AI coding agent in your WordPress or Elementor workflow. Your agent's skills — coding standards, deployment checklists, review prompts — are becoming part of your project setup. APM plus Dependabot gives them a maintenance story, but review each update against a staging site before it touches a client project.
