Enterprise AI

Why we're building on the Agent Plugins standard

Dániel Kovács

August 7, 2026 · 7 min read

OpenAI, AWS, Microsoft, GitHub, Cursor, and Vercel don’t agree on much. This week they agreed on Agent Plugins 1.0, a shared package format for the components that extend AI agents: skills and MCP servers.

We’re adopting it as the portable core of plugin distribution on Speakeasy, and we’ve already shipped the first phase. This post is about why. Not why the standard exists, which the announcement covers, but why a company whose product includes plugin distribution would rebuild that distribution around a spec that’s a week old.

The per-client packaging tax

Every agent client invented its own extension format. Claude Code has plugins, Cursor has its marketplace format, Codex has its own config layout, VS Code and Copilot have theirs, OpenCode has another. The content inside is nearly identical in every case: instruction files that teach the agent how your team works, and MCP server definitions that give it access to your systems. What differs is the packaging.

We know exactly what that costs because we pay it. Speakeasy generates plugin packages for four client formats today. Every client your org adopts has meant another generator on our side, and every new capability has meant implementing it four times. When one client’s format changes, that client’s packages drift until we catch up.

Teams building their own tooling pay the same tax with fewer resources. The common outcomes:

• Standardize on one client, and lose the developers who are more productive in another.
• Support several clients, and maintain several copies of the same skills and configs that slowly stop agreeing with each other.
• Give up on packaging entirely, and let everyone copy files around until nobody knows which version of the deploy runbook their agent is reading.

Someone has to eat the cost of internal fragmentation.

What does the Agent Plugins spec actually define?

Less than you’d expect. A plugin is simply a directory with a plugin.json manifest, skills under skills/ in the existing Agent Skills format, and MCP server definitions in mcp.json. Client-specific behavior goes in namespaced extensions so it can’t contaminate the portable core.

The spec explicitly does not define:

• Marketplaces or registries
• Installation, updates, or rollback
• Distribution formats or protocols
• Permission models
• Credential references or secret injection
• Hooks, commands, or UI extensions

Each client keeps control of the UX around how plugins get installed, distributed, and sandboxed. The standard only guarantees that the package itself means the same thing everywhere.

It’s tempting to read that scope as a limitation. We read it as the reason to be optimistic that the standard will hold. Container images went through the same evolution: the OCI image format standardized what a container is, and everything above it (registries, scanners, orchestrators, policy engines) stayed competitive. A maximal spec that tried to standardize marketplaces and permission models would have needed six vendors to agree on product decisions, and it would have stalled or forked. A minimal spec that standardizes the artifact can actually ship, and it did, with a governance charter that prevents any single vendor from holding a majority of maintainer seats.

What this means for your team

The benefits for teams distributing agent tooling through Speakeasy are concrete.

Install once, run everywhere

A plugin you curate is one artifact, not a family of client-specific variants. The same package installs into Cursor and Codex today, and into each additional client as it adopts the standard. Your platform team maintains one source of truth; the packaging matrix stops being your problem, and increasingly stops being ours.

New clients work on day one

Under per-client packaging, supporting a new agent client meant waiting for us to build and test another generator. Under the standard, a client that implements Agent Plugins can install your existing packages the day it ships. Client coverage stops being gated on vendor engineering and starts being gated on the spec, which every major client vendor has committed to.

No lock-in, in either direction

The package is an open format, and you can export any compatible plugin as a standards-conforming ZIP and take it anywhere. If Speakeasy disappeared tomorrow, your plugins would still install. We think plugin distribution should be won on the quality of the registry, distribution, and measurement around the artifact, not on a proprietary package format holding your content hostage.

Credentials stay out of packages

The standard treats package contents as visible data, so credentials don’t belong in them, and we enforce that strictly: portable packages contain URLs and transport types, never API keys or auth headers. Authentication happens at the client via OAuth. Packages get committed to repos and cached on laptops; under this model, that’s safe, because a leaked package leaks instructions, not access.

Why not let clients discover tools themselves?

There’s a reasonable objection to packaging anything: clients keep getting better at discovery. An agent can already connect to an MCP server given a URL, public registries of servers and skills are growing, and it’s easy to extrapolate to a world where each agent assembles its own toolkit on demand. For public tooling, that may well be how it plays out, and the standard doesn’t prevent it.

Inside an enterprise, the operative question is which tools a given person should have, with which access, approved by whom. That’s why enterprises maintain an internal registry in the first place, and it’s where a plugin earns its keep. A plugin is a pre-made package tailored to your company and to a role within it. A support engineer installs one artifact and gets the triage skills plus the ticketing MCP server. A platform engineer gets the deploy runbook plus the infrastructure access that goes with it. The evaluation of what’s safe to connect to happened upstream, once, instead of at every desk.

What the standard leaves out is what still needs solving

A package format answers “what is a plugin?” It doesn’t answer the questions an engineering org actually operates on:

• Which plugins exist across the company, and which version is current?
• Which machines and which people have which plugins installed?
• Are the installed plugins the approved ones, and did anyone drift?
• Are the skills inside them actually helping, or quietly wasting context?

Those are registry, distribution, and measurement problems, and they’re deliberately outside the spec. This is where we’ve been building: a system of record for skills with immutable versions and usage analytics, org-policy-driven distribution to developer machines, and governance over the MCP access those plugins carry.

A standard portable artifact makes every one of those layers work better. Version history means more when the versioned thing installs everywhere. Compliance checks are simpler when there’s one package to verify instead of four variants.

Where we’re being deliberate

Adopting a week-old standard warrants some care, so it’s worth being specific about the edges:

• The spec is young. We pin our implementation to an exact published revision of the spec and its JSON schemas rather than tracking the latest draft, so a change upstream can’t silently change what we publish. Validation runs against that pinned local copy at publish time, and generation never fetches anything from upstream.
• Version 1.0 doesn’t cover everything we ship. Hooks, which power our agent observability, are outside the portable component model, so those remain provider-native until the standard grows to cover them.
• Clients lag. Older Cursor and Codex releases predate the standard, so our packages include legacy manifests alongside the portable core. Teams that pin client versions keep working without noticing any of this happened.
• Fidelity beats coverage. If a plugin can’t be represented completely and safely in the 1.0 format (for example, a private MCP server without OAuth, or one that needs user-supplied credential headers), we keep it on the provider-native path and say so in the dashboard, rather than exporting a package that silently drops a server.

The standard will evolve, and we’ll track it. But the direction is set: the industry has agreed on what a plugin is, and everyone distributing agent tooling, including us, gets to stop re-solving packaging and start competing on everything above it.

Working out how to distribute skills and MCP access across a team of mixed agent clients? Book time with our team.