Six of the biggest names in agent infrastructure — Amazon, Cursor, Microsoft, OpenAI, Vercel, and now Google — just signed onto Agent Plugins 1.0.0. The standard is two lines of manifest, one directory layout, and a deliberate refusal to solve the rest of the problem. That restraint is the only reason six of them agreed. Here is what the box looks like, what it does not do on purpose, who is shipping at launch, and why the thin-standard critics are answering the wrong question.

The Agent Stack Just Got Its First Shared Manifest. The Critics Are Missing Why That's The Whole Point.

Hey guys, Mr. Technology here.

At some point this week — depending on which timezone you read the announcement in — six of the largest names in agent infrastructure all signed their names to the same line: Agent Plugins 1.0.0. Amazon, Cursor, Microsoft, OpenAI, and Vercel are the founding TSC. Google joined this week as a Core Maintainer, with Kevin Hou of DeepMind taking the seat. GitHub is in the room but not on the steering committee yet. The spec lives at agent-plugins.org, the schema is at agent-plugins.org/schemas/1.0.0/plugin.schema.json, and the GitHub org is the very on-brand agentplugins/agent-plugins-spec.

This is the first time anyone in agent infrastructure has agreed on what a plugin looks like. It is also the first time the word "plugin" has meant something coherent in this space. Read the announcement wrong and it sounds like a packaging story. Read it right and you realize it is the answer to a question we have all been quietly failing at for eighteen months.

The Question Nobody Wanted To Answer Out Loud

Pick any two of these products: Claude Code, GitHub Copilot, Cursor, Gemini CLI, Antigravity, Kiro, VS Code, ChatGPT, Codex, your IDE plugin manager. Ask each one of them to ship the same Skill + MCP server combo. Now watch what happens.

The skill is fine. The MCP server is fine. The wrapper around them is not. The directory layout is different. The manifest wants different top-level metadata. The MCP configuration uses a different shape and infers transports differently. So you fork the package, maintain two copies of components that were never different in the first place, and watch them drift.

This is the part of the Google blog post Kevin Hou actually got right when he wrote: the core problem isn't the components. It's the manifest. That sentence is the entire post if you take it seriously.

Agent Skills were already portable — that is what the SKILL.md spec did. MCP was already portable — that is what the protocol was for. What was not portable was the box you put them in, and that box was the thing every client had to invent for itself. Five different companies wrote five slightly different directories and called them a packaging format.

What Agent Plugins 1.0 Actually Is

A plugin is a directory. That is the whole idea, and the restraint is the point. Here is the canonical layout from the spec:

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

The manifest is two lines of substance:

json

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin"
}

That is it. Notice what plugin.json cannot do. It cannot relocate components. It cannot declare them inline. There is no discovery path to configure and no precedence order to learn. If skills/ is not there, the client loads what is there and moves on. An mcp.json server that fails to start does not take the plugin's skills down with it — the client skips that entry, keeps loading, and reports the failure. Independent components fail independently.

That last reverse-domain directory — com.example.client/ — is the escape hatch. It is an extension namespace owned entirely by one client, for hooks, agents, commands, or anything else that client wants to add. Clients that do not recognize it ignore it. The portable core stays small because the non-portable parts have somewhere legitimate to go.

The Smart Restraint

Agent Plugins v1 is a package format and nothing more. It defines:

No install mechanism
No distribution protocol
No permission model
No sandboxing requirements
No trust or provenance verification
No user experience

Those are named openly in the project's FUTURE_CONSIDERATIONS.md, not quietly omitted. The reasoning is straightforward: installation, policy, enterprise controls, and approval UX are quite different across an IDE, a CLI, and a managed enterprise platform. Each agentic application has genuinely different obligations to their users.

This is the right call. The temptation on a new standard is to define everything. The discipline here is to define only the part where everyone actually agrees.

Not Every Skill Should Be A Plugin

Before you reach for a plugin, ask whether you need one. The spec is explicit about this and most readers will miss it:

If you are shipping a single MCP server to a single client, mcp.json on its own is still the simpler answer.
If you have a single skill, you do not need a plugin. Use the SKILL.md spec directly.
Agent Plugins earns its keep when you have components that belong together and need to travel together.

This matters because the next twelve months will produce a wave of plugin-packaged-single-skill wrappers that should not exist. The standard is a contract, not a costume.

The Ecosystem Layers

Packaging is one job. Discovering and getting a plugin to a user is a different job, and it is worth being precise about which layer does what.

Layer	Job	Spec / Protocol
Find	"What is available for this task?"	Agentic Resource Discovery
Describe	Catalog entry that points at a plugin	AI Catalog
Package	One directory, fixed locations	Agent Plugins
Run	The execution contracts	MCP + Agent Skills

Each layer is independently useful and independently adoptable. You can publish a plugin with no catalog entry, catalog a resource that is not a plugin, and run skills with no plugin at all. Adopting one never obligates you to the next.

ARD already treats a Plugin as a first-class agentic resource type, alongside agents, MCP servers, and Skills. There is a pending PR on AI Catalog to register application/agent-plugins+json as a known type. The plumbing is being laid one spec at a time.

The Critics Are Right, Sort Of

Dax Raad, who builds the SST developer-tools framework, told The Next Web he is "very much against" the standard, calling it "a thin standard" whose useful parts will end up in client-specific extensions anyway.

He is not wrong. He is just answering the wrong question.

The thinness is the point. The things he is worried about — install mechanism, permission model, sandboxing, marketplace UX, trust — are intentionally out of scope because every client has a different answer and the standard would die if it tried to pick one. Client-specific extensions are not a failure mode. They are the explicit escape hatch (com.example.client/) the spec authors built so the non-portable parts have somewhere to live.

The alternative history is the one we have been living. A year ago every agent framework was inventing its own plugin format. A year from now we would have seven. The fact that the standard is thin is the only reason six of them agreed to it.

Developer advocate Angie Jones got the response closer to right: "We neeeeded this." She had wanted one way to carry her skills between the tools she uses for two years. That is the entire constituency the standard is built for.

What This Means If You Build In This Space

If you publish an MCP server today, you ship a manifest. If you publish a Skill today, you ship a SKILL.md. After Agent Plugins 1.0 you have the option to ship both in the same folder, with a plugin.json that is two lines, and have it work in every compatible client.

Compatible clients at launch, per the spec and the announcements: Antigravity, Gemini CLI, Claude Code, Cursor, GitHub Copilot, Kiro, VS Code, ChatGPT, Codex. That is not all of them. That is enough of them that "build once, run anywhere" stops being a slogan and starts being an accountant's spreadsheet.

For us at mr.technology — we already ship a Skills registry, an MCP server (/api/mcp), and a security audit pipeline that ingests and detonates plugins before they reach user code — the move is the one Kevin Hou spelled out in the post. Plugin.json is two lines of substance. We add support for the layout, we keep our audit posture, and we let independent components fail independently. A mcp.json server that fails to start should not take the plugin's skills down with it. The standard agrees. So do we.

For everyone else: package the Skill + MCP combo you actually ship together. Keep the single-skill and single-server cases on their native formats. Do not reach for a plugin when mcp.json is the simpler answer.

The Plumbing Is Agreed

The standard does not solve trust. It does not solve discovery. It does not solve marketplaces. It does not solve the security question that hit the Skills ecosystem earlier this year when fake Skills slipped past scanners. Those are the unsolved problems The Next Web flagged correctly.

What it does solve is the smallest, hardest, most ignored problem: what does a plugin look like on disk. That is the same answer Linux distros gave with .deb and .rpm, the same answer browsers gave with .crx, the same answer Node gave with package.json. None of those formats solved distribution, trust, or UX. All of them made everything downstream cheaper to build.

A shared format could let a small developer reach every major agent at once. That is the open-ecosystem case and it is real. It could also cement the handful of clients that already have the users, because a standard rewards whoever people already run. Both of those are possible at once. The plumbing is agreed. The fight over the parts it leaves out — the marketplaces and the trust — has barely started.

Build one. It takes about a minute.

Sources: