Suppose you set up an AI agent environment for an internal development team. You spin up an MCP server that calls internal APIs, write instructions guiding the agent through coding standards and review criteria, create a setup manual, and distribute it to everyone. Getting this far takes weeks to months.
Then, six months later, talks emerge about switching the standard tool to something else. Perhaps license costs are being reassessed, or evaluation of model accuracy has changed. That is when the person in charge ends up saying: "We built that specifically for Cursor, so moving to Copilot means starting over from scratch."
Because of this single statement, many companies postpone reviewing their tools altogether. Options with unpredictable migration costs never even make it to the evaluation table.
What was being rewritten was not the content, but the setup method
Breaking it down calmly, the vast majority of what had to be rewritten was not the substance of the knowledge or tools provided to the agent. Implementations calling internal APIs and documents detailing standards are shaped in ways that can be reused directly.
Where rewrites occurred was in how to make clients recognize them. Configuration file paths, names, syntax, and required steps all differed from client to client. Rewriting the same content across six different setup methods and maintaining six sets of onboarding guides—that is the true nature of "migration cost."
In other words, what needed standardization was not the substance of the knowledge or tools, but how they are packaged.
What was decided on August 6
On August 6, 2026, OpenAI, Microsoft, Amazon, Cursor (Anysphere), and Vercel jointly released Agent Plugins 1.0.0. It is a vendor-neutral specification for packaging Agent Skills and MCP servers into distributable plugins.
Vercel initiated the proposal, and representatives from AWS, Anysphere, GitHub, Microsoft, OpenAI, and Vercel joined to finalize the specification. Core maintainers on the Technical Steering Committee (TSC) come from AWS, Cursor, Microsoft, OpenAI, and Vercel. Google has also announced its participation in core maintenance, stating that it will advance support in the Agents CLI and Data Agent Kit.
Clients supported at launch are ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code. A plugin created once can be loaded into all six without rewriting client-specific installation procedures.
The specification is published under an open license, with maintainers, contribution processes, and technical decision-making made public. It is explicitly established that the specification's direction is not structured around any specific company's product roadmap.
Not a replacement for MCP
Because this is easily misunderstood, let us be clear: Agent Plugins is not a competing third format against MCP. It is a packaging layer that sits on top of Agent Skills and MCP servers.
While MCP defines "how an agent connects to external tools and data," Agent Plugins defines "how that bundle of MCP servers and skills is distributed and installed." Because they operate at different layers, one does not make the other obsolete.
If you are not yet familiar with how MCP itself works, please first review The Complete Guide to MCP, and for its standing as a standard, see What the Transfer of MCP to the Linux Foundation Means. Taking these two into account makes it easier to see that what was added this time is simply a single upstream layer.
What changes in outsourcing vs. in-house development decisions
From the perspective of those commissioning internal AI infrastructure or building it in-house, what changes primarily comes down to two points:
First, the reversibility of tool selection has increased. Previously, choosing which AI client to adopt as the internal company standard was a decision that could not be reversed for several years once finalized. That was because all surrounding development was tied directly to it. When packaging is standardized, migration costs move closer from "starting over" to "expanding distribution targets." Decisions can be made faster, and the damage is lighter if you make a mistake.
Second, how estimates are interpreted changes. When outsourcing AI agent-related development, it was previously necessary to specify in the requirements which client it targeted. Moving forward, specifying "deliver packaged in Agent Plugins format" allows you to set the range of supported clients as a condition of deliverables. You can prevent situations at the contracting stage where deliverables tailored exclusively to a specific client require re-commissioning upon tool migration.
Architecture for setting up internal MCP servers is compiled in Implementation Guide for Internal MCP Servers. Think of the current change as relating to how what you built there is distributed.
Do not miscount what has not been standardized
On the other hand, assuming that internal rollout has now become easy is premature. What was standardized is the packaging; nothing about permissions or data handling has been unified.
A plugin being able to "load into any client" inversely means that it has also become easier to load into places where it shouldn't be. Paths open up where a plugin containing connection credentials for internal APIs can enter a client used under a personal account. As distribution becomes simpler, whether distribution targets are governed becomes increasingly critical.
Before adoption, you should nail down at least the following three points:
- Determine who is permitted to bring plugins into the company. Now that distribution is straightforward, introducing rogue plugins must be treated as an operating premise.
- Design the architecture so credentials are not bundled into plugins. Designing agents without holding keys directly remains a firm requirement regardless of standard changes.
- Explicitly define which clients are authorized. "Having six supported clients" and "authorizing all six internally" are two separate decisions.
The organizational framework for managing agent permission grants is covered in Enterprise Management and Authorization for MCP. Now that packaging is standardized, it better reflects reality to consider the substantive debate as having shifted here.
What to do next
If you have already invested in custom setups for AI agents internally, first list out on a single sheet which clients those assets are tied to. Once you see which clients your MCP servers, policy documents, and onboarding manuals are dedicated to, you can determine what overhead is eliminated by repackaging them into the Agent Plugins format.
If you plan to outsource development going forward, simply adding the delivery format to your requirements will be effective. With the specification published, this is a condition that imposes minimal additional burden on the contractor.
If you would like to consult on designing internal AI infrastructure or taking inventory of existing custom implementations, we assist through GleamHub's Development, AI, and Automation Consultations. Because realistic approaches vary depending on your existing environment and client tools in use, please reach out for an individual consultation. Feel free to contact us via Contact Us.
Sources
- Introducing Agent Plugins — Vercel
- AWS Supports Agent Plugins: An Open Standard for Portable Agent Extensions — AWS Open Source Blog
- Vercel, OpenAI, GitHub, Microsoft, AWS, Anysphere, and others announce "Agent Plugins," a common plugin standard for AI agents — gihyo.jp
- OpenAI, Microsoft, and Cursor Unite Behind Agent Plugins to End Fragmented AI Workflows — AlphaSignal
- OpenAI and four rivals just agreed on one standard for AI agents — The Next Web
