Agent Plugins 1.0: GitHub, OpenAI and Google converge on a common format

GitHub now supports Agent Plugins 1.0 in Visual Studio Code, Copilot CLI and the Copilot app. The open format distributes agent instructions, skills and required MCP servers in one package. Its promise is straightforward: build an extension once and use it in several compatible clients instead of maintaining a separate integration for each one.

The standard was published on August 6 with contributors from organizations including AWS, Anysphere, Google, Microsoft, OpenAI and Vercel. That convergence matters to teams accumulating internal agents, because the real cost no longer sits only in prompts. Distribution, permissions and long-term maintenance are becoming equally important.

The short answer

A package instead of scattered files

A plugin has a root manifest. Its skills/ directory describes capabilities the agent can activate, while mcp.json declares connections to external tools or data. A vendor directory such as com.github.copilot/ can extend the common foundation without making the whole package proprietary.

This structure addresses a problem already appearing inside companies. One team writes an incident-analysis procedure, another adds an observability MCP server, and every developer manually assembles both in an editor. A plugin turns that collection into a versioned, reviewable and testable artifact.

Portability does not mean identical behavior everywhere. Models, permission interfaces and client capabilities vary. The standard transports the package; it does not fully standardize the engine executing it.

What GitHub adds around 1.0

Visual Studio Code, Copilot CLI and the Copilot app can discover and install these plugins. A developer can therefore use the same specialized agent from a terminal, editor or remote environment with more consistent configuration.

Administrators get settings including enabledPlugins, extraKnownMarketplaces and strictKnownMarketplaces. They can require plugins, declare internal catalogs or block unapproved sources. MCP allowlists remain complementary: approving a package should not silently authorize every command offered by its servers.

A new software supply-chain component

A plugin may execute a binary, call an internal API or read a repository. It should be treated as a software dependency, not harmless configuration text. Author, provenance, version and permission changes need review before distribution.

Private catalogs will help publish assistants tailored to an architecture, coding standard or on-call procedure. They also create an ownership obligation. A stale plugin may recommend a dangerous command or keep calling a retired API, so update and retirement policies are necessary.

Adopting it without creating more debt

Start with a narrow, measurable use case such as preparing a code review or diagnosing one service. Put stable instructions in a skill, restrict MCP to necessary tools and document accessible data. Test the package in two clients the team actually uses.

Version the plugin, require review for manifest changes and record expected outcomes for a few scenarios. In an enterprise, distribute it through a controlled catalog and pair it with an explicit MCP allowlist. Secrets belong in the client or infrastructure, never in the plugin package.

Finally, measure failures and confirmation requests. A portable agent that needs manual correction on every run does not become useful simply because it follows a standard.

Agent Plugins 1.0 gives development agents a distribution format they were missing. Its success will depend less on plugin volume than on whether organizations govern these packages as real software.