Amazon, OpenAI, and 3 Others Release "Agent Plugins" to Standardize AI Agent Extensions

Core maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel are jointly stewarding "Agent Plugins," an open standard for carrying AI agent extensions across products. The published specification, version 1.0.0, bundles existing Agent Skills and Model Context Protocol (MCP) servers into a single directory, allowing compatible products to discover and validate them using the same rules. The goal is to reduce the burden on authors who have had to rearrange the same components and rewrite configurations for each vendor's product. However, what has been standardized is the plugin's "packaging," not the permissions or execution environment after installation.

The minimal unit that plugin.json aligns

The minimal structure of an Agent Plugin is a directory with a plugin.json file at its root. The manifest requires a $schema field specifying the spec version and a plugin name. The actual functionality can be added optionally, and 1.0.0 defines two types of portable components: Agent Skills and MCP servers.

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
└── mcp.json

Directly under skills/, folders containing SKILL.md files that describe procedures and expertise are placed. Agent Plugins does not redefine the contents of skills; it only specifies where to find files that conform to the Agent Skills specification. Similarly for MCP, the communication method itself is deferred to the MCP specification, and mcp.json allows describing stdio for launching local processes, Streamable HTTP for remote connections, and the legacy HTTP+SSE.

This division of labor well illustrates the change at hand. Agent Skills hand agents work procedures, while MCP servers connect to external tools and data. Agent Plugins puts both into the same box and adds a contract for how compatible clients load them. Authors can reduce the work of moving skill folders and MCP configurations into product-specific layouts.

The specification also standardizes how loading failures are handled. If one skill is invalid, that skill is skipped while sibling skills are still loaded. If one MCP server fails to start or authenticate, other servers and skills are not halted. Rather than treating the entire plugin as an all-or-nothing success or failure, the design isolates the broken portion narrowly.

Five compatible products, but not all can read the same components

The official compatibility list includes Visual Studio Code, Cursor, GitHub Copilot, ChatGPT & Codex, and Amazon's Kiro. All five can load Agent Skills. For MCP, ChatGPT & Codex supports stdio and Streamable HTTP, while the remaining four support these two methods plus the legacy SSE.

These differences remain because the specification allows for phased adoption. A conforming client only needs to implement at least one of Agent Skills or MCP servers, and even for MCP support, handling just one of stdio or Streamable HTTP satisfies the requirement. Therefore, even if a single package can be distributed to all five products, it doesn't mean all the components included will work identically. Authors need to check the compatibility table for their target platforms and test the behavior when unsupported components are included.

An escape hatch for vendor-specific features is also provided. Using a reverse domain name like com.example.client, client-specific configurations and hooks can be added to a plugin. Other clients can ignore unsupported namespaces, allowing vendor-specific extensions without breaking the common parts. However, that directory is not a portable component. Commands, hooks, and agents fall outside the common scope of 1.0.0, and rules and LSP servers also remain within each product's implementation.

Permissions and distribution remain outside the standard

Agent Plugins 1.0.0 does not define distribution sources or marketplaces. Installation, updates, and how they are presented to users are managed by each client. Permission checks, trust policies, and sandboxing are also not standardized. Even with a common plugin.json, an operation permitted in one product is not necessarily permitted in another.

What the specification primarily defines on the security front is the package boundary. Files that a client loads and executes must remain within the plugin's root directory even after resolving symlinks and the like. If an MCP working directory or executable escapes outside, that server entry is disabled. However, this check does not sandbox the launched MCP process, nor does it restrict the paths accessible during execution.

Authentication is also not portable. 1.0.0 has no common fields for OAuth or credential references, and authentication for remote MCP is left to the client side. Since HTTP headers and environment variables in configuration files can be read from the package, the specification requires that secrets not be embedded there. When enterprises evaluate adoption, separate from format conformance, they must investigate distribution source verification, code review, and permission-granting methods for each product individually.

Joint governance launched without Anthropic

The initial Technical Steering Committee (TSC) consists of five people: Clare Liguori from Amazon, Roshan Sadanani from Cursor, and Harald Kirschner from Microsoft. Gav Verma represents OpenAI, and Jonathan Hefner represents Vercel, with Hefner serving as Lead Core Maintainer. Positions are held by individuals rather than companies, and no single vendor can hold a majority of Core Maintainer seats. Proposals and technical decisions are made public, and participation is stated to be broadly open.

Both specifications wrapped by Agent Plugins originated from Anthropic. MCP was published by the company in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025. Agent Skills was also developed by Anthropic and moved to an open standard in December 2025. However, as of August 8, 2026, Anthropic's name does not appear on the initial Agent Plugins TSC roster. Official materials do not explain the reason.

Whether the joint standard actually reduces porting costs can be measured by how consistently the five compatible clients load the same sample package and produce the same results. Furthermore, if differences in permission checks and authentication leave individual work for authors, the effect of standardization stops before distribution. Whether the next version increases the number of portable components, and whether conformance tests and per-client implementation tables for 1.0.0 are updated first, will determine the standard's real-world effectiveness.