TECHNICAL DEEP DIVE

Agent Plugins 1.0 for Product Managers: The Open Standard That Changes AI Distribution

By Institute of AI PM·14 min read·Aug 10, 2026

TL;DR

On August 6, 2026, OpenAI, AWS, Cursor, GitHub, Microsoft, and Vercel launched Agent Plugins 1.0: an open standard that packages AI skills and MCP server configurations into a single portable folder. A plugin built once runs across ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code with no custom integration work. For AI PMs, this changes the distribution equation for AI capabilities: your skills can now reach every agent client your users already work in, without negotiating separate integrations.

The AI PM Minute

One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.

No fluff. Unsubscribe anytime.

What Agent Plugins 1.0 Actually Is

Agent Plugins 1.0 is a vendor-neutral packaging format for AI agent capabilities. Think of it as the npm package for agent skills: a directory structure that any compliant agent client knows how to read, install, and run. Before this standard, if you built an AI skill for Cursor, you had to rebuild it separately for GitHub Copilot, VS Code, and ChatGPT. Each platform had its own extension model, its own configuration format, and its own distribution channel.

The technical steering committee that governs the standard includes Clare Liguori of AWS, Roshan Sadanani of Cursor, Harald Kirschner of Microsoft, Gav Verma of OpenAI, and Jonathan Hefner of Vercel (lead core maintainer). Google has since joined as a core maintainer. This is not a single-vendor play: it is an industry consortium backing a shared distribution format.

The plugin format in plain terms:

plugin.json

The manifest: plugin name, version, author, description, and which skills and MCP servers it includes.

skills/

A folder of SKILL.md files, each describing one discrete AI capability in natural language that any LLM can execute.

mcp.json

MCP server configurations the plugin needs for live data connections (APIs, databases, internal tools).

vendor dirs

Optional reverse-domain directories for client-specific extension data (e.g., com.cursor/ or com.github.copilot/).

Why This Standard Emerged Now

MCP (Model Context Protocol) solved the data connection problem: it let AI clients connect to APIs and databases through a standard protocol. But MCP does not package skills themselves. A team building a code review skill for Cursor still had to repackage it separately for VS Code, ChatGPT, and GitHub Copilot. The result was fragmentation: the same capability lived in four incompatible extension formats, maintained by four separate integration teams.

Agent Plugins 1.0 sits one layer above MCP. It does not replace MCP: it bundles MCP configurations along with the skill definitions into a single portable unit. An Agent Plugin can reference an MCP server for live data access, wrap that access in skill instructions that guide agent behavior, and ship the whole package to any client that supports the standard.

Before Agent Plugins

Build skill for Cursor. Rebuild for VS Code. Rebuild again for GitHub Copilot. Rebuild for ChatGPT. Maintain four separate extension codebases. Fragmented distribution, fragmented discovery, fragmented updates.

After Agent Plugins 1.0

Build one plugin.json with skills/ and optional mcp.json. Publish to any plugin registry. Every compliant client reads the same package. One codebase, one update cycle, one listing to maintain.

What MCP handles

Live tool and data connections: calling APIs, querying databases, reading files. MCP = the data layer. Agent Plugins bundles MCP configs alongside skill instructions.

What Agent Plugins adds

Skill packaging, discovery, and distribution. SKILL.md files describe what the agent can do in each client context. The standard defines how clients load, sandbox, and invoke those skills.

The Six Clients at Launch (and What Each Adds)

Six clients supported Agent Plugins 1.0 at launch. Each client reaches a different user population and workflow context, which matters for your distribution strategy.

ChatGPT

Consumer and enterprise end users

The largest installed base. Plugins here reach users who are not developers. Distribution to ChatGPT users gives your skill the broadest possible reach but requires skills to be robust for non-technical users.

Codex

Developers using OpenAI's coding agent

Codex is OpenAI's autonomous coding agent. Plugins here extend what Codex can do during multi-step code generation and debugging sessions.

Cursor

Developers using the AI-native IDE

One of the fastest-growing developer tools. Plugins reach professional developers mid-workflow in their primary editor. High intent, low context-switching.

GitHub Copilot

All GitHub users with Copilot enabled

The largest developer audience by installed base. Copilot plugins reach developers inside their existing GitHub workflow without requiring any tool change.

Kiro

AWS-native developers

Amazon's agent-powered developer tool. Plugins here reach teams building on AWS infrastructure.

VS Code

The global developer community

The dominant code editor. VS Code support means reaching virtually every developer who has not switched to an AI-native editor yet.

Ship AI Products That Win on Distribution

The AI PM Masterclass covers how to turn emerging standards like Agent Plugins into distribution advantages. Taught live by a former Apple and Salesforce Sr. Director PM.

Product Implications: How Distribution Changes

For AI PMs, Agent Plugins 1.0 creates a new distribution primitive. Before this standard, the decision was: build a standalone product, or build a plugin for one specific platform. Now there is a third option: build an Agent Plugin once and distribute it across six clients simultaneously.

Your skill can follow users across tools

A developer might use Cursor for focused coding sessions, GitHub Copilot for quick code completions, and ChatGPT for planning. An Agent Plugin reaches them in all three contexts with the same skill, maintained from one source.

Discovery becomes cross-platform

If a client supports Agent Plugins, it likely has a registry or marketplace. Getting listed in one registry does not automatically list you in others, but the packaging format is identical: publish once to each registry rather than building once per platform.

Skill definition is now a product artifact

SKILL.md files describe what your agent can do in natural language. These files need the same level of product craft as user-facing copy: clear capability descriptions, explicit scope boundaries, and examples that match actual usage. Poorly written SKILL.md files produce unreliable agent behavior.

Version management gets simpler

One plugin.json means one version number, one changelog, and one deprecation cycle. Teams that previously maintained separate Cursor and VS Code extensions can consolidate to a single release process.

Sandboxing requirements vary by client

Each client implements its own security model for plugin execution. Agent Plugins 1.0 defines the packaging format but not the sandboxing spec. Understand each client's permission model before assuming your plugin will behave identically across all six.

What to Watch, What to Question

Agent Plugins 1.0 is version 1.0 of a new standard. That means the happy path works well and the edge cases are still being discovered. Here is what experienced AI PMs should pressure-test before committing a roadmap to this distribution path.

Client adoption is uneven

Six clients at launch is impressive, but the clients your users actually use may not be on the list yet. JetBrains IDEs, Zed, Windsurf, and Claude Code are not on the launch list. If your users live in one of those environments, you still need a platform-specific solution.

Skill quality determines agent quality

A plugin is only as good as its SKILL.md files. If the natural-language skill description is ambiguous, the agent executing it will produce inconsistent results across different client LLMs. Plan for skill QA as a first-class PM responsibility.

Monetization is undefined

Agent Plugins 1.0 defines packaging and distribution, not monetization. There is no standard for paid plugins or usage-based billing across clients. If you plan to charge for plugin access, you will need to implement billing infrastructure outside the standard.

The standard will evolve

Version 1.0 means the spec will change. Schema additions, permission model revisions, and registry requirements will update over time. Build your plugin deployment pipeline to treat plugin.json updates as routine, not exceptional.

The Decision Framework: Should You Build an Agent Plugin?

Not every AI capability should become an Agent Plugin. The format is best suited to skills that are genuinely context-agnostic: capabilities that make sense whether the user is in ChatGPT or Cursor or GitHub Copilot. Use this framework to decide.

Build an Agent Plugin if:

  • +Your capability is useful in multiple tool contexts (code review, data lookup, summarization, generation)
  • +Your target users already use two or more of the six supported clients
  • +You want to reduce integration maintenance overhead across platforms
  • +Your skill definition is stable enough to describe in natural language without client-specific tuning

Do not build an Agent Plugin if:

  • -Your capability requires deep integration with a single platform's UI or data model
  • -Your primary users are on clients not yet supporting the standard (JetBrains, Zed, Claude Code)
  • -You need guaranteed monetization infrastructure before shipping
  • -Your skill relies on real-time bidirectional UI interactions that go beyond tool calls

Turn New AI Standards Into Product Advantages

The AI PM Masterclass teaches you to read emerging standards early, evaluate their product implications before your competitors do, and ship distribution strategies that compound.

Before you go: get the AI PM Minute

One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.

No fluff. Unsubscribe anytime.