On August 6 a group of companies published Agent Plugins 1.0, a vendor-neutral format for packaging what an agent can do. Vercel initiated the proposal and the core maintainers come from Amazon, Cursor, Microsoft, OpenAI, and Vercel, with a charter that forbids any single vendor from holding a majority of seats. At launch the same plugin installs into ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code. A plugin is a folder with a plugin.json manifest at its root, an optional skills/ directory holding reusable instructions, and an optional mcp.json describing connections to tools and data.
Two things about this are worth slowing down for. The first is that it is not a new capability model. Agent Skills already existed as reusable instruction sets, and MCP servers already existed as the way an agent reaches live tools. Agent Plugins does not redefine either. It is the wrapper that lets a skill and its tooling travel together across clients instead of being reassembled by hand in each one. The second is that the standard is deliberately narrow. It says how a plugin is packaged and found, and almost nothing else. Marketplaces, installation, permissions, sandboxing, and trust all stay with each client. That narrowness is the design decision, and it is the reason the format is worth writing about rather than the six logos on the announcement.
What the format actually settles
For a while, a capability we built for one agent client was close to worthless anywhere else. The instructions were portable in the sense that text is portable, but the wiring around them was not. Each client had its own place to drop a skill file, its own way of registering an MCP server, its own naming and discovery rules. Moving a working setup from one runtime to another meant re-reading each host’s conventions and translating by hand. The cost was not the ideas. It was the reassembly.
Agent Plugins settles the reassembly. A folder with a manifest is now a unit that a compliant client knows how to find and read. This is the same move that package formats made for libraries: the interesting engineering was never the tarball, it was agreeing on where the manifest lives and what it is allowed to say, so that a thousand tools could stop each inventing their own answer. A standard that only defines the envelope is easy to underestimate, because the envelope looks trivial next to the contents. But the envelope is exactly the part that has to be shared for anything else to compose.
The restraint is the strongest signal here. A specification that tried to also standardize permissions and sandboxing and a marketplace would have been a platform, and platforms attract exactly the vendor gravity the charter is trying to avoid. By defining packaging and discovery and stopping, the format leaves room for clients to differ on the things they should differ on, and it keeps the shared surface small enough that agreement is plausible. We have watched broader proposals stall under their own scope. This one drew a line most of the way toward “just the envelope,” and that is probably why it shipped as a 1.0 with real clients behind it.
The two grants folded into one
Here is the part we keep returning to. A plugin can carry a skills/ folder and an mcp.json in the same directory. The skills are instructions: they change how the agent reasons and what it tries. The MCP config is access: it connects the agent to live tools and data. Those are different kinds of thing. One shapes behavior, the other opens a door. Installing a plugin can do both in a single action.
That folding is convenient and it is also the whole risk surface. When a capability was assembled by hand, the two decisions were separate whether you wanted them to be or not. You wrote the instructions, and then, as a distinct step, you pointed the agent at a tool and decided what that tool could reach. A packaged plugin can collapse those two steps into one accept. And the standard, by its own description, leaves permissions, sandboxing, and trust to the client. So the layer that got standardized is the packaging, and the layer that did not is the one that decides what the bundled tool is allowed to touch. Those are not the same layer, and a good outcome depends on clients taking the second one as seriously as the first.
We do not read this as a flaw in the format. Keeping trust with the client is the right call, because trust is contextual in a way a package cannot know. A plugin author cannot decide, from inside a folder, whether a given tool should be allowed to write to a production system on our behalf. Only the host running the agent has that context. But it means the meaningful decision moves to install time, and it means “install a plugin” should never feel like the low-stakes action that “install a package” has been trained to feel like. A plugin is a capability and a connection at once. The connection is the part to read closely.
What it changes for how we work
We run a small stack where the same underlying agent picks up work across very different tasks, and where a capability is worth building only if it does not have to be rebuilt per context. A portable packaging format is directly useful to that. The unit of reuse becomes a thing we can version, name, and move, rather than a habit we re-establish in each client. That is a real reduction in the tax we pay for breadth.
The habit we want to keep, though, is treating the skill and the mcp.json as separate reviews even when they arrive in one folder. The instructions can be read for what they will make the agent try. The MCP config has to be read for what it will let the agent reach, and against the specific systems this host actually exposes. A plugin that is safe on one stack is not automatically safe on ours, because the doors it opens lead to different rooms. The format makes the bundle portable. It does not make the trust portable, and it is careful to say so.
The version to watch for is the one after this. A packaging standard tends to grow a provenance story next, because once artifacts travel, the question of where a given one came from and whether it was changed in transit stops being optional. For now the useful posture is simple. Take the portability. Keep the two grants separate in our heads even when the folder joins them. And read the connection every time, because that is the line the standard leaves to us on purpose.