Agent Plugins: the new open standard for AI agent extensions

What Agent Plugins actually is

I ship integrations for a living, so my first reaction to any new standard is to check how much of it is real spec and how much is a press release. This one is mostly spec.

Agent Plugins describes itself as an open, vendor-neutral standard for packaging reusable components that extend AI agents. In practice it standardizes one thing: the shape of the folder. Where the manifest lives, what fields it may contain, where a client should look for skills, and where it should look for MCP server config. Everything else, including installation, marketplaces, permissions and the entire user experience, stays with each client.

The smallest plugin that does anything is three files:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

And the manifest can be two lines:

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

That is it. $schema and name are the only required fields. Everything else, version, description, author, homepage, repository, license, keywords, extensions, is optional.

The problem it is solving is dull and real. Every agent client grew its own plugin format, so the same skill had to be rearranged per client, and a package built for one needed adapting before another would load it. If you have ever maintained the same SKILL.md in four repo layouts, you already know the shape of the pain. It is the same fragmentation that made ChatGPT plugins and GPTs and Actions awkward to reason about a couple of years ago, only now there are more clients.

What goes in a plugin, and what does not

Version 1 defines exactly two component types. Skills and MCP servers. That is a deliberately small number and it is the most interesting design decision in the whole document.

Both live at fixed locations that the manifest is not allowed to override. Skills go in skills/, one subdirectory each, containing a SKILL.md. MCP config goes in mcp.json at the root. The spec is explicit that a client must not recurse deeper looking for extra skills, and must not accept MCP config declared inline in plugin.json.

For the SKILL.md format itself, the spec hands off entirely: skills must conform to the Agent Skills specification, which stays the source of truth for frontmatter and the scripts/, references/ and assets/ layout. Agent Plugins only says where to find them.

Here is what travels and what does not:

Anything a client wants to add on top goes in a reverse-domain namespace, either as a key under extensions in the manifest or as a top-level directory named com.example.client/. Other clients are required to ignore namespaces they do not implement, without even validating what is inside. That is a small rule with a big consequence: a plugin can carry client-specific extras and still load cleanly everywhere else.

The MCP side has more teeth than I expected. Three transports are recognized, stdio, streamable-http and the deprecated sse, and a conformant client must support at least one of the first two. Remote endpoints must use HTTPS unless the host is loopback. Every stdio subprocess gets PLUGIN_ROOT and PLUGIN_DATA environment variables, and ${PLUGIN_ROOT} and ${PLUGIN_DATA} expand inside args, env and cwd but nowhere else. Path containment is enforced throughout, so a command of ../bin/server is invalid rather than merely discouraged.

Failure isolation is the part I would actually lean on in production. A broken MCP entry disables that server, not the plugin. A malformed SKILL.md skips that skill, not the folder. A plugin that fails schema validation on the manifest, though, is rejected outright and none of its components run. Those boundaries are spelled out one by one, which is a good sign that people who have shipped this stuff wrote it. Anyone who has debugged a half-loaded MCP integration will appreciate the precision.

Which parts of your extension actually travel

Rather than describe the split again, here is the same information you can poke at. Pick a component and see whether it survives a move between clients.

Who is actually behind it

Standards live or die on governance, so this is the section I read first.

The Technical Steering Committee is five people, each named as an individual with an affiliation attached rather than a company holding a seat:

Vercel's announcement credits a slightly wider group, naming Amazon Web Services, Anysphere, GitHub, Microsoft, OpenAI and Vercel as having developed the standard together.

The charter has three clauses worth reading twice. No single vendor may control a majority of Core Maintainer seats. All governance roles are held by individuals, and no seats are reserved for companies. And the name, logos, domains and GitHub organizations are held in trust by a neutral entity designated by the committee, with no vendor permitted to claim exclusive control of project identity.

The paper trail supports that. The repository was incubated at vercel-labs/open-plugin-spec and now sits under a separate agentplugins organization, with the spec text under CC-BY-4.0 and the code under Apache 2.0. If the neutrality claim ever stops holding, the licensing means the thing is forkable rather than captured. That is roughly the same playbook the industry ran with the agentic commerce protocol work, and it is a better sign than a consortium press release with no repo behind it.

The Anthropic-shaped absence

Anthropic does not appear on the maintainer list, and Claude Code is not among the launch clients Vercel names. That is worth sitting with, because Claude Code is where a very large share of real plugin authoring currently happens, and because Agent Skills started there.

The formats are close but not compatible. Anthropic's documented plugin layout puts the manifest at .claude-plugin/plugin.json and MCP config at .mcp.json, both hidden paths, where Agent Plugins uses visible plugin.json and mcp.json at the root. Claude Code also ships component types the standard does not cover at all, and the same shape shows up again in the Cowork plugin format and in the IDE plugins.

Those are file-path differences, which is the most fixable kind of incompatibility there is. A plugin could carry both manifests today without much drama. But until someone does the work, an author targeting both ecosystems is still maintaining two layouts, which is precisely the problem the standard set out to remove. I would not read the absence as a rejection, and there is no public statement either way. I would read it as unfinished.

It is worth noting that the same pattern is playing out elsewhere. Atlassian ships Rovo agent skills, ServiceNow ships its own agent skills, and Freshworks ships a prebuilt skills library. None of those are in scope for a spec aimed at coding agents, but they are the same idea packaged five different ways, which tells you how early this all is.

What version 1.0.0 deliberately leaves out

This is the section I would want a security reviewer to read before anyone installs anything.

The maintainers are refreshingly blunt about the gaps. A dedicated future considerations document lists, as things v1.0.0 does not define:

• A trust model, permission system or sandboxing. No capability declarations, no consent flows, no graduated trust levels.
• Provenance verification. No signature checking, no attestation linking a published plugin back to its source repo.
• Secret handling. The spec bans credentials in env and in HTTP headers, and offers no portable alternative.
• Enterprise controls. No allowlists, no blocklists, no org-scoped registries, no centralized policy overrides.
• Audit trails. No standard event schema for install, enable, update or uninstall.
• Dependency resolution. Plugins cannot declare dependencies on other plugins.

The spec does carry real safety rules where it can: paths must stay inside the plugin root, non-loopback MCP endpoints must use HTTPS, configured headers must not be forwarded across a redirect to a different origin without explicit user authorization, and clients must not fetch a schema over the network while loading a plugin. Those are sensible. They are also all about the package, not about what the package is then allowed to do.

So the honest read is this. Agent Plugins solves distribution. It does not solve trust. An MCP server inside a plugin can launch an arbitrary process with your environment, and the standard has nothing to say about whether it should be allowed to. Whether that is fine depends entirely on which client you install it in and what permission controls that client happens to ship. On the Claude Code side that means admin controls and settings.json; elsewhere it means whatever that vendor decided.

What this means if you buy AI agents instead of building them

Most people reading about a plugin spec are developers. But the second-order effect lands on anyone evaluating AI agents for a business function, and support is the clearest case.

The pitch of a portable plugin format is that your extension is not hostage to one vendor. That is real, and it is a good reason to prefer clients that adopt it. It is also narrower than it sounds, because portability of the package is not portability of the outcome. Your SKILL.md moving cleanly between two clients does not mean the agent behaves the same in both, that it has the same tool permissions, or that it resolves the same share of tickets. That last number is the one that pays for the project, and it is what an AI agent for customer service actually gets judged on.

I see the same reasoning play out in build-versus-buy conversations constantly. One engineering lead we worked with put the calculation better than I could:

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

That is an engineering lead running a 300-plus article Confluence and Telegram knowledge base, who chose to buy rather than build. A standard lowers the cost of assembling pieces. It does nothing about the ongoing cost of owning the result, and that is where these projects actually get expensive.

The three questions I would put to any vendor, standard or no standard:

1. Can I export what I taught it? Prompts, rules, escalation logic. If the answer is no, a portable plugin format changes nothing about your lock-in.
2. Who decides what it can touch? Since v1 defines no permission model, this is a per-client answer, and you should get it in writing before anything reaches a live queue. For regulated teams that folds straight into your data privacy review.
3. Can I test it against my own history before it goes live? Simulation against scenarios someone wrote is not the same as a dry run over your own past tickets.

That third one is the one I would not compromise on. We have watched a confident-sounding bot quietly give wrong answers, which is exactly why every rollout at eesel gets simulated against historical tickets first rather than switched on and watched.

Try eesel for support that plugs into what you already run

eesel takes the same idea Agent Plugins is chasing, meeting you where you already work, and applies it to the helpdesk. It connects to Zendesk, Freshdesk and Gorgias, plus Slack, Confluence and the rest of your internal knowledge base, then drafts or resolves from what it learns there.

The differentiator is the third question above. Before eesel replies to a single live ticket, you run it over your own ticket history and see what it would have said, on which tickets, at what confidence. Then you pick which ticket types it is allowed to touch. It is free to try, and setup runs in minutes rather than a quarter.

Where this goes next

My read after a day with the spec: the format is small enough to be adopted quickly, the governance is stronger than most first-version standards, and the security story is a deliberate hole with a roadmap attached. A minimal spec that ships beats a comprehensive one that argues, and Agent Plugins is clearly the former.

The two things I would watch. Whether Anthropic converges, since the gap is basically two file paths and one ecosystem's worth of extra component types. And whether v1.1 lands a permission model before someone ships a plugin that makes everyone wish it had.

If you are picking AI agent tools right now, whether that is a coding agent like Cursor or an agentic CLI, treat Agent Plugins support as a mild positive signal about a vendor's posture on lock-in. Then treat their answers about permissions and testing as the thing that actually decides it.