Quick Take

The agent stack is getting a supply chain

agent-pluginsardmcpsupply-chainstandardsagentic-ai

Back in March I was trying to ship the same plugin across Claude Code, Codex CLI, and Gemini CLI, and the annoying part was that the three formats were nearly identical and still incompatible. Same architecture, different key names, no principled reason for the difference. I wrote about it on a007.ai and guessed that a compatibility layer would show up before any formal standard did. I got the order wrong.

The Agent Plugins specification is now out: a portable plugin format built around a plugin.json manifest at the root, a skills/ directory, and an mcp.json for server configuration. The initial technical steering committee includes core maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. If that file layout sounds familiar, it is close to the shape Claude Code plugins have shipped with for a while, and Anthropic is not on the committee. I read that as the normal life cycle of a standard: someone ships a working shape, independent implementations converge on it, and governance arrives later to write it down.

On its own, a packaging spec is a quality-of-life fix. The bigger story appears when you put it beside Agentic Resource Discovery, or ARD, published by Microsoft with Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Nvidia, Salesforce, ServiceNow, and Snowflake. Under ARD, an organization publishes an /.well-known/ai-catalog.json at its own domain describing its capabilities, and registries crawl those catalogs the way search engines crawl the web. An agent can then ask a registry, in plain language, what resource can handle a given task.

Put the two next to each other and you can see the outline of a supply chain. Agent Plugins standardizes how skills and MCP server configurations are packaged. ARD standardizes how capabilities are published and found. MCP or a plain API handles invocation. The remaining decisions, including which registry to query, which result to trust, what to install, and what it may touch, belong to the runtime.

That outline changes what an agent can become. Today an agent is mostly a fixed application. Someone wires up its tools ahead of time, and at runtime it chooses from what it was given. With portable packages and runtime discovery, an agent can become a runtime that assembles its capability set per task. It starts looking less like an appliance and more like an operating system with a package manager attached.

I think that is a genuinely good direction. The portability tax I hit in March was pure waste, the kind of friction that exists because teams built in isolation, and a shared package format deletes it. Package managers also come with a lesson the software industry has already paid for: the format is the least contested part of the system. The contested parts are the registry, the ranking, and the trust model.

Open formats tend to relocate gatekeepers. Once the package format is a commons, controlling it stops being worth much, and the value moves to whoever decides which package the agent finds first. Microsoft’s own ARD announcement says this plainly: “Whoever runs the discovery service controls the answer set.” The ARD materials go further and describe many discovery services, each indexing different resources and applying its own trust, ranking, and access policies. The spec authors are telling you where the power sits.

The power centers I would watch are the ones the specs deliberately leave open:

  • The registry that decides what an agent can discover at all
  • The ranking that decides which capability it prefers when several match
  • The trust layer that decides which publishers are acceptable
  • The runtime that decides what a loaded capability may touch
  • The observability layer that can prove what it actually did

There is also a supply-chain shift buried in here that has not gotten enough attention. Today a developer picks a dependency, pins a version, and commits a lockfile. A human is in the loop at selection time. In the ARD model, an agent can resolve a capability from a registry in the middle of a task. Google’s announcement explains how ARD grounds publisher identity in domain ownership, so a client can confirm which identity published a capability before connecting.

That is necessary and insufficient. Knowing who published a capability tells you nothing about whether it is safe, appropriate for the task, or doing what its description claims. The npm ecosystem had working publisher identity through every typosquatting wave and compromised-maintainer incident it ever had. Identity also does not pin the artifact. A real trust model still needs version selection, digests, revocation, update policy, and a record of what bytes actually ran.

A caveat belongs in any read of this: both documents are early. Agent Plugins calls version 1.0.0 a working draft, and ARD is at v0.9, explicitly open and evolving. The direction is worth taking seriously because this many companies co-signing the same architecture is a stronger signal than any single spec revision.

For my own setup, the packaging direction is immediately useful, but the portability win is incomplete. Codex supports the format; Claude Code and Gemini CLI are not on the current compatible-client list. One manifest instead of three is now a credible target. My shipping reality still needs three.

I will be slower with the discovery half. Before I let an agent resolve its own dependencies mid-task, I want to understand which registry it is talking to, how that registry ranks, and what the capability can touch once it loads. My first experiment will be deliberately boring: one private registry, allowlisted publishers, pinned artifact digests, a deny-by-default runtime, and a trace of every result the resolver considered. That should expose which parts of this emerging supply chain are real and which ones are still being left to the runtime.