Agent Plugins 1.0.0 is a vendor-neutral packaging format that bundles an AI agent's custom skills, their dependencies, and configuration files into a single, portable file. It deliberately leaves Model Context Protocol (MCP) servers out of the package, treating them as external resources the agent connects to rather than components it carries along.
The distinction matters more than the spec's authors might admit. The release announcement, covered by outlets like AWS's own news blog in late 2025, frames Agent Plugins as the answer to a frustrating problem: every agent framework ships its own proprietary way of extending it, so a skill you build for one assistant has to be rebuilt for the next one. The proposal wants to do for agent extensions what container images did for applications, define a standard shape that runs anywhere.
What the package actually contains
Open the spec and you find the familiar anatomy of a modern software artifact. An `agent-plugin.json` manifest declares the plugin's metadata and, critically, lists its dependencies. A `skills/` directory holds the actual skill definitions, the instructions and tools that give an agent a new capability. A `dependencies/` directory carries the executable code and shared libraries the skill needs to run. The whole thing is meant to be signed and versioned, which is where the real engineering thinking shows.
The parallel to container images is deliberate, and it inherits container flaws too. An image that declares a dependency on a base layer is only portable if that base layer exists wherever the image runs. Agent Plugins has the same structural dependency, and resolving it in practice requires a registry, a trust model for signatures, and a runtime that honors the format. None of those are in the spec itself.
How skills and MCP servers fit together
This is the part vendors keep tripping over. A skill in the Agent Plugins format is a capability the agent can invoke: "check my calendar" or "summarize this document." An MCP server is a connector to an external tool or data source, a live bridge to something like a database or a SaaS product. The plugin bundles the skill, but it references MCP servers by name and configuration rather than shipping them.
Think of it as the difference between a map and a road. The plugin gives the agent a map of what it can do, drawn in a common cartography. The MCP servers are the roads, and they are owned and maintained by whoever operates them. The agent that runs your plugin needs to reach those roads, and "reach" means network access, credentials, and a server that is actually running.
That separation is defensible. Packaging a live server with its credentials and its network dependencies would be a security and logistics nightmare, and the format's authors know it. But the separation is also where the portability promise starts to bend.
The portability claims under stress
The phrase "portable agent extensions" deserves scrutiny, because portability is a spectrum, not a switch. A plugin is portable in the sense that a chess opening is portable: both players know the moves, but the game only happens if the board is set up and the opponent shows up.
Three things stand between the spec and the marketing. First, the MCP servers a plugin depends on are external, so moving a plugin between agents means moving its infrastructure too. Second, the manifest's dependency resolution assumes a compatible runtime, and while Agno and AWS Bedrock AgentCore have signaled support, a standard with two initial implementations is still a proposal. Third, signed artifacts need a trust anchor, and the spec leans on existing PKI rather than defining one, which is reasonable but puts the burden on whoever deploys the plugin.
There's a documented precedent for this exact failure mode, and it cost a team dearly. In 1999, NASA lost the Mars Climate Orbiter because one team specified thruster impulses in metric newton-seconds while the navigation team expected imperial pound-seconds. The spacecraft entered the Martian atmosphere at the wrong altitude and broke apart, roughly $125 million gone. The postmortem, published by the NASA JPL investigation board, found the root cause was a software interface contract that everyone assumed was clear and no one verified end to end.
The mechanism is identical to the plugin portability problem. The format was the interface contract, and the unit mismatch was the dependency that nobody in the chain owned. When a plugin says it needs an MCP server called "invoices_db," and the target runtime has one called "invoices-db" with slightly different credentials, that is the same class of error as the metric mix-up. Every participant assumed the interface was the other participant's job to get right.
The lesson is not that Agent Plugins is doomed, any more than the Mars Climate Orbiter proved navigation software was a dead end. The lesson is that portability is an operational property, not a packaging property. A standard file format can give you a common language, but it cannot give you compatible runtimes, reachable servers, or a trust chain. Those are deployed, operated, and verified by people.
Reading the spec before you build on it
Treat the 1.0.0 release as a strong draft, and check the three claims against your own stack. Declare the MCP servers your agent depends on in the same manifest that declares the plugin. Test the plugin on every target runtime before you promise portability to a customer. And verify signatures at deploy time, because a standard that leans on PKI is only as trustworthy as the pipeline that checks it.
The format is worth adopting, but adoption and portability are different words. The spacecraft's other lesson, from the same 1999 report, is that the interface that killed it had been reviewed and approved. The reviewers just never checked whether the two sides were speaking the same units. When you move an Agent Plugin from one environment to the next, ask the same question the JPL board asked with far less margin: who is checking the units, and how will they know.
Comments
No comments yet.