OpenAI, Cursor, Microsoft, Amazon and Vercel just agreed on one AI plugin format — here's what Agent Plugins actually does

On 6 August 2026, five companies that normally compete head-on — OpenAI, Amazon, Microsoft, Cursor, and Vercel — jointly published Agent Plugins, a vendor-neutral specification for packaging AI agent extensions (verified 7 August 2026, via agent-plugins.org and OpenAI's announcement). Version 1.0.0 is out now, marked as a "Working Draft," and it's already supported by ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code.

If you don't build AI tooling yourself, the practical version of this story is short: a skill or integration built for one AI coding assistant should now be usable in several others, without a rebuild. Here's what actually changed and why it matters.

The problem this solves

Every AI agent product — Cursor, GitHub Copilot, ChatGPT, VS Code's Copilot Chat — invented its own way of packaging "extensions": extra instructions, tools, and integrations the agent can load when a task calls for them. The underlying pieces were often conceptually identical, but every vendor stored and described them differently, which meant a developer building a reusable skill effectively had to rebuild it for each tool they wanted it to work in.

Agent Plugins doesn't try to standardize everything about how plugins behave — installation, permissions, marketplaces, and UI all stay entirely up to each vendor. It standardizes one narrow thing: the folder structure and file format a plugin ships as, so any compliant tool can find, validate, and load it the same way. The spec calls this a "small interoperability floor" on purpose.

What's actually in a plugin

A plugin is just a folder — no proprietary archive, no build step, nothing that can't be opened in a text editor or committed to Git:

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       └── SKILL.md
├── mcp.json
└── com.example.client/

• plugin.json — the one file every client is guaranteed to read. Name, spec version, and optional metadata like a description or license.
• skills/ — holds Agent Skills, the format Anthropic originally built and open-sourced, now adopted broadly. Each skill is a short description plus instructions, loaded into the agent's context only when a task actually needs it — the same "progressive disclosure" model that keeps a large skill library from slowing an agent down.
• mcp.json — connections to Model Context Protocol servers, the standard way an agent talks to outside tools and data. The spec settles on two required transport types (stdio for local processes, Streamable HTTP for remote ones) with an older SSE variant supported for backward compatibility — which matters, because inconsistent MCP configuration formats across tools was a real, recurring source of "works in one client, silently fails in another" bugs.
• Reverse-domain folders (com.example.client/) — an escape hatch letting one specific tool add its own extra behavior without breaking the package for everyone else reading it.

When a client loads a plugin, the spec requires it to fail gracefully component by component: if one MCP server won't connect or one skill file is malformed, a compliant client skips just that piece rather than refusing to load the whole plugin.

Where it runs today

(Verified 7 August 2026 against the spec's own Compatible Clients page — check agent-plugins.org directly before relying on this, since the list is expected to grow quickly.)

Google and AWS have both published posts backing the effort even though their own products aren't yet on the compatible-clients list, which is a reasonable early signal that adoption will widen rather than stay at five companies.

The notable name missing from the list

Anthropic isn't on the Technical Steering Committee, and Claude Code isn't listed as a compatible client — despite the fact that two of the three things this format packages, Agent Skills and MCP, were both originally built and open-sourced by Anthropic. Claude Code currently uses its own plugin layout rather than this one.

That's worth flagging plainly rather than glossing over: if your team standardizes tooling around Agent Plugins today, a Claude Code user on the same team won't automatically get the same portability — you'd still be building or maintaining a separate package for it. Whether that changes is worth watching, given how central Anthropic's own formats are to what this spec packages.

What this means if you build or buy AI tooling

If you or a developer you work with maintains internal AI skills or MCP integrations — an internal "summarize support tickets" skill, a connector to your CRM, a script your team's agent runs — the direct benefit is that building it once against the Agent Plugins folder structure means it now works in Cursor, Copilot, ChatGPT/Codex, and VS Code without a separate build for each.

For a small business deciding which coding assistant or agent tool to standardize on, this lowers the cost of that decision being "wrong" later: tooling built around a portable plugin doesn't need a rewrite if you switch coding assistants next year. It's a smaller, quieter version of what open container formats did for deployment — less lock-in, because the package itself isn't tied to one vendor's product.

The caveat is that portability here means the package structure, not the experience around it. Installation, permission prompts, and how a skill shows up in the UI are still entirely up to each tool — two clients can both correctly load the same plugin and still feel completely different to use.

The bottom line

This is infrastructure, not a product you'll interact with directly — but it's the kind of infrastructure decision that quietly saves real engineering hours down the line, the same way a shared file format or API convention does. It's one day old, still a Working Draft, and worth a second look once more vendors join or the spec settles past 1.0.0. For now, if your team is investing time into custom AI skills or MCP connectors, building them against this format rather than one tool's proprietary layout is the safer bet.