On August 6, 2026, Google announced that it had joined the core maintainers of Agent Plugins 1.0.0. The specification is being developed with teams from Amazon, Cursor, Microsoft, OpenAI, and Vercel. Its goal is not to create another agent runtime. It is to define a small, portable package format for Agent Skills and MCP servers.
Google’s framing is simple: when the same skill and MCP server need to work with a second agent client, the recurring problem is usually not the component. It is the wrapper around it. Directory layouts, manifest metadata, and transport configuration differ from client to client, so authors end up maintaining near-duplicate packages that drift over time. Agent Plugins fixes the shared packaging layer.
An Agent Plugin is a directory with fixed locations for plugin.json, skills/, mcp.json, and an optional reverse-domain extension namespace owned by an individual client. Agent Skills keep the format they already use under skills/. MCP servers are declared in mcp.json with an explicit transport, including stdio, Streamable HTTP, and legacy HTTP+SSE. A client no longer has to infer transport from an arbitrary configuration shape.
The narrow scope is deliberate. Agent Plugins v1 defines no installation mechanism, distribution protocol, permission model, sandboxing requirement, trust or provenance verification, or user experience. A plugin can therefore be easier to move between clients without becoming automatically safe, trusted, or executable. Installation policy, approval flows, enterprise controls, and runtime isolation remain the responsibility of each IDE, CLI, or managed platform.
Google says two of its products already support the format. Agents CLI packages skills for agent building, evaluation, deployment, observability, and publishing. Data Agent Kit packages skills and MCP servers that connect compatible clients to services such as BigQuery, Spanner, and Cloud SQL.
The immediate value is an interoperability floor, not a promise that every agent client will behave the same way. Plugin authors get a predictable package layout, while client authors retain room for hooks, commands, and governance inside their own extension namespace. The next hard questions are therefore operational: who can install a plugin, who can authorize it, how its provenance is checked, and how a failed component is isolated.
