Agent Plugins 1.0: One Package Format for Every AI Agent

What is Agent Plugins? Agent Plugins 1.0 is an open, vendor-neutral packaging standard – published August 6, 2026 – that bundles Agent Skills and MCP server configurations into a portable directory any compatible agent client can load. A plugin is a folder with a required plugin.json manifest, an optional skills/ folder of Agent Skills, and an optional mcp.json declaring MCP servers. ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code support it at launch.¹²

Six companies that compete with each other every day shipped one shared answer to a problem every agent user has felt: the extension you built for one agent client does not work in the next one. Vercel initiated the proposal and developed the specification with Amazon, Anysphere (Cursor’s maker), GitHub, Microsoft, and OpenAI;² Google announced the same day that it is joining the core maintainers and building support into its own products.⁶ The official site’s one-line summary: “A portable package format for reusable components that extend AI agents.”¹

The name of the company that authored both layers being packaged is not on the maintainer list. That absence is half the story, and the second half of this post.

TL;DR: Agent Plugins 1.0 standardizes the packaging layer around two existing specs – Agent Skills and the Model Context Protocol – and replaces neither: it fixes where both live inside a shareable directory.¹ A plugin is a folder: plugin.json for identity, skills/ for skills, mcp.json for servers, plus reverse-domain namespace folders for client-specific extras. Version 1 is deliberately an interoperability floor – the spec defines no portable semantics for installation, registries, permissions, provenance, secrets, or OAuth; all of that remains client-managed.¹² Codex shipped support across v0.146.0 and v0.147.0.⁴ Anthropic, which created Agent Skills and MCP, is not among the maintainers – Claude Code keeps its own plugin format.³⁷⁸

Key Takeaways

• Solo developers: Author your skills as standard Agent Skills (a folder with a SKILL.md) and they are already the portable substrate – wrapping them in a plugin is a manifest away. Stop maintaining per-client copies.
• Team leads: The standard covers packaging, not distribution or policy. Your registry, your update mechanism, and your allow-list story are still per-client decisions – budget for that before promising “write once, run anywhere” internally.
• Security engineers: Version 1 defines no provenance or permissions layer, and no signing layer either – the trust decision moves entirely to your install-time review. Portability widens the blast radius of poisoned-skill attacks.

What Shipped

On August 6, 2026, Vercel published Agent Plugins 1.0.0 – an open specification it initiated and developed with Amazon, Anysphere, GitHub, Microsoft, and OpenAI.² The normative spec lives in a public repository whose maintainer roster spans Amazon, Cursor, Microsoft, OpenAI, and Vercel,³ and Google announced on launch day that it is joining that group as a core maintainer, with support already rolling into its own agent tooling.⁶

The launch-day client list spans the ecosystem’s biggest surfaces: VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, and Kiro.¹² Codex’s CLI support actually preceded the public announcement – v0.146.0 (July 29) added Agent Plugins manifests and workspace plugin publishing, and v0.147.0 (August 7) completed the loop with portable plugin installation and search across local, personal, workspace, and remote catalogs.⁴

The scope is stated in the spec’s own opening line: it “defines the canonical Agent Plugins Specification v1.0.0 for packaging reusable components that extend AI agents into distributable plugins.”¹ Packaging – not a new skill language, not a replacement for MCP. Both underlying formats keep their own specifications; this standard fixes where they live inside a directory a client can discover.

The Anatomy of a Plugin

A plugin is a directory with one required file and three optional surfaces:¹

my-plugin/
├── plugin.json              # required: identity + metadata
├── skills/                  # optional: Agent Skills
│   └── release-notes/
│       └── SKILL.md         # one immediate subdirectory = one skill
├── mcp.json                 # optional: MCP server configs
└── com.example.client/      # optional: client-namespace directory

plugin.json is a closed-schema manifest. The permitted top-level fields are exactly ten: $schema, name, version, description, author, homepage, repository, license, keywords, and extensions – and the spec is strict about everything else: “Clients MUST report and ignore each unknown field and MUST continue loading the plugin if the manifest otherwise satisfies this section.”¹ The name field allows lowercase alphanumerics, hyphens, and periods, with alphanumeric first and last characters and no consecutive hyphens or periods.¹

skills/ holds Agent Skills exactly as they already exist: “Each immediate child directory containing a path named exactly SKILL.md that resolves to a regular file is treated as one skill.”¹ mcp.json declares MCP servers; a client that supports plugin MCP servers “MUST support at least one of stdio or streamable-http” and SHOULD support both, with sse optional – and the spec explicitly permits a skills-only client to conform without supporting MCP servers at all.¹

Reverse-domain directories like com.example.client/ hold client-specific behavior, with the portability rule written in normative language: “A client MUST ignore manifest entries for namespaces it does not implement without validating the contents of their values.”¹

That last mechanism carries more weight than it looks. The components that differ most across clients are fenced out of the portable core: commands, hooks, agents, rules, and LSP servers are the spec’s own examples of component types that “remain too client-specific for a stable portable contract” and sit outside the v1 format until their formats converge.¹ The portable core is skills plus MCP configs, full stop.

What Version 1 Deliberately Leaves Out

The spec standardizes the smallest thing that could work. It defines no portable semantics for installation, registries, permissions, provenance, secrets, or OAuth – every one of those remains client-managed¹² – and it defines no signing layer either. The maintainers’ expansion path is conservative by design: component types graduate into the portable core only once implementations converge enough to define them precisely.¹

Read that as coalition physics rather than timidity. Six companies – five of them shipping agent clients with incompatible plugin formats – could agree on where files live; they could not agree – yet – on how hooks fire, how commands register, or whose permission model wins. So the standard froze the layer where behavior already converged (skills are markdown folders, MCP is a wire protocol) and fenced everything contested into namespaces. It is an interoperability floor, and floors are useful precisely because everyone can stand on them.

The cost of that floor: “build once, run anywhere” applies to the package, not the experience. A plugin installs everywhere; what it can do still varies per client, and how it gets installed, updated, and trusted is entirely per client.

The Anthropic-Shaped Hole

Here is the strange part. Agent Skills – the folders-of-instructions format the standard packages – is Anthropic’s creation, announced in October 2025.⁸ So is the Model Context Protocol, which Anthropic open-sourced in November 2024.⁷ Both layers under this packaging standard came from the one major agent-tool vendor whose name appears nowhere in the maintainer roster.³

Claude Code keeps its own plugin format – its own manifest, its own marketplace sources, its own hooks-and-commands packaging – and nothing announced on August 6 changes that. The bridging, for now, runs in one direction: Codex ships a Claude Code marketplace source (v0.146.0), and its /import command migrates Claude Code settings, MCP servers, plugins, sessions, commands, and project-scoped memories into Codex.⁴

Practically, the seam is narrower than the org chart suggests, and the reason is the substrate: a skill is a folder with a SKILL.md, in every ecosystem. Skills you write for Claude Code are the same artifact an Agent Plugin carries. What does not travel is the wrapper – Claude Code’s plugin manifest on one side, plugin.json on the other – and the client-specific components (hooks above all) that each ecosystem keeps native. If you maintain skills today, you are already writing the portable layer; the divergence is packaging, not content.

Whether Anthropic eventually adopts the format, publishes an equivalent, or lets the bridge stay one-directional is the open question this launch poses. The coalition’s composition – every major agent-client vendor except one – makes the packaging standard’s trajectory depend less on its technical merits than on whether the absent author of its two underlying layers decides the floor is worth standing on.

The Supply-Chain Question Nobody Standardized

A portable package format with no provenance layer is also a portable attack format. Version 1 leaves provenance and permissions client-managed and defines no signing or validation tooling,¹ which means the trust decision lives entirely at install time, per client, per user.

That matters more this month than last. Recent research on skill-level attacks – ElasticBack is the sharpest example – demonstrates conditional backdoors planted in a single skill document, and frames agent skills as “an emerging supply chain where a single poisoned skill can persistently compromise every agent that installs it.”⁵ Portability multiplies that: the same poisoned plugin now installs into six clients instead of one, and the standard’s scope leaves detection to whatever review each client (or each user) performs.

I made the fuller argument before this standard existed in Agent Skills Need Package Managers: agent context has become a software supply chain, and installing it safely needs the machinery package ecosystems already learned to build – manifests, lockfiles, scoped installs, review gates, rollback. Agent Plugins 1.0 delivers the manifest and stops there; the rest of that list is exactly what v1 leaves to clients. Inspect what you install; the format will not do it for you. (One adjacent gotcha from Skills My Agent Could Not See: agents load skill descriptions under a hard context budget, and plugin-shipped skills join that same catalog – portability adds skills to a queue that already silently truncates.)

What To Do Today

If you use Codex: you already have the standard. codex plugin surfaces portable Agent Plugins installation, and plugin search spans local, personal, workspace, and remote catalogs as of v0.147.0.⁴ Teams can publish plugins into their own workspace rather than standing up a public marketplace.

If you use Claude Code: nothing changes in your plugin format. Keep authoring skills as standard skill folders – that is the portable layer – and treat the wrapper as disposable. If you also run Codex, its Claude Code marketplace source and /import carry your existing setup across.⁴

If you use VS Code, Cursor, Copilot, ChatGPT, or Kiro: you are on the launch-client list; how plugins install is your client’s UX, because the standard deliberately does not specify it.¹

If you ship developer tooling: the manifest is small enough to adopt in an afternoon, and the spec repository is public.³ The interesting decision is not whether to read plugin.json – it is which of your components you fence into your reverse-domain namespace, because that boundary is the de facto declaration of what you consider portable.

FAQ

Does Agent Plugins replace MCP or Agent Skills?

No. The spec’s stated job is “packaging reusable components that extend AI agents into distributable plugins”¹ – skills keep their SKILL.md format, MCP servers keep their protocol, and the standard fixes where both live inside a shareable directory.

Can a plugin ship hooks, slash commands, or custom agents?

Not portably, not in v1. The spec names commands, hooks, agents, rules, and LSP servers as examples of component types that “remain too client-specific for a stable portable contract” – outside the portable format until their shapes converge. A client can carry them inside its reverse-domain namespace directory, and clients MUST ignore namespaces they do not implement.¹ The portable core is skills plus MCP configurations.

Why isn’t Anthropic part of the standard?

Neither the spec nor the coalition has said. What is public: the maintainer roster spans Amazon, Cursor, Microsoft, OpenAI, and Vercel, plus Google joining at launch,³⁶ while Anthropic – creator of both Agent Skills and MCP⁷⁸ – is absent, and Claude Code retains its own plugin format. The practical bridge today is Codex-side: its Claude Code marketplace source and /import migration.⁴

Is it safe to install third-party Agent Plugins?

The format gives you no help deciding: version 1 leaves permissions and provenance client-managed and defines no signing or validation tooling.¹ Treat a plugin like any code you grant your privileges to. Skill-level backdoor research (ElasticBack) shows a single poisoned skill document can conditionally compromise every agent that installs it, and portability multiplies the installed base.⁵

References