Five Companies Standardized Agent Plugins Without Anthropic
On August 6, 2026, six companies shipped a unified plugin format for AI agents. The specification bundles two technologies — Agent Skills and MCP servers — into one portable directory. Neither technology was invented by any of the six. Both were invented by Anthropic. Anthropic is not on the Technical Steering Committee.
I verified that myself. I downloaded the full specification text at agent-plugins.org/specification and the governance charter at GOVERNANCE.md in the project's GitHub repository. I ran a case-insensitive search for "Anthropic" and "Claude" against both documents. The governance charter returned zero matches. The specification text returned zero matches. The word "Anthropic" does not appear in the normative contract that packages their two inventions.
Anthropic created the Model Context Protocol (MCP) and Agent Skills as open standards. MCP connects AI agents to external tools and data sources through a standardized wire protocol. Agent Skills bundle reusable instructions, scripts, and reference documentation into a folder with a SKILL.md file. Both are portable on their own. What was not portable was the package format that wrapped them — every client invented its own.
The Problem: Same Components, Different Wrappers
Every major AI agent client had developed its own plugin format. A workflow packaged for GitHub Copilot needed rework before Cursor could use it. A tool integration wired up for Codex would not load in VS Code. Plugin authors maintained parallel versions of components that were never functionally different — only the wrapper differed.
The core problem was not the components themselves. Agent Skills already gave agents reusable instructions. MCP already connected agents to tools and services. Both were portable independently. What broke portability was the manifest — the metadata file, the directory layout, the discovery rules. Every client invented its own box for the same contents.
Vercel, Amazon, Microsoft, OpenAI, and Anysphere (Cursor's parent company) decided that the interoperability floor was worth standardizing. The result is Agent Plugins 1.0.0 (specification).
What Agent Plugins Actually Defines
The structure is intentionally minimal:
my-plugin/
├── plugin.json
├── skills/
│ └── summarize/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json
└── com.example.client/
└── hooks/
The manifest (plugin.json) is two lines of substance: a $schema field identifying the spec version, and a name field. The schema is closed — only nine top-level fields are permitted, and anything else is reported and ignored. Clients must not assign semantics to unknown fields.
The skills/ directory contains Agent Skills in the format defined by the Agent Skills specification. Each immediate child directory with a SKILL.md file is one skill. Clients do not recursively search for additional skills — if it is not at the top level of skills/, it does not exist.
The mcp.json file declares MCP servers using three transport types: stdio, Streamable HTTP, and legacy HTTP+SSE. Each server entry requires an explicit type field. A client never guesses the transport from the shape of the configuration object.
The reverse-domain directory (com.example.client/) is the escape hatch. It lets individual clients add behavior — hooks, commands, agent-specific configuration — without changing the portable core. Clients that do not recognize a namespace ignore it.
What the Specification Deliberately Leaves Out
Agent Plugins v1 is a package format. Nothing more. The specification explicitly does not define installation mechanisms, distribution protocols, permission models, sandboxing requirements, trust or provenance verification, or user experience. These are named openly in the project's future considerations document, not quietly omitted. The Google DeepMind team, which joined as Core Maintainer on launch day, explained the reasoning: installation, policy, enterprise controls, and approval UX differ fundamentally across clients like an IDE, a CLI, and a managed enterprise platform (developers.googleblog.com).
This is the correct distinction. Agent Plugins standardizes discovery and loading — how a client finds plugin.json, reads skills/, and parses mcp.json. It does not standardize trust. A plugin that fails to start does not take the plugin's skills down with it. The client skips the failing MCP server entry, keeps loading, and reports the failure. Independent components fail independently.
The Launch Clients
Six products support the format as of the August 6 launch:
- ChatGPT and Codex (OpenAI)
- GitHub Copilot (Microsoft)
- VS Code (Microsoft)
- Cursor (Anysphere)
- Kiro (Amazon Web Services)
Google also announced same-day support in two products: Agents CLI and Data Agent Kit. The Agents CLI packages Google's expert skills for agent building, evaluation, deployment, and observability. Data Agent Kit provides plugins connecting to BigQuery, Spanner, and Cloud SQL.
Anthropic's Absence
Anthropic created both technologies that Agent Plugins packages. MCP was announced in late 2024 as an open protocol for connecting AI models to external data sources and tools. Agent Skills followed as a format for bundling reusable instructions and resources into a folder with a SKILL.md file. Both were released as open standards under permissive licenses.
The specification's only reference to these technologies is structural: skills/ contains Agent Skills "in the format defined by the Agent Skills specification," and mcp.json declares MCP servers per the "Model Context Protocol specification." The originating organizations are not named in the normative text.
Anthropic recently added its own plugin system to Cowork, its desktop tool for agentic knowledge work. That system is separate from the Agent Plugins standard. Anthropic has not publicly commented on the Agent Plugins launch as of this writing.
The Governance Structure
The Technical Charter establishes a hierarchical structure: Contributors, Maintainers, Core Maintainers, and a Lead Core Maintainer. The TSC consists of all Core Maintainers together with the Lead Core Maintainer. Decisions seek consensus; when votes are required, each TSC member has one vote, quorum requires 50% of TSC members, and decisions require a majority.
The charter includes several structural safeguards: all governance roles are held by individuals, not organizations; no seats are reserved for specific companies; no single vendor may control a majority of Core Maintainer seats; the Lead Core Maintainer can be removed by a 75% super-majority vote; specification text is licensed under Creative Commons Attribution 4.0; and code is licensed under Apache 2.0. Participation is open to anyone who abides by the charter.
Why This Matters for Agent Development
The standardization of plugin packaging changes how AI-assisted software development teams build and distribute agent extensions. Before Agent Plugins, a team building an MCP server plus a skill for database reporting would package it differently for each client. The wrapper differed even when the components were identical. Now, one directory structure works across six launch clients.
In our own AI agent development work, we package MCP servers and Agent Skills separately — each portable on its own, but the distribution format varies by target client. A shared package format eliminates the per-client wrapper without constraining how each client loads, permissions, or exposes the components. The components stay portable. The client-specific behavior stays client-specific.
The distinction between packaging and trust is important. Agent Plugins standardizes how a client discovers and loads components. It does not standardize whether a component should be trusted, how permissions are granted, or what sandboxing applies. Those decisions remain with the client — and they should. An IDE running locally has different trust obligations than a managed enterprise platform running in the cloud.
The Ecosystem Layers
Agent Plugins does not exist in isolation. It is part of a stack where each layer is independently useful and independently adoptable: Find it via Agentic Resource Discovery, an open protocol that lets a client ask "what is available for this task?" and receive matching resources. Describe it via AI Catalog, the entry format ARD indexes. Package it via Agent Plugins. Run it via MCP and Agent Skills. You can publish a plugin without a catalog entry, catalog a resource that is not a plugin, and run skills with no plugin at all. Adopting one layer never obligates the next.
FAQ
What does Agent Plugins 1.0.0 standardize?
Agent Plugins 1.0.0 standardizes the package format for AI agent extensions. It defines a directory with a plugin.json manifest, a skills/ folder for Agent Skills, and an mcp.json file for MCP server configurations. It does not define installation, distribution, permissions, or trust verification (agent-plugins.org).
Who governs the Agent Plugins specification?
The Technical Steering Committee includes Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. Google joined as Core Maintainer on launch day. The governance charter states that roles are held by individuals, no seats are reserved for companies, and no single vendor may control a majority (GOVERNANCE.md).
Is Anthropic involved in Agent Plugins?
Anthropic is not listed as a Core Maintainer or contributor in the specification or governance documents. Anthropic created both technologies that Agent Plugins packages — MCP and Agent Skills — but is not part of the standardization effort. Anthropic has not publicly commented on the launch (the-decoder.com).
Which clients support Agent Plugins at launch?
ChatGPT, Codex, GitHub Copilot, VS Code, Cursor, and Kiro (AWS) support the format as of August 6, 2026. Google's Agents CLI and Data Agent Kit also support it (alphasignal.ai).
Should I package my MCP server as an Agent Plugin?
If you are shipping a single MCP server to a single client, mcp.json on its own is simpler. Agent Plugins earns its keep when you have components that belong together and need to travel together — a skill plus its companion MCP server, distributed as one unit across multiple clients (developers.googleblog.com).
Conclusion
Five companies standardized a package format for two technologies they did not invent. The specification is clean, minimal, and correctly scoped — it standardizes packaging, not trust. The governance structure is open, vendor-neutral, and structurally protected from single-vendor capture. The absence of Anthropic from a standard that packages Anthropic's own inventions is the governance story worth watching.
If you are building AI agent systems and want to package skills and MCP servers for cross-client distribution, Agent Plugins is the format to target. The specification is open at agent-plugins.org, and the GitHub repository accepts public proposals.
Sources
- Agent Plugins Official Site — 2026-08-06 — Official specification site; defines plugin.json, skills/, mcp.json format; TSC Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, Vercel
- Agent Plugins Specification Repository — 2026-08-06 — GitHub repo for specification text, governance charter, schemas, and conformance tests
- Google DeepMind Blog: Agent Plugins Package Your Skills, Tools, and More — 2026-08-06 — Google joining as Core Maintainer; explains the "box" problem and what the spec deliberately leaves out
- AWS Blog: AWS Supports Agent Plugins — 2026-08-06 — AWS support announcement for the open standard
- Agent Skills Specification — 2026-08-06 — The Agent Skills specification that Agent Plugins packages
- MCP Specification — 2026-08-06 — The Model Context Protocol specification that Agent Plugins packages
- The Decoder: Amazon, Cursor, Microsoft, OpenAI, and Vercel Unite — 2026-08-07 — Notes Anthropic's absence explicitly; mentions Cowork plugin system
- AlphaSignal: OpenAI, Microsoft, and Cursor Unite Behind Agent Plugins — 2026-08-07 — Full launch clients list; TSC composition
- Agent Plugins Governance Charter — 2026-08-06 — Technical Charter defining TSC structure, voting rules, and licensing
- Agent Plugins Future Considerations — 2026-08-06 — Explicitly lists what v1 does not define: install, distribution, permissions, trust