Agent Plugin 1.0 - A Unified Framework for Agent Plugins

Inside this article

Agent Plugins 1.0.0 is an open, vendor-neutral specification for packaging Agent Skills and MCP servers into one portable directory. It was published August 6, 2026.
The spec solves a real and unglamorous problem: identical components kept needing different wrappers for every client, so authors forked and maintained drifting copies.
The Technical Steering Committee includes Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. Google joined as a Core Maintainer the day the spec shipped.
PRESHai builds agent harnesses for a living, and our flagship harness, PRESHos, supports the format. This post explains why the design choices in the spec line up with how we already build.

The Problem Was Never the Components

Here is a scenario anyone shipping agent capabilities has lived through. You write a skill. You write an MCP server to go with it. Together they do one useful thing well, say, query a reporting database and turn the results into the weekly summary a team actually reads.

Then you try to ship it to a second client.

The skill is fine. The MCP server is fine. The wrapper around them is not. The directory layout is different, the manifest wants different top-level metadata, the MCP configuration uses a different shape and infers transports differently. So you fork the package, maintain two copies of components that were never different in the first place, and watch them drift.

The same skill and MCP server packaged three different ways for three different clients, versus one Agent Plugins package that every compatible client loads the same way.

The components were portable all along. Agent Skills give agents reusable instructions and resources. MCP connects agents to tools and services. What was never portable was the box you put them in, and that box was the thing every client had to invent for itself. Agent Plugins standardizes the box.

What an Agent Plugin Actually Is

A plugin is a directory. That is the whole idea, and the restraint is the point.

The file tree of an Agent Plugin: plugin.json, a skills directory containing one subdirectory per skill with SKILL.md, scripts, and references, an mcp.json, and an optional reverse-domain client extension directory such as com.example.client.

The manifest is two lines of substance:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin"
}

Everything else is found at a fixed location. Skills live in skills/, one subdirectory each, in the format the Agent Skills specification already defines. MCP servers are declared in mcp.json, with an explicit type on every entry, so a client never has to guess a transport from the shape of a config object. stdio, Streamable HTTP, and legacy HTTP+SSE are all covered.

Notice what plugin.json cannot do. It cannot relocate components, and it cannot declare them inline. There is no discovery path to configure and no precedence order to learn. If skills/ is not there, the client loads what is there and moves on. An mcp.json server that fails to start does not take the plugin's skills down with it; the client skips that entry, keeps loading, and reports the failure. Independent components fail independently.

That last directory in the tree is the escape hatch. com.example.client/ is an extension namespace owned entirely by one client, for hooks, agents, commands, or anything else that client wants to add. Clients that do not recognize it ignore it. The portable core stays small because the non-portable parts have somewhere legitimate to go.

What It Deliberately Leaves Out

Agent Plugins v1 is a package format and nothing more. It defines no install mechanism, no distribution protocol, no permission model, no sandboxing requirements, no trust or provenance verification, and no user experience. Those are named openly in the project's future considerations, not quietly omitted.

This is the right call. Installation, policy, enterprise controls, and approval UX are genuinely different across an IDE, a CLI, and a managed enterprise platform. Each agentic application has different obligations to its users, and a one-size-fits-all permission model would either be too weak for enterprises or too heavy for a solo developer. Standardizing the package and leaving policy to the client is the correct layer boundary.

It is also worth saying when not to use a plugin. If you are shipping a single MCP server to a single client, mcp.json on its own is still the simpler answer. A single skill does not need a plugin either. The format earns its keep when you have components that belong together and need to travel together.

Packaging Is One Layer in a Bigger Ecosystem

Getting a capability to a user involves more than the box it ships in. The spec is precise about which layer does what.

Four layers of the agentic ecosystem stacked: Agentic Resource Discovery to find it, AI Catalog to describe it, Agent Plugins to package it, and MCP plus Agent Skills to run it. Each layer is independently adoptable.

Agentic Resource Discovery handles finding: an open protocol that lets a client ask what is available for a task and get back matching resources, with plugins as a first-class resource type. AI Catalog handles describing: the entry format ARD indexes, with a proposed change registering application/agent-plugins+json as a known type so a catalog entry can point at a plugin.json the way it points at an agent card. Agent Plugins handles packaging. MCP and Agent Skills handle running.

Each layer is independently useful and independently adoptable. You can publish a plugin with no catalog entry, catalog a resource that is not a plugin, and run skills with no plugin at all. Adopting one never obligates you to the next.

Who Is Behind It

The spec is openly licensed and developed in public, with proposals and technical decisions happening in GitHub Discussions on the specification repository. The initial Technical Steering Committee included Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. Google joined as a Core Maintainer the day the spec shipped, represented by Kevin Hou of Google DeepMind, and is already building support into its own products.

The Agent Plugins Technical Steering Committee: founding Core Maintainers Amazon, Cursor, Microsoft, OpenAI, and Vercel, with Google joining in August 2026. Google Agents CLI and Google Data Agent Kit ship support today.

Two Google products support the format as of today. Google Agents CLI packages expert skills for agent building, evaluation, deployment, observability, and publishing, turning any compatible coding agent, including Claude Code, Cursor, Gemini CLI, and Antigravity, into an agent-building expert. Google Data Agent Kit ships plugins that connect agents to BigQuery, Spanner, Cloud SQL, and the rest of Google Data Cloud, portable across any compatible client or IDE.

When the maintainers of the major agent clients, the two biggest model providers, and the dominant deployment platform all agree on a package format on day one, the format stops being a proposal and starts being the floor. That is what happened here.

Why PRESHai Supports It

We build agent harnesses for a living. A harness is everything wrapped around the model that makes an agent reliable: the loop, the tools, the context management, the guardrails, the verify step, and the capabilities the agent can reach for. Our flagship product, PRESHos, is exactly that kind of harness, an enterprise agent operating system where capabilities, tools, approvals, and tenant boundaries have to compose cleanly for real client work.

The single most expensive pattern in that work has been capability packaging. Before Agent Plugins, every reusable capability we shipped to a client environment meant choosing between a lowest-common-denominator package or a fork per client. We have lived the drift problem the spec's authors describe, and we have the maintenance scars to prove it.

So PRESHai agent harnesses, including PRESHos, support the Agent Plugins format. Concretely:

A portable Agent Plugin flowing into the PRESHos harness: the loader and validator reads plugin.json against the 1.0.0 schema, the skill registry turns skills into routable agent capabilities, the MCP runtime starts declared servers with isolated failures, and the harness layers on tenant scoping, RBAC, approvals, audit, guardrails, and verification.

PRESHos loads Agent Plugins as first-class capability packages. The loader validates plugin.json against the 1.0.0 schema, registers each skill in skills/ as a routable agent capability, and starts the MCP servers declared in mcp.json with the explicit transport the spec requires.
Failures stay isolated, per the spec. A plugin whose MCP server fails to start does not take its skills down. PRESHos skips the entry, keeps loading, and surfaces the failure in the audit trail, which is exactly the behavior the format mandates.
The escape hatch stays open. PRESHos-specific behavior, like our approval gates and tenant-scoped tool routing, lives in a reverse-domain extension namespace, not in a forked manifest. The portable core of every plugin we ship stays portable.
The enterprise layer stays ours, on purpose. The spec deliberately leaves out permissions, provenance, sandboxing, and install UX. Those live in the harness: PRESHos supplies tenant scoping, RBAC, approvals, audit, guardrails, and verification around any plugin it loads. That split is not a gap in the spec. It is the design, and it is why we can adopt the format without weakening the controls our clients depend on.

The portable core travels. The enterprise controls stay where they belong. That is the exact boundary Agent Plugins was designed around, and it is the boundary we already build to.

What to Do With This

If you author skills or MCP servers, the getting-started path is about a minute: create a directory, add a plugin.json with a name, write a hello-world instruction to skills/greet/SKILL.md. That is a valid plugin. The full specification, schemas, and the list of compatible clients are at agent-plugins.org.

If you are evaluating agent platforms, add one question to your list: does the harness load portable capability packages, or does every capability arrive wrapped in that vendor's private format? The first answer means the ecosystem's work compounds in your favor. The second means you are paying for a fork forever.

Packaging is unglamorous infrastructure, and unglamorous infrastructure is exactly the kind of thing that should be shared rather than reinvented five times. Agent Plugins is deliberately small in scope, does one thing well, and is open and interoperable. That is why the industry is backing it, and it is why we are too.