Agent Plugins Made AI Agent Skills Portable — What Agencies Should Do Now
The same skill, six different wrappers
If you build custom AI automations for clients, you already know the pain: an MCP server or agent skill is portable, but the wrapper around it is not. The same tool had to be repackaged, re-configured, and re-maintained for every client platform — Codex here, Cursor there, VS Code somewhere else. Same component, six directory layouts, six metadata formats, six forks that drift apart over time.
On August 6, 2026, that problem got a standard. Agent Plugins 1.0.0 — an open, vendor-neutral specification for packaging agent skills and MCP servers into portable plugins — was published and announced by OpenAI's developer account alongside AWS, Cursor, GitHub, and Vercel. Here is what actually shipped, who backs it, and what an agency should do about it this week.
What happened: an open spec, six clients at launch
Agent Plugins 1.0.0 defines one packaging format that works across agentic clients. OpenAI's announcement on X was echoed by Google's Developers Blog, which described the spec as packaging "your skills, tools, and more." The home base for the standard is agent-plugins.org, with the full 1.0.0 specification and a compatible-clients list published openly.
Who backs v1.0.0: the Technical Steering Committee of Core Maintainers comprises Amazon, Cursor, Microsoft, OpenAI, and Vercel. Google is joining as a Core Maintainer and has already shipped two products using the format (its Agents CLI and Data Agent Kit for BigQuery, Spanner, and Cloud SQL). The spec is versioned 1.0.0 but explicitly labeled a Working Draft — a public consensus document, not a frozen standard.
Six clients support the format at launch, per OpenAI's compatible-clients post and the official list:
| Client | Vendor | Launch support |
|---|---|---|
| Codex | OpenAI | Skills + MCP |
| ChatGPT | OpenAI | Skills + MCP |
| Cursor | Anysphere | Skills + MCP |
| GitHub Copilot | Microsoft | Skills + MCP |
| Kiro | AWS | Native support |
| VS Code | Microsoft | Skills + MCP |
AWS's Agent Toolkit is compatible with 30+ curated skills across Lambda, S3, DynamoDB, and CDK. Notably, no Anthropic/Claude client was announced at launch — don't assume Claude Code support until it is officially declared.
What a plugin actually is
A plugin is a directory, not an installer or a bundle format. It has three fixed parts plus optional client extensions:
my-plugin/
├── plugin.json # closed-schema manifest
├── skills/ # Agent Skills
├── mcp.json # optional MCP server config
└── com.example.client/ # reverse-domain client extensions
The plugin.json manifest is deliberately closed — only $schema, name, version, description, author, homepage, repository, license, keywords, and extensions. It cannot relocate or inline components: skills live in skills/, MCP servers in mcp.json, and each transport is declared explicitly (stdio, Streamable HTTP, or legacy HTTP+SSE).
Two design choices matter for agencies. First, independent component failure: a bad MCP server entry doesn't take skills down — clients skip what they don't support and load the rest. Second, deliberately small scope: v1 standardizes exactly two component types (Skills + MCP). Commands, hooks, agents, rules, and LSP servers are explicitly out until their formats converge. Client-specific behavior is contained in reverse-domain extension namespaces that other clients simply ignore.
The spec also slots into a broader ecosystem layering: Agentic Resource Discovery (find) → AI Catalog (describe) → Agent Plugins (package) → MCP + Agent Skills (run). Each layer is independently adoptable.
What v1 deliberately leaves out
The most important part of the spec might be what it does not do yet. Installation, distribution, permissions, sandboxing, and trust/provenance verification are all flagged as Future Considerations. That means the v1 plugin format has no permission model and no provenance standard.
For an agency, that gap is both a risk and a differentiator. If you sell plugins, self-impose signing, code review, and least-privilege practices — and document that you did. If you buy plugins (or install third-party ones into client environments), vet them the same way you would vet any dependency. Trust layers are now a service agencies can legitimately sell.
Why it matters for packaging and reselling
The strategic shift is simple: build once, run anywhere. Custom skills and MCP servers packaged as a plugin work across six clients at launch. The deliverable is one directory instead of N client-specific builds, and per-client reimplementation cost collapses.
- Plugins become a real product line. Agencies can ship branded plugin bundles — "SEO workflow plugin," "client reporting plugin," "lead-qualification plugin" — that clients install in Codex, Cursor, Copilot, or VS Code. AWS explicitly frames the standard as enabling the same extensions across harnesses.
- Cost modeling changes. Delivery estimates that assume a fixed per-platform adaptation cost now overstate work for plugin-based deliverables. One package, one maintenance stream — not N forks that drift.
- Client portability cuts both ways. A client can switch agent platforms without rebuilding their tools. That lowers switching costs — great for client trust, but it weakens "sticky" platform-based retainers.
- Lock-in moves up the stack. The spec is community-governed (no reserved seats, no single-vendor majority), but distribution, installation, permissions, and UX remain client-owned. The lock-in risk shifts from the package format to the marketplace and install layer.
Actionable next steps for your agency
- Inventory your tools. List every custom skill and MCP server you currently build and maintain per client. Those are your first plugin candidates — and your first pricing conversations.
- Design plugins to spec. Package one existing automation as a spec-compliant plugin and test it in two launch clients. The agent-plugins.org guides cover the directory anatomy and schema.
- Update your pricing calculators. If you estimate delivery cost per platform, apply a portability discount for additional compatible clients — roughly a 60–90% reduction in adaptation cost per extra client — and add "plugin packaging & distribution" as a priced line item.
- Add a trust layer to your offer. Plugin vetting, signing, and least-privilege review is a sellable compliance service precisely because v1 leaves it to you.
Price plugin-based work with the AI agency cost calculator
Estimate Your Delivery Cost →Or browse the findaiagency.com directory for agencies already packaging automations for multiple platforms.
Frequently asked questions
What is Agent Plugins 1.0.0?
Agent Plugins 1.0.0 is an open, vendor-neutral specification published August 6, 2026 for packaging Agent Skills and MCP servers into portable plugins. A plugin is a directory containing a plugin.json manifest, a skills/ folder, an optional mcp.json, and reverse-domain client-extension namespaces.
Which tools support Agent Plugins at launch?
Six agentic clients support the format at launch: OpenAI Codex, ChatGPT, Cursor, GitHub Copilot, Kiro (AWS), and VS Code. AWS's Agent Toolkit is compatible with 30+ curated skills, and Google's Agents CLI and Data Agent Kit already ship with the format.
Who governs the Agent Plugins standard?
The Technical Steering Committee of Core Maintainers comprises Amazon, Cursor, Microsoft, OpenAI, and Vercel. Google is joining as a Core Maintainer. The specification lives at agent-plugins.org with a public GitHub repository (agentplugins/agent-plugins-spec).
What does Agent Plugins mean for agency pricing?
One plugin package works across multiple clients, so per-client reimplementation and N-fork maintenance costs largely disappear. Agencies can price plugin packaging and distribution as its own deliverable, and should apply a portability discount when the same automation runs on several platforms.
What is missing from Agent Plugins v1.0.0?
The spec is labeled a Working Draft and deliberately leaves out installation, distribution, permissions, sandboxing, and trust/provenance verification — all flagged as Future Considerations. Agencies should self-impose signing, review, and least-privilege practices when shipping or buying plugins.
Sources
- OpenAI Developers, "Introducing Agent Plugins" (X, Aug 6, 2026): x.com/OpenAIDevs/status/2085398373511918022
- OpenAI Developers, "Compatible agentic clients at launch" (X, Aug 6, 2026): x.com/OpenAIDevs/status/2085398374841532758
- Google Developers Blog, "Agent Plugins package your skills, tools, and more" (Aug 6, 2026): developers.googleblog.com
- Agent Plugins — home: agent-plugins.org
- Agent Plugins Specification 1.0.0 (Working Draft): agent-plugins.org/specification
- Agent Plugins Compatible Clients: agent-plugins.org/compatible-clients
- Agent Plugins spec repo (agentplugins/agent-plugins-spec): github.com/agentplugins/agent-plugins-spec