MCP (Model Context Protocol) has been emerging as one of the leading standards for connecting AI agents to tools, APIs, and services (learn more here and here).
That's a reputation and permissions problem wearing an interoperability costume. "Trust" here isn't really about whether the plugin's code is good, it's about whether the agent (or the person who owns the agent) can afford to be wrong about it. Which makes me think the winning model borrows more from package managers with sandboxing and signed provenance than from app stores with manual review — review doesn't scale to the volume, but a blast radius does.
Exactly. I like the distinction between interoperability and trust.
The package-manager analogy makes a lot of sense: signed provenance, permissions, and sandboxing could provide scalable trust without relying on manual review.
The real question may be how to define the blast radius when an agent gets a plugin wrong.
The independent-failure design is the detail I'd bet on more than the packaging spec itself. Most "standard" proposals die because they assume a clean adoption path, but real systems fail partially, not wholesale — an MCP server going down without taking your skills with it is the kind of boring reliability decision that actually survives contact with production. My guess on your closing question: we get real interoperability at the plugin layer (too useful to skip) but vendors still fight over the discovery/trust layer, since that's where the actual lock-in value sits.
Great point. I agree that independent failure handling may be just as important as the packaging format, especially in production environments.
And I like your prediction about interoperability: Agent Plugins solves the packaging layer, while discovery, trust, and governance remain open, and could become the areas where vendors differentiate.
The next challenge may be not just making plugins portable, but deciding when and which plugins an agent should trust and use.
That's a reputation and permissions problem wearing an interoperability costume. "Trust" here isn't really about whether the plugin's code is good, it's about whether the agent (or the person who owns the agent) can afford to be wrong about it. Which makes me think the winning model borrows more from package managers with sandboxing and signed provenance than from app stores with manual review — review doesn't scale to the volume, but a blast radius does.
Exactly. I like the distinction between interoperability and trust.
The package-manager analogy makes a lot of sense: signed provenance, permissions, and sandboxing could provide scalable trust without relying on manual review.
The real question may be how to define the blast radius when an agent gets a plugin wrong.
The independent-failure design is the detail I'd bet on more than the packaging spec itself. Most "standard" proposals die because they assume a clean adoption path, but real systems fail partially, not wholesale — an MCP server going down without taking your skills with it is the kind of boring reliability decision that actually survives contact with production. My guess on your closing question: we get real interoperability at the plugin layer (too useful to skip) but vendors still fight over the discovery/trust layer, since that's where the actual lock-in value sits.
Great point. I agree that independent failure handling may be just as important as the packaging format, especially in production environments.
And I like your prediction about interoperability: Agent Plugins solves the packaging layer, while discovery, trust, and governance remain open, and could become the areas where vendors differentiate.
The next challenge may be not just making plugins portable, but deciding when and which plugins an agent should trust and use.