Agent Plugins 1.0: build your agent skills once, ship to Cursor and Copilot

Until August 2026, shipping the same agent capability to Cursor, Copilot, and ChatGPT meant maintaining parallel manifests, folder layouts, and config drift. Agent Plugins 1.0 is the industry bet that portability should live at the packaging layer, not in your git history.

I wire MCP servers and skills for client ops stacks. Fragmentation is not an abstract annoyance. It is billable hours duplicated every time a team adds a second IDE.

The problem Agent Plugins solves

Agent extensions today are mostly two things:

1. Skills (markdown instructions the agent loads on demand)
2. MCP servers (tool connectors the agent calls at runtime)

Each client invented its own zip format. You would write one skill, then fork it for Copilot's layout, Cursor's layout, and whatever ChatGPT expects next week.

Agent Plugins 1.0.0, published August 6, 2026, defines a single directory that compatible clients can discover. The steering committee includes Amazon, Cursor, Microsoft, OpenAI, and Vercel, with Google joining as a core maintainer the same week.

That lineup matters. This is not one vendor's plugin store pretending to be a standard.

The minimal plugin layout

The spec stays intentionally small. From the Vercel changelog and GitHub's Copilot announcement:

my-plugin/
├── plugin.json          # name, version, identity
├── skills/
│   └── greet/
│       └── SKILL.md     # one skill per child folder
└── mcp.json             # optional MCP server config

That is a valid plugin. Google's developer blog notes you can stand one up in about a minute with a hello-world SKILL.md.

Components fail independently. A broken MCP entry should not brick the whole skills package.

What the spec deliberately does not solve

Google's launch post is refreshingly honest: v1 is packaging only. It does not define install mechanics, distribution, permissions, sandboxing, provenance, or UX. Clients keep those choices.

For practitioners that means:

• Marketplaces differ. Copilot points at Awesome Copilot; Cursor has its own install path. Same folder, different storefronts.
• Security is still your problem. Portable format does not mean trusted format. Review MCP servers like you would any production dependency.
• Client-specific power stays namespaced. Copilot can load custom agents, commands, rules, and hooks from extension directories beyond the portable core.

The spec's narrow scope is why it might actually ship. Version 1.0 does one job well.

Why this lands in my stack

I already treat skills as versioned artifacts and MCP as the integration layer for CRMs, calendars, and internal APIs. Agent Plugins gives me a single artifact to hand a client whether their team standardizes on Cursor or GitHub Copilot.

AWS's open source blog frames the same pain: rebuild the server for Kiro, rewrite packaging for VS Code, repeat for every harness. Their AWS Agent Toolkit is already moving skills and MCP bundles into the shared format.

For Applied AI shipping, the workflow I recommend:

1. One repo per integration (CRM connector, ticketing, internal KB)
2. MCP server for tools + auth boundaries
3. Skills folder for how the agent should use those tools in your business context
4. plugin.json so every compatible client loads the same package

Governance and what comes next

The format sits under open governance with a technical steering committee. The Register noted the Linux Foundation's Agentic AI Foundation (AAIF) embraced the effort while the spec remains an independent entity. License: CC-BY-4.0 for the specification text.

Future versions may add hooks, sub-agents, and other extension types. The 1.0 scope is skills + MCP only. That is enough to kill the worst duplication today.

Practical next steps

If you maintain agent tooling today:

1. Read the spec at agent-plugins.org
2. Convert one internal skill + MCP pair into the directory layout
3. Test install on every client your team actually uses
4. Keep client-specific rules in namespaced folders rather than forking the portable core

Agent Plugins will not replace good integration design. It removes a boring tax so you can spend cycles on auth, evals, and ops wiring instead.

Building portable agent extensions for a multi-IDE team? Book a free discovery call and we can map your first plugin.