# Agent Plugins: OpenAI, Microsoft, Amazon, Cursor and Vercel Agreed on One Plugin Format *The Agent Plugins standard shipped on 6 August 2026. I adopted it the next day in both of my repos, and this is what it specifies, who governs it, and what it actually cost.* > Agent Plugins 1.0.0 is an open, vendor-neutral standard for packaging AI agent plugins, released 6 August 2026 and governed by a Technical Steering Committee with Core Maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel. A plugin is a directory with plugin.json, a skills/ folder in Agent Skills format, and an mcp.json describing MCP servers. This explains what the spec requires, how its governance charter enforces vendor neutrality, how it differs from MCP and Agent Skills, and what adopting it on day one cost me across a 13-skill library of testing skills for agents and a 33-skill second brain. Published: 2026-08-07 · Reading time: 9 min · Tags: agent-plugins, ai, agents, standards, mcp, agent-skills, testing Canonical URL: https://huytieu.com/blog/agent-plugins-standard/ Author: Huy Tieu (huytieu.com) --- My library of testing skills for agents has 13 skills in it. Building it produces 124 files. I wrote the build script that does this, so I have nobody to blame. The 13 skills are the actual work: how to plan a test cycle, how to design cases from a requirement, how to read a failing run and decide whether the release is safe. The other 111 files are packaging. Four of them I added this week and they are the rest of this post. The remaining 107 exist because until this week, every agent wanted that same knowledge handed to it in a slightly different shape. ``` skills/ (13 SKILL.md files, the only real content) | +--> plugins/ Claude Code, Codex, Cursor plugin +--> .cursor/rules/ *.mdc, its own frontmatter +--> .kiro/steering/ inclusion: manual +--> .github/skills/ plus .github/prompts/, separately +--> .windsurf/rules/ trigger: model_decision +--> .clinerules/ no frontmatter at all +--> .continue/rules/ name + description + alwaysApply +--> AGENTS.md the fallback for everyone else 107 files of transcription ``` None of that is interesting. It is transcription. Every agent that gains traction means another emitter to write and another thirteen files to keep from drifting out of sync with the skills they are supposed to mirror. Then on 6 August 2026, five companies that compete with each other agreed on a format. [Vercel announced Agent Plugins 1.0.0](https://vercel.com/blog/introducing-agent-plugins), with Amazon, Cursor, Microsoft and OpenAI on the steering committee and GitHub in the room for the drafting. I adopted it the next day, in that repo and in my [personal second brain](https://github.com/huytieu/COG-second-brain), which has the same disease with 33 skills instead of 13. ## What is the Agent Plugins standard? Agent Plugins is an open, vendor-neutral standard for packaging reusable AI agent components into a portable plugin. Version 1.0.0 was published on 6 August 2026 at [agent-plugins.org](https://agent-plugins.org). It defines a directory layout that any conformant agent client can load, so a plugin author packages once instead of once per client. It is a packaging format and nothing else. I read the [whole specification](https://agent-plugins.org/specification) in one sitting, which is the first thing I liked about it. A plugin is a directory: ``` my-plugin/ |-- plugin.json identity + which spec version |-- skills/ | `-- summarize/ | |-- SKILL.md | |-- scripts/ | `-- references/ |-- mcp.json MCP servers this plugin ships |-- com.example.client/ optional, client-specific `-- LICENSE ``` ## What does plugin.json require? `plugin.json` requires exactly two fields: `$schema`, pinning the spec version, and `name`. Everything else is optional metadata that looks like a `package.json` you have written a hundred times: `version`, `description`, `author`, `homepage`, `repository`, `license`, `keywords`. ```json { "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json", "name": "katalon-true-platform", "version": "0.3.0", "license": "MIT" } ``` Two required fields. That is the whole barrier to entry. The skills are not redefined. The spec says they MUST conform to the [Agent Skills specification](https://agentskills.io), the SKILL.md format Anthropic built and released as an open standard, which Cursor, Copilot, VS Code, Gemini CLI, Kiro and a long list of others already read. Agent Plugins does not compete with that. It says where skills live and how they travel. `mcp.json` describes the [MCP](https://modelcontextprotocol.io) servers a plugin brings, in three transports: `stdio`, `streamable-http`, and `sse` for the legacy case. Two environment variables are guaranteed, `PLUGIN_ROOT` and `PLUGIN_DATA`, and they expand inside `args`, `env` values and `cwd`. They do not expand inside `command`, which stays one executable token. That restriction is small and I appreciate it: a manifest cannot smuggle a shell expression into the thing my machine is about to run. ## What the spec deliberately leaves out The part I keep coming back to is what it refuses to do. No registry. No conformance badge. Nobody to register with. Conformance is self-declared by implementing the behaviours. Client-specific features go into reverse-domain namespaces, both as a key in the manifest and as a top-level directory: ``` my-plugin/ |-- plugin.json `-- com.example.client/ `-- hooks/ `-- hooks.json ``` Clients ignore namespaces they have not implemented, without validating them. That one rule is what lets the format stay this small and still leave room for clients to differentiate. Hooks, telemetry config, some future thing nobody has built: all of it fits without a spec revision, and none of it breaks a client that has never heard of it. The repo also ships a [FUTURE_CONSIDERATIONS document](https://github.com/agentplugins/agent-plugins-spec) listing what was deliberately deferred from 1.0.0: permission and consent flows, cryptographic provenance, secret handling, enterprise allowlists, audit-trail schemas, dependency resolution between plugins, and conformance test suites. Seven genuinely hard problems. A 1.0 that tried to answer them would have landed in 2027 and been wrong about most of them. ## Who governs the Agent Plugins standard? The standard is governed by a Technical Steering Committee. Its Core Maintainers are Clare Liguori (Amazon), Roshan Sadanani (Cursor), Harald Kirschner (Microsoft), Gav Verma (OpenAI), and Jonathan Hefner (Vercel), who serves as Lead Core Maintainer. Vercel initiated the proposal, and AWS, Anysphere, GitHub, Microsoft and OpenAI worked on the specification before publication. The names matter less to me than the [governance charter](https://github.com/agentplugins/agent-plugins-spec), which makes promises about what cannot happen: ``` no single vendor may hold a majority of Core Maintainer seats no seats are reserved for specific companies project assets held in trust by a neutral entity spec licensed CC-BY-4.0, code Apache 2.0 maintainers selected partly on "multi-vendor neutrality" ``` The way a format like this dies is not by failing to launch. It launches, gets adopted, and then bends toward whoever controls the reference implementation until conformance quietly means compatibility with one company's product. Writing the neutrality constraints into the charter before adoption is the only defence I know of, and it is cheap to write while a project is new and expensive to retrofit once a sponsor has something to protect. ## How is this different from MCP and Agent Skills? The three sit in a stack and do not overlap. ``` Agent Skills what a capability IS SKILL.md + scripts/ + references/ MCP how an agent CALLS it stdio / streamable-http / sse Agent Plugins how you SHIP both plugin.json + skills/ + mcp.json ``` [MCP](https://modelcontextprotocol.io) standardized how an agent reaches a tool at runtime, and tool builders stopped writing one integration per assistant. It says nothing about distribution, so you could build an excellent MCP server and a good set of skills and still be stuck on how to hand the bundle to someone who uses a different editor. Agent Plugins fills that gap and nothing else. One is the wire protocol, the other is the shipping container. ## What adoption actually cost Less than I expected in one repo. More than I expected in the other. For the skills library it was genuinely small. I added the emission to the build script that already generates the other eight formats, so a `plugin.json` and an `mcp.json` now fall out at the repo root and inside the plugin directory. The MCP config needed translating rather than copying, because Claude's `.mcp.json` shape and the standard's are not the same file with a different name: the standard wants an explicit `"type": "stdio"` and its own `$schema`. Then I validated both files against the published schemas with `ajv` before I trusted any of it: ``` $ npx ajv-cli validate --spec=draft2020 \ -s plugin.schema.json -d plugin.json plugin.json valid ``` That took an afternoon, most of it reading. My second brain was messier, because its canonical skills live in `.claude/skills/` and the spec wants them at `skills/`. I did not want two hand-maintained copies, which is the exact disease I was trying to cure. So the root `skills/` is a generated mirror, there is a one-command script that rebuilds it, and the packaging validator now fails if the two trees differ at all. If I edit the mirror by hand, the build tells me off. That felt like the right shape: the standard gets a real directory, and the source of truth does not move. The unglamorous part was version bookkeeping. My repo had shipped a release while I was working, my branch collided with it on rebase, and the version I had already written into four different manifests was taken. So the validator now checks version alignment across all four manifests plus the version file, because I clearly could not be trusted to do it by hand, and the release went out one number higher than planned. ## The part where I did not get to delete anything I still have all eight adapters. Every client in that list has users today and several have not implemented the standard yet. Adopting on day one meant adding a ninth surface, not removing eight. The consolidation is real but it arrives later, when clients catch up, and I would be suspicious of anyone claiming a one-day-old standard let them delete their compatibility layer this week. ``` before this week: 8 formats 120 files now: 8 formats + 1 standard 124 files later, maybe: just the standard ~15 files ^ this is the bet, not the result ``` So this is a bet, and it is worth naming it as one. Specifications get abandoned all the time. What made it worth taking was the combination: a spec small enough to implement in an afternoon, a charter that constrains its own sponsors, and a scope that stops at packaging instead of reaching for the whole problem. If it fails, I have lost a manifest file and about forty lines in a build script. When packaging stops being a differentiator, the differentiator becomes content, and the small specific plugin that nobody builds today because packaging it for six clients costs more than writing it becomes worth building. That is the version of this I am hoping for. A published spec is not a working one; it starts working when enough libraries package for it that clients have a reason to read it. So I packaged for it. We will see who else does. ## Frequently asked questions ### What is the Agent Plugins standard? Agent Plugins is an open, vendor-neutral standard for packaging AI agent components into portable plugins. Version 1.0.0 was published on 6 August 2026. A plugin is a directory containing a plugin.json manifest, an optional skills/ directory holding Agent Skills, and an optional mcp.json describing MCP servers. Any conformant client can load it, so authors package once instead of once per agent. ### Who created the Agent Plugins standard? Vercel initiated the proposal, and AWS, Anysphere, GitHub, Microsoft and OpenAI collaborated on the specification. It is governed by a Technical Steering Committee whose Core Maintainers are Clare Liguori of Amazon, Roshan Sadanani of Cursor, Harald Kirschner of Microsoft, Gav Verma of OpenAI, and Jonathan Hefner of Vercel, who is Lead Core Maintainer. ### Is Agent Plugins the same as MCP? No. MCP standardizes how an agent calls a tool at runtime. Agent Plugins standardizes how skills and MCP servers are packaged and distributed. They compose: a plugin's mcp.json declares the MCP servers it ships, so the two work together rather than competing. ### How does Agent Plugins relate to Agent Skills? Agent Plugins requires that skills conform to the Agent Skills specification at agentskills.io, the SKILL.md format originally developed by Anthropic and released as an open standard. Agent Plugins does not redefine what a skill is. It defines where skills live inside a plugin and how the plugin travels between clients. ### What is required in a plugin.json file? Only two fields are required: $schema, which pins the specification version, and name. Optional fields include version, description, author, homepage, repository, license, keywords, and an extensions object keyed by reverse-domain namespaces for client-specific configuration. ### Which agent clients support the Agent Plugins standard? The launch named ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code as clients in the ecosystem behind the standard. Conformance is self-declared rather than certified, since the specification deliberately ships no registry and no conformance badge. ### Should I adopt Agent Plugins now? Adopting it early costs very little: a manifest file and a small amount of build scripting, since the spec has only two required fields. It does not let you delete existing per-client adapters yet, because many clients have not implemented it. Treat it as adding one portable surface now and consolidating later, once client support catches up. The testing skills for agents are at [katalon-labs/true-skills](https://github.com/katalon-labs/true-skills) and the second brain is at [huytieu/COG-second-brain](https://github.com/huytieu/COG-second-brain), both conformant as of this week.