Build a plugin once, and it
runs on rival agents too.
On August 12, 2026, GitHub shipped "Agent Plugins 1.0" as generally available across VS Code, Copilot CLI, and the Copilot app. The standard behind it was co-founded by AWS, Anysphere (Cursor), Microsoft, OpenAI, and Vercel — companies that normally compete hard, lining up on one plugin format.
"Build once, run
anywhere" as a spec
GitHub's official changelog announced that on August 12, 2026, "Agent Plugins 1.0" became generally available across VS Code, Copilot CLI, the Copilot SDK, and the Copilot app, on all Copilot plans. Agent Plugins bundles an AI agent's skill (task instructions) and MCP servers into a single package, governed as an open standard independent of any one vendor.
The standard itself was announced on August 6, jointly authored by AWS, Anysphere (Cursor), Microsoft, OpenAI, and Vercel. Per the official VS Code docs, existing Copilot plugins that don't target 1.0 keep working as-is, with no migration required.
They fight over the product.
On the standard, they shake hands.
Cursor's name on the list
is the real story here
Anysphere (Cursor), one of the co-founding members, is a direct competitor to GitHub in the coding-AI space.
Anysphere, the company behind Cursor, shipped its own Git hosting platform, "Origin," the very same week, explicitly aiming to reduce dependence on GitHub (owned by Microsoft) — see our related article. Competing hard on the hosting layer while lining up on a shared "interoperability standard" for plugins isn't a contradiction; it's a pattern that shows up often in this industry. Companies want to own the infrastructure themselves, but a widely shared ecosystem (the ground developers build plugins on) improves the overall developer experience — and, ultimately, tends to funnel more usage back to their own products too.
The practical impact is significant too. Previously, developers had to write separate plugins for Copilot, for Cursor, and for whatever other agent they targeted. Following the shared Agent Plugins shape (skills and MCP servers), a single package can now be reused across multiple clients. For plugin authors, adding support for a new client no longer means rebuilding from scratch.
The economics of
building a plugin, changed
| Before | After Agent Plugins 1.0 |
|---|---|
| Separate implementation per client | One package shared across clients |
| No cross-vendor compatibility | Skills and MCP servers in a common shape |
| Existing plugins managed individually | Older non-1.0 plugins keep working too |
Who this matters to,
and how
Plugin authors
The cost of duplicating implementations across multiple agent clients drops. Even internal, business-specific plugins become easier to extend to new clients later.
Engineers and users
Existing Copilot plugins keep working with no changes required, so there's no forced migration. When choosing a new plugin, whether it supports Agent Plugins becomes a reasonable factor to weigh going forward.
Product managers
Internal agent-tooling budgets can potentially be estimated on a "build once, use in several places" basis rather than per-client.
A shared standard still has
to prove itself in practice
A standard existing and a plugin actually behaving identically on every client are two different things. Digital Applied's analysis points out that, at the Agent Plugins 1.0 stage, some pieces still "don't port" cleanly across clients. As long as vendor-specific implementation differences remain, "write once, behave identically everywhere" isn't quite accurate yet.
It's also worth being careful about taking "open and neutral" at face value just because five major companies co-authored the standard. Those same companies also run the major platforms the standard governs, so there's a real chance future revisions still end up shaped by their interests. For now, plugin authors shouldn't skip actually testing behavior on each major client rather than assuming full portability.