Agent Plugins 1.0: What Actually Ports Between Your AI Coding Tools — And What Doesn't

For the past two years, every AI coding assistant has asked engineering teams to do the same tedious thing over again: write a custom instruction file for Cursor, then rewrite it for GitHub Copilot, then rewrite it again for ChatGPT’s Codex, then once more for whatever tool the team adopts next. The underlying capability — a skill, a connector to an internal database, a set of house coding conventions — never changed. Only the packaging did, every single time.

On August 6, 2026, five of the biggest names in AI development tooling — AWS, Cursor’s parent Anysphere, Microsoft, OpenAI, and Vercel — published Agent Plugins 1.0, an open, vendor-neutral specification for packaging AI agent extensions so they work across competing tools without a rewrite. Google joined as a core maintainer the same day. It’s a rare moment: direct competitors agreeing on shared infrastructure instead of trying to out-platform one another.

But six days after GitHub shipped general availability of the standard, the more interesting story isn’t that competitors agreed on something — it’s how much narrower that agreement actually is than the announcements suggest, and what that gap means for any team about to bet its tooling strategy on “portable” AI agents. This piece breaks down what Agent Plugins 1.0 actually standardizes, who’s really behind it, what still doesn’t travel between tools despite the hype, and how engineering leaders should think about it before committing.

What Agent Plugins 1.0 Actually Standardizes

Strip away the marketing and the spec is deliberately narrow. A plugin is a folder containing three things:

• plugin.json — a manifest that, at minimum, needs just a schema version and a name
• skills/ — a directory of Agent Skills written as markdown files with frontmatter metadata
• mcp.json — configuration for MCP servers the plugin depends on

As Vercel put it in its own announcement of the spec, the problem it solves is duplicated effort: “[e]ven though the underlying Skill or MCP server is identical, clients often expect different top-level metadata, discovery paths, or MCP configuration.” Agent Plugins fixes that specific mismatch — package once, and compatible clients can discover and load the same skill and MCP configuration without a client-specific rewrite. GitHub’s own changelog confirms general availability landed on August 12 across VS Code, Copilot CLI, the Copilot SDK, and the Copilot app, for all Copilot plans.

That’s genuinely useful. It’s also all the spec does. It defines no install mechanism, no distribution protocol, no permission model, no sandboxing, and no trust or provenance verification — packaging and discovery, full stop.

Who’s Actually Governing It

The Technical Steering Committee that owns the spec has five named seats: Clare Liguori of Amazon, Roshan Sadanani of Cursor, Harald Kirschner of Microsoft, Gav Verma of OpenAI, and Jonathan Hefner of Vercel, who chairs it. AWS has already shipped two concrete implementations of its commitment — Kiro now natively supports Agent Plugins, and the AWS Agent Toolkit was updated to package more than 30 curated skills spanning Lambda, S3, DynamoDB, and CDK under the new format. That’s a real, working example of a large vendor treating the standard as more than a press-release commitment.

The Catch: Governance Membership Isn’t the Same as Support

Here’s where the story gets more interesting than the launch coverage let on. Holding a seat on the Technical Steering Committee, it turns out, guarantees nothing about whether a vendor’s own product actually conforms to the spec it co-governs.

The clearest example is Anthropic. Anthropic built Agent Skills and co-created MCP — the two component types Agent Plugins 1.0 was designed to package — yet Anthropic is not a maintainer of the standard and wasn’t a launch partner. Claude Code ships its own, separate plugin system, currently in public beta behind the /plugin command, distributed through Anthropic’s own claude-plugins-official and claude-community marketplaces rather than through the Agent Plugins format. The company that arguably did the most upstream technical work isn’t the one packaging it the way the rest of the industry just agreed to.

OpenAI presents a similar, subtler gap. It holds a Technical Steering Committee seat, but a review of an early cohort of major coding tools found that OpenAI’s own plugin documentation makes no mention of Agent Plugins, its schema, or conformance of any kind — the company instead ships a /import feature that translates Claude Code’s and Cursor’s proprietary formats directly, rather than consuming the shared standard it helped write. Of four major AI coding tools examined in that review, only half documented actual conformance to the spec their vendors had nominally endorsed.

And even where a client does support the format, portability stops well short of “write once, run anywhere.” VS Code, for instance, currently ignores client-specific extension data and directories inside Agent Plugins 1.0 packages. What genuinely ports across supporting clients is the narrow floor: skills and MCP server configuration. What doesn’t travel: hooks, slash commands, subagents, LSP servers, and any client-specific behavior layered on top — exactly the customizations that make a given tool’s setup feel tailored to a team’s workflow in the first place.

Why This Matters Beyond Developer Tooling

This is a smaller-scale rerun of a pattern enterprises have now seen play out across the AI stack all year. It echoes what happened when IBM struck its own multi-vendor OpenAI partnership rather than betting exclusively on one model provider, and it rhymes with the lesson from AWS retiring Bedrock Agents Classic earlier this year: even inside a single vendor’s own ecosystem, the tooling layer moves faster than any team’s investment in it, and “we built this on the standard interface” doesn’t fully insulate you from rework. Google’s decision to hand its own agent protocol to a neutral foundation earlier this month was part of the same broader trend — vendors ceding formal control of interfaces while trust and actual conformance still lag behind the announcement.

The practical risk for engineering leaders isn’t that Agent Plugins 1.0 is bad infrastructure — the AWS and Vercel implementations show it solves a real problem for the narrow slice it covers. The risk is treating a vendor’s Technical Steering Committee seat, or its name on a launch-day press release, as a proxy for “our tools will work the same way across every client we use.” As of today, that proxy doesn’t hold, and the gap between the two is currently doing a lot of the reputational work for the announcement.

How Engineering Teams Should Actually Respond

1. Author your custom skills and MCP servers to the Agent Plugins 1.0 folder structure now, even if you’re only deploying to one client today. The floor-level format — plugin.json, skills/, mcp.json — costs little to adopt and pays off the moment a second tool needs the same capability.

2. Don’t assume a vendor logo on the spec’s website means their product ships conformant support. Check each tool’s own documentation for explicit Agent Plugins conformance before you plan a migration or a multi-tool rollout around it — the gap between committee membership and shipped behavior has already caught out teams that assumed otherwise.

3. Keep hooks, slash commands, and subagents deliberately thin and easy to rebuild. Since none of that layer is portable under the current spec, treat it as the disposable, client-specific configuration it actually is — not as core intellectual property worth heavily investing in for any one tool.

4. Revisit this in two to three quarters, not before. A working draft of version 1.1.0 is already in progress, and the practical portability story here is likely to change faster than most infrastructure standards do, given how many well-resourced vendors have a stake in making it work.

Agent Plugins 1.0 is a genuine, if narrow, win for teams tired of rebuilding the same skill five times. Treat it as exactly that — a packaging format for the pieces it actually covers — and it will save real engineering time. Treat it as a guarantee that your AI tooling stack is now vendor-agnostic, and the first migration you attempt will teach you otherwise.

Frequently Asked Questions

What is Agent Plugins 1.0 in simple terms?

It’s an open specification, published August 6, 2026 by AWS, Cursor, Microsoft, OpenAI, Vercel, and Google, that defines a common folder format — a manifest plus a skills directory and an MCP configuration file — so an AI agent extension can be packaged once and loaded by any client that supports the format, instead of being rewritten for each tool.

Does Agent Plugins 1.0 make all AI coding tools fully interoperable?

No. It standardizes packaging and discovery for two component types — Agent Skills and MCP server configuration. Client-specific features like hooks, slash commands, subagents, and LSP servers are explicitly outside the spec and remain locked to whichever tool you built them for.

Does Claude Code support Agent Plugins 1.0?

Not directly. Claude Code has its own plugin system, distributed through Anthropic’s own marketplaces and installed via the /plugin command. Anthropic, which created Agent Skills and co-created MCP, is not a maintainer of or launch partner for the Agent Plugins standard.

Is it worth adopting the Agent Plugins folder structure if my team only uses one AI coding tool today?

Generally yes, for new skills and MCP servers you build, since the format costs little to adopt upfront. Just don’t assume it buys you full portability today — verify conformance in each tool’s own documentation rather than relying on that vendor’s name appearing in the governance list.

Which AI coding tools actually support Agent Plugins 1.0 today?

At general availability, GitHub confirmed support in VS Code, Copilot CLI, the Copilot SDK, and the Copilot app. AWS shipped support in Kiro and updated its AWS Agent Toolkit to the format. Documented conformance elsewhere is inconsistent — some Technical Steering Committee members, including OpenAI, have not documented conformance in their own product docs as of this writing.

What should I do if I’ve already built custom instructions for multiple AI tools separately?

There’s no need to migrate everything immediately. Prioritize consolidating skills and MCP configurations you maintain across more than one tool first, since that’s where the duplicated-effort cost is highest and where the portable floor of the spec delivers the most immediate value.

Sources

• Agent Plugins Specification v1.0.0 - The official spec repository, including the manifest schema, governance charter, and maintainers list.
• Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app - GitHub’s official changelog announcing general availability on August 12, 2026.
• Introducing Agent Plugins - Vercel’s official announcement explaining the fragmentation problem the spec solves.
• AWS Supports Agent Plugins: An Open Standard for Portable Agent Extensions - AWS’s official blog on its Technical Steering Committee role and its Kiro and AWS Agent Toolkit implementations.
• Agent Plugins package your skills, tools, and more - Google’s official announcement of joining as a core maintainer.
• Agent Plugins 1.0 Ships: What Still Does Not Port - Independent analysis of the gap between Technical Steering Committee membership and documented product conformance.
• Customize Claude Code with plugins - Anthropic’s official documentation of Claude Code’s own, separate plugin system.
• Anthropic defined the standards inside Agent Plugins. So why isn’t it helping govern the format? - The New Stack’s reporting on Anthropic’s absence from the standard’s governance despite building its underlying components.