Agent Plugins 1.0: Build Once, Run Everywhere

There is a specific tedium every developer building AI plugins knows. You write one useful little tool, then you rebuild the packaging around it four times so it works in four different clients. Agent Plugins 1.0 wants that chore gone.

Table of Contents

What actually landed

On 6 August 2026 a group of vendors published Agent Plugins 1.0, an open standard for packaging agent skills and MCP servers into a single installable plugin. GitHub then made support generally available across VS Code, Copilot CLI, the GitHub Copilot SDK and the Copilot app on 12 August, on all Copilot plans.

The cast behind the spec is the interesting part. AWS, Anysphere (the maker of Cursor), Microsoft, OpenAI and Vercel signed on, with Google joining as a core maintainer on the same day. The pitch is one line: build a plugin once, use it across every compatible agent client, and govern it independently of any single vendor.

The problem it fixes

Bundling a skill with an MCP server was already possible. Picture a deployment runbook (the skill) and the tool integration that runs it (the MCP server). Those two pieces were identical for every client. The packaging around them was not, so you maintained a separate manifest and directory layout for each tool you wanted to support. That is duplication with no payoff. Agent Plugins 1.0 standardises the wrapper. One package, many clients.

How to adopt it

If you maintain a plugin, migrating is mostly manifest housekeeping:

Add a $schema field to plugin.json pointing at the 1.0 schema.
Keep skills under skills/ and MCP configuration in mcp.json.
Move any Copilot-specific files into a com.github.copilot/ directory, which other clients simply ignore.

That last step is the clever bit. Custom agents, commands, rules and hooks live in the namespaced folder, so one package stays portable while keeping its Copilot behaviour. You find plugins in the Awesome Copilot marketplace, on by default in VS Code, Copilot CLI and the Copilot app. Existing plugins that do not target 1.0 keep working, with no forced migration.

Read the asterisk

Here is the honest bit. Portable has a boundary. The spec standardises skills and MCP servers and nothing else, so anything a vendor does beyond those two things lives in its own namespaced corner. Sensible design, but it means a rich Copilot plugin is portable in its bones and Copilot-flavoured in its extras. The standard is also young. Client coverage will be uneven for a while, and vendor-specific plugin formats have not vanished overnight. Treat build once, run everywhere as a direction of travel with real weight behind it, not a finished promise.

For teams, governance rides on settings you already use. Copilot Business and Enterprise admins get enabledPlugins to auto-install or block plugins, extraKnownMarketplaces to add sources, and strictKnownMarketplaces to lock installs to approved marketplaces. Because plugins can carry MCP server configs, pair that with MCP allowlists that approve or block servers by URL, command or name.

Why it matters

The real win here is political, not technical. An open format co-maintained by AWS, Microsoft, OpenAI, Google, Vercel and the maker of Cursor is a rare moment of the big names agreeing on plumbing instead of scrapping over it. If it holds, the people who benefit most are the ones building small, sharp tools who want them to work everywhere without writing the same manifest five times. Good week for the little guy.

Did you know: the Model Context Protocol these plugins lean on only turned up in late 2024, and it is already the closest thing the agent world has to a universal socket.

Sources

The free stack. One email a week: the AI tools and moves that actually matter, hype filtered out. Subscribe free →