OpenAI and Major Tech Companies Unify AI Agent Plugin Format

On August 6, 2026, OpenAI, Microsoft, Amazon, Cursor, and Vercel jointly launched Agent Plugins 1.0.0, aiming to establish a universal plugin packaging format for AI Agents. Developers can place Agent Skills—comprising instructions, scripts, and reference materials—alongside MCP servers that connect to databases, cloud services, and development tools within the same directory; theoretically, a single packaging step enables use across compatible clients such as ChatGPT, Codex, VS Code, Cursor, GitHub Copilot, and Kiro. It addresses not model capability issues, but the growing fragmentation in the Agent ecosystem: currently, the same capability often requires separate manifest files, modified directory structures, and multiple branches maintained for different products. However, the 1.0.0 specification is still labeled as a “working draft,” currently standardizing only the packaging method without defining plugin marketplaces, installation protocols, permission models, sandbox isolation, or source verification. Thus, it functions more like a “package format” for the Agent ecosystem rather than a mature app store where users can safely install any plugin.

Author and source: Jonathan Hefner, member of the Vercel engineering team

Over the past year, the AI Agent ecosystem has developed two important extension capabilities.

The first category is Agent Skills. They typically consist of aSKILL.md file, associated scripts, and reference materials that instruct the Agent on how to perform a specific type of task. For example, when deploying a website, analyzing financial documents, or checking code security, skills provide step-by-step procedures, important considerations, validation rules, and executable programs.

The second type is the MCP server. MCP enables Agents to connect with external tools and data, such as reading databases, interacting with GitHub, querying cloud platform statuses, or calling enterprise internal systems. Skills focus on "teaching the Agent how to do something," while MCP focuses on "providing the Agent with actual tools to call."

The problem is that these components previously lacked a unified packaging approach. Even when the core functionality of a skill or MCP server was identical, developers might still need to separately modify manifest files, directory structures, and configuration fields when integrating it into different Agent products. Over time, this led to multiple client-specific versions of the same extension; when one version fixed a bug, other branches didn’t necessarily sync, ultimately resulting in what Google calls “forking and drift.”

What Agent Plugins provide is this generic outer packaging for these capabilities. Their role is more akin to JavaScript’spackage.json or the OCI format in containerization: they do not replace the code and protocols inside, but instead uniformly describe how these components should be organized, discovered, and loaded.

According toversion 1.0.0 specification, an Agent Plugin is a directory with a fixed structure, and the root directory must containplugin.json. The minimal manifest only needs to declare the adopted specification version and the plugin name.

If the plugin includes skills, they are all placed in theskills/ directory, with each skill having its ownSKILL.md, along with accompanying scripts, reference files, and other resources. If the plugin requires connection to external tools, place anmcp.json file in the root directory to declare one or more MCP servers.

The MCP module currently supports three connection methods: stdio with a locally launched process, the currently recommended Streamable HTTP, and HTTP+SSE retained for backward compatibility with older systems. Clients do not need to support all transport methods, but must support at least one of stdio or Streamable HTTP.

The direct benefit of this fixed structure is that clients do not need to guess where files are located, and plugin authors do not need to redesign directories for each product. A compatible client that supports only Skills but not MCP can still read the skills section; when an MCP configuration fails, the specification requires the client to skip the faulty server whenever possible, rather than causing the entire plugin to fail.

Agent Plugins also allow vendors to retain proprietary features. Clients can establish their own extension namespaces using reverse domain names, such ascom.example.client. Other clients should ignore unrecognized proprietary configurations rather than rejecting the entire plugin. This enables standards to provide a common foundation while not forcing all products to have identical features.

The official compatibility list currently includes VS Code, Cursor, GitHub Copilot, ChatGPT, and Codex, as well as Amazon's Kiro. Vercel initiated the original specification proposal, and the initial Technical Steering Committee was established by AWS, Anysphere (parent company of Cursor), Microsoft, OpenAI, and Vercel; GitHub also participated in refining the specification.

On the day of its release, Google announced its participation in core maintenance and began enabling relevant products to support this format. Google plans to adopt Agent Plugins in Agents CLI and Data Agent Kit, allowing developers to combine data capabilities such as BigQuery, Spanner, and Cloud SQL into portable plugins.

This group of participants is noteworthy because they are not aligned on the model or product level: Microsoft owns VS Code and GitHub Copilot and has close ties with OpenAI; Cursor is an independent AI programming tool; AWS owns Kiro and competes with Microsoft and Google in the cloud marketplace; Vercel aims to become a platform for deploying AI applications. Their willingness to collaborate on packaging standards indicates that plugin fragmentation has begun to increase maintenance costs for all vendors.

The specification adopts an open license, and technical discussions and decisions are also planned to take place in public projects. It attempts, at least in its institutional design, to avoid complete control of the format by a single corporate entity. However, whether open governance proves effective ultimately depends on the decision-making processes of future versions and whether products will heavily rely on their own proprietary extensions.

The most misleading aspect of Agent Plugins is the term "plugins," which may evoke associations with browser extensions or mobile app stores. In reality, the current 1.0.0 version only standardizes the packaging format and has not established a complete plugin distribution and security system.

Google's official interpretation clearly states that the first version did not specify which protocol plugins should use for installation, where to search and download them, or establish unified requirements for permission requests, user confirmation, sandboxed execution, publisher identity, and source verification. These tasks are still handled individually by each Agent client.

Although the specification requires that file paths within the plugin cannot escape the plugin root directory via../or symbolic links, the official documentation specifically notes: this path restriction does not equate to sandboxing the plugin process. An MCP server launched via stdio may still execute programs; which files, environment variables, networks, and user data it can access is determined by the client’s permission system.

Remote MCP endpoints must use HTTPS by principle, and plugins must not directly embed passwords or other secrets into public request headers or environment configurations. However, version 1.0.0 does not provide a generic OAuth configuration or portable credential reference mechanism; authentication discovery, user login, and credential storage are still handled by the client.

Therefore, standardizing the format may also increase the efficiency of malicious extension distribution. Developers can “package once, run anywhere,” and attackers could theoretically do the same. What will ultimately determine whether this standard achieves widespread adoption may not be the directory structure, but whether mechanisms such as signing, permission prompts, supply chain reviews, automatic updates, and revocation can keep pace in a timely manner.

Many Agent products also include commands, event hooks, sub-Agent templates, interface components, and custom workflows. The designers did not enforce uniformity for these elements in the first version, but instead selected only Skills and MCP, two components that have already established a certain cross-platform foundation.

This is a conservative but pragmatic choice. If standards attempt to define all Agent capabilities from the outset, they risk becoming overly complex and locking in the current design of a single product as a long-term industry standard. Agent Plugins first address the most clearly defined problem: integrating an Agent’s operational knowledge and tools into a single, portable software package.

Google also specifically notes that not every individual skill or each MCP server needs to be packaged as a plugin. Plugins are better suited for a set of capabilities that require joint installation, version management, and migration. For example, a suite of database development plugins could include SQL query skills, MCP database connectivity, troubleshooting guides, and deployment scripts together; if it’s just a simple standalone document, distributing it directly as a skill may be more appropriate.

If the standard gains sufficient client support, developers won’t need to rebuild all their skills and tool integrations when switching teams from Cursor to VS Code, or from Codex to another agent. The agent capabilities accumulated over time by individuals or enterprises can follow users, making it easier to swap out underlying models and clients.

This will change the way Agent platforms compete. Manufacturers can no longer rely solely on proprietary plugin formats to retain users; instead, they must continuously compete on model quality, execution reliability, permission controls, interface experience, and plugin discovery capabilities. For developers, portable plugins mean a single investment can reach a broader user base, eliminating the need to maintain nearly identical projects for every Agent marketplace.

But true portability still has boundaries: clients may implement only parts of the specification, and authorization mechanisms and execution environments vary across products; although plugins can be recognized, they may not behave identically on every client. Plugins that heavily rely on vendor-specific namespaces may even re-establish de facto lock-in beneath a surface of formal compatibility.

Additionally, MCP was initially championed by Anthropic, but Anthropic does not currently appear on the list of initial core maintainers or first-wave officially compatible clients published for Agent Plugins. This does not mean Claude will not support the format in the future, but it indicates that the new packaging standard has not yet been adopted by all major Agent factions.

The greatest value of Agent Plugins today is not technical complexity, but rather the fact that multiple competing vendors have acknowledged the same issue: while models can invoke an increasing number of tools, if each platform has its own plugin packaging method, the Agent ecosystem will replay the fragmented history of early mobile apps and browser extensions.

The first version of the specification is very minimal and doesn't even address how plugins discover, install, or establish trust. But this restraint may also be its strength: it first unifies the most fundamental and easiest-to-consensus layer, giving Skills and MCP servers a common transport mechanism, while leaving permissions, distribution, and additional components for future versions.

It should be noted thatthe official specification page, although labeled as version 1.0.0, is still marked as a “Working Draft,” and further details may be subject to change. Currently, support is primarily limited to manufacturers involved in developing the standard, and it has not yet been proven that the broader Agent ecosystem has adopted it.