Amazon, Microsoft, OpenAI and Vercel agreed on one plugin format for AI agents

An Agent Plugin is a folder. Inside it sits a plugin.json manifest with two required fields, an optional skills/ folder holding Agent Skills, and an optional mcp.json that declares MCP server connections. That is the whole thing. It is licensed CC-BY-4.0, developed in the open, and the spec lives at agent-plugins.org.

The reason it matters is who signed up to read it. At launch the compatible clients are ChatGPT, GitHub Copilot, Cursor, VS Code, Codex and Kiro. The initial Technical Steering Committee is Amazon, Cursor, Microsoft, OpenAI and Vercel, and Google joined as a core maintainer the same day, wiring it into its own Agents CLI and Data Agent Kit. When the companies that normally build competing walled gardens all agree to accept the same package, the format stops being a proposal and starts being a fact you can plan around.

This did not come from nowhere. It builds on two pieces that already have scale. Anthropic's MCP had passed 10,000 active public servers and 97 million monthly SDK downloads by December 2025, and Agent Skills has been shipping since 2025. Agent Plugins is not a new thing to learn. It is a wrapper that makes the things you already build movable.

Because the file format is where lock-in lives. Right now, if your team builds a genuinely useful agent capability, say a skill that knows your invoice rules plus an MCP connection into your billing system, that work is married to whatever platform it was built on. Move to a different agent product next year and someone rebuilds it. That rebuild is not a line item anybody quotes you. It hides inside internal engineering time, and it is exactly the switching cost that makes a platform sticky whether or not it stays the best one.

A shared package format is a direct hit on that. Build the skill once, wrap it as an Agent Plugin, and every compatible client can load it. The work you commissioned becomes an asset you own rather than a rental tied to one vendor's runtime. For anyone deciding to spend money on custom agent development, that changes the shape of the question from "which platform do we bet on" to "what do we want the agent to do," which is the question you actually wanted to be asking.

Here is the before and after, in the terms a buyer feels. Before, the cost of a custom skill scaled with the number of platforms you wanted it on, because each one meant another build. After, you pay for the capability once and the portability rides along. The repeated column of spend collapses into a single entry.

That is the good outcome, and it is worth being concrete about who gets it. A company running agents across more than one client, which is more of them than you would think once you count the coding assistant, the support tool and the internal workbench separately, stops paying the platform tax on every skill. A company that commissions agent work gets a cleaner asset: a deliverable that is not quietly worth less the day it decides to switch vendors. And a builder that ships plugins instead of platform-specific configs is handing over something the client can actually keep.

Read the spec and you find the limit stated plainly: installation, distribution, policy, permissions and user experience are left to each client. That is a deliberate design choice, and it is the difference between a package being portable and an agent behaving identically everywhere. The folder moves. What a client does with it once it lands is the client's call.

So "write once, run anywhere" is the wrong slogan to lift from this. "Package once, still test everywhere" is closer. A plugin that grants a tool broad access on one client might get a permission prompt on another, or a different sandbox, or a different default. A skill that assumes one client's file conventions may not find them on the next. None of that is a flaw in the standard. It is the standard being honest about what it does and does not cover, and it means the per-client validation work does not vanish. It shrinks. If a vendor tells you a plugin is portable and therefore done, that is the sentence to push on.

There is a second thing nobody put in a headline. A shared package format is also a shared distribution channel, and shared distribution channels are where supply-chain risk grows. A plugin bundles skills and tool connections that an agent will execute, and the spec deliberately leaves trust and provenance to clients rather than solving them centrally. We walked through what happens when agent controls fail at the top of the market, and the lesson transfers cleanly: a convenient way to share capability is also a convenient way to share a problem. Vet a plugin the way you would vet a dependency, because that is what it is.

It is easy to read "open, free, portable" and conclude the cost of agent work is falling. The build cost tied to lock-in is falling. The cost of running agents is not, and it is the far bigger number. A format that makes a skill trivial to load into five clients also makes it trivial for five teams to start burning tokens with it, none of them metering, and that is the spend that actually moves a budget. McKinsey found 93% of enterprises already exceed their AI budgets, and we went through what that does to a build in our piece on running agent work in-house. A package format does nothing about it. The rebuild you just stopped paying for was never where the money went.

Three moves, in order.

1. Make portability a question you ask out loud. If you are commissioning agent work now, ask whether the deliverable ships as an Agent Plugin or as platform-specific config. The answer tells you whether you are buying an asset or renting one, and it costs nothing to ask before the contract is signed. This is the same first-call discipline we push for vetting any agent build team: the good ones have already thought about what you keep.
2. Do not rip anything out to chase this. The standard is a week old, client support is real but uneven, and "portable" still means "test on each client." If your current agents work, they keep working. Make new work portable by default rather than migrating working systems for a property you are not using yet.
3. Treat plugins as dependencies from day one. The moment your team can install a shared plugin in a click is the moment you need a rule about which plugins, from where, with what access. The convenience and the risk arrived in the same release, and only one of them is self-limiting.

We build agents for a living, so weigh this accordingly: the part of that work worth paying for was never the platform-specific typing that this standard removes. It is the scoped access, the evals that catch drift before your customers do, and a named owner when something breaks. A portable package makes the deliverable more valuable to you, which is a good reason to care what is inside it.