On August 6, 2026, the agent ecosystem received a packaging standard. Agent Plugins 1.0.0 was adopted by Amazon, Microsoft, OpenAI, Vercel, and Cursor. The specification ships in VS Code, GitHub Copilot, Cursor, ChatGPT, and Kiro. Google joined as a core maintainer on the same day. The file format is open. The code is Apache-2.0. The spec is CC-BY-4.0. None of that is in dispute. What the announcement does not say is who controls the path from a developer's skill to an enterprise's runtime. That is the distribution layer. It is absent from the specification. Audit gap confirmed.
I have spent the decade since the 2017 ICO boom auditing smart contracts for reentrancy and token emission flaws. The pattern is familiar: open standard, closed control. The 2017 ICO audit gap taught me that narrative never equals code. A standard that packages capabilities but excludes distribution is not a neutral protocol. It is an envelope with the address field left blank.
The timing is worth recording. While the IETF DAWN working group spent July debating the discovery layer beneath agent ecosystems in Vienna, the industry built its own answer. DAWN's charter was deferred at IETF 126 despite 12 pre-charter Internet-Drafts. DAWN was trying to solve the question of how agents and their capabilities are discovered. Agent Plugins 1.0 does not solve that problem. It packages capabilities into portable units. But the simultaneity is not a coincidence. The industry chose shipping over consensus. The message to the standards bodies was unmistakable: the market will define the substrate, and it will do so without waiting.
The technical details of the new standard are straightforward. An Agent Plugin is an archive that bundles an Agent Skill, defined as a declarative description of an agent's capabilities, with an MCP server when required. MCP, or Model Context Protocol, is the wire protocol that lets agents call external tools. The plugin format is designed to be transportable across client runtimes. On paper, a developer can build one skill, package it once, and install it into any compliant client. That is the promise of portability.
The coalition is not small. Jonathan Hefner of Vercel leads the Technical Steering Committee. Clare Liguori represents AWS. Roshan Sadanani represents Cursor. Harald Kirschner represents Microsoft. Gav Verma represents OpenAI. Google contributed two plugin producers, the Agents CLI and the Data Agent Kit, though it is not listed as a client entry. The project name, logos, domains, and GitHub organization are held in trust by a neutral entity. The governance charter prevents any single vendor from holding a majority by assigning seats to individuals, not companies. On the surface, this is a credible attempt at multi-stakeholder governance.
The surface is the problem. The specification is notable for what it deliberately excludes: installation mechanisms, distribution protocols, provenance verification, permission models, sandboxing requirements, and marketplaces. Each of these is a locus of control. By leaving distribution out of the standard, the coalition has guaranteed that each platform operator will build its own channel for how agent skills reach users.
This is where the money lands. The platform operator who ships the client becomes the gatekeeper. Because each platform controls its own distribution, and the spec defines no registry or marketplace, developers who build high-value agent skills are not simply building for a standard. They are selecting which gatekeeper controls their access to enterprise buyers and their path to revenue.
The fragmentation is structural, not accidental. Each client—VS Code, Cursor, ChatGPT, Copilot, Kiro—will define its own discovery and installation experience. There will be separate marketplaces, separate review processes, separate revenue splits, and separate persistence. For enterprise technology leaders evaluating agent deployments, the cost of switching platforms is not just technical. It is commercial. A skill installed across five clients is a skill that must be maintained across five distribution pipelines.
Consider the mathematics. Let n be the number of compliant clients in the ecosystem. The portability of a plugin is bounded by the number of clients that implement the plugin archive format correctly. But the reach of a plugin is bounded by the number of marketplaces in which it is listed. The format solves the first problem. It does nothing for the second. A plugin that is installable everywhere but listed nowhere is a file that exists on a local disk. It has no economic footprint. This is not a subtle distinction; it is the difference between a standard and a product.
I have seen this pattern before. In 2024, I analyzed the custody solutions of the top three approved Bitcoin ETF providers. The regulatory marketing emphasized compliance. The technical reality was centralization risk in multi-signature wallet setups. One provider held an outsized share of key control. The market ignored the nuance until a minor security incident validated the report. The lesson was not that institutions are careless. It was that compliance frameworks mask underlying structural risk. Agent Plugins 1.0 repeats the pattern. Open licensing masks distribution control.
Let me be precise about what the standard does not include. There are no cryptographic signatures for plugin artifacts. There is no content-addressable manifest. There is no standardized permission model. There is no sandbox requirement. According to VS Code documentation, plugins are implicitly trusted at the moment of installation. The runtime executes plugin code with the privileges of the host environment unless the client itself imposes additional safeguards. The specification provides no guidance on how those safeguards should be implemented, audited, or verified.
This is an audit gap, and it is not hypothetical. A malicious agent skill, if delivered through a compromised marketplace or a misleading URL, could execute arbitrary commands in an enterprise environment. The standard does not make this possible; it was already possible. But the standard does nothing to prevent it. In a world where every enterprise is being pressured to deploy agentic workflows, the absence of a trust model is an invitation to incident response teams to build the same governance layer separately, five times, across five clients.
Enter OpenAI Presence. Launched in July, Presence is a governance-focused control plane for enterprise agent behavior. It is designed to sit above agent runtimes and enforce policy, permissions, and auditability. The arrival of Agent Plugins 1.0 with no trust model is the best possible marketing for Presence and its competitors. As MCP gateways crystallize as enterprise infrastructure, companies will need to layer proprietary control planes on top of the open plugin format to manage risk. The standard has created a new category of middleware demand. The ledger does not lie. The open format is a commodity. The governance layer is the margin.
No analysis of the agent ecosystem can ignore Anthropic. The company is absent from the coalition. This is notable because Anthropic authored the underlying Agent Skills specification and the .claude-plugin format that informed the standard. Claude Code is not among the launch clients. No Anthropic representative sits on the Technical Steering Committee. The company made a strategic choice. Claude Code's plugin format supports a broader feature set: custom subagents, hooks, LSP servers, background monitors. It is tied to Anthropic's own client structure and uses the claude.md file convention rather than the agents.md convention adopted by the coalition.
The strategic calculus is visible. Anthropic has decided that platform-specific richness is more valuable than portable minimalism. A developer who builds a plugin for Claude Code can access subagents and hooks that the portable standard cannot express. That is a real capability gap. But it comes at the cost of portability. A Claude-specific plugin will not run in ChatGPT, Copilot, or VS Code without adaptation. Anthropic is betting that superior local capabilities will retain developers better than a lowest-common-denominator format. The coalition is betting that portability and scale will win.
The contrarian position deserves a hearing. The coalition's decision to exclude distribution from the standard may be strategically sound. If the standard had included a registry, the first implementation would likely have become a monopoly bottleneck in the name of interoperability. The absence of a registry prevents any single vendor from owning the canon. Each marketplace must compete on quality, trust, and enterprise integration. There is a plausible argument that the current design is a deliberate attempt to avoid the exact centralization that emerged in Node.js's npm ecosystem.
I have audited enough token issuance schedules to recognize a yield trap when I see one. Yield trap detected. The open-source wrapper is the bait; the distribution layer is the hook. But the absence of trust and provenance is not necessarily a fatal flaw. It can be filled by the market. OpenAI Presence is one example of a commercial control plane. Third-party registries can emerge with their own verification mechanisms. Security vendors can build scan-on-install services for plugins. The standard has created the conditions for a layered ecosystem. Whether those layers remain open or become proprietary toll booths is still undetermined.
The immediate test is whether the Technical Steering Committee maintains genuine neutrality. The governance charter is well-constructed on paper. Each seat belongs to an individual, not a company. No single vendor holds a majority. But governance charters do not enforce compatibility. The real enforcement will be whether competing clients implement the specification in compatible ways. The spec is version 1.0.0. There will be version 1.1, 2.0, and beyond. Each revision will be a negotiation. The absence of Anthropic from the table means the next negotiation will occur without the company that defined the language of Agent Skills.
The deeper issue is the distinction between packaging and discovery. DAWN was chartered to address discovery. Agent Plugins 1.0 does not answer the discovery question. It answers a narrower question: how do I express and package an agent capability? The answer is a file format. That file format does not tell an agent that a plugin exists. It does not tell an enterprise which plugin is the most trusted, the most maintainable, or the most compatible. It does not provide a graph of dependencies or a registry of versions. In the absence of a registry, discovery becomes a marketing exercise. The clients will eat it.
Let me return to first principles. The agent economy, like every economy, runs on scarce resources. The scarce resource is not code. It never was. The scarce resource is access to users and to buyers. In the ICO era, the access was to token buyers. In the DeFi summer, the access was to liquidity. In the agent era, the access is to the enterprise runtime. The standard lowers the cost of creating an agent skill. That is a real gain. But lower creation costs are not the same as lower distribution costs. The distribution cost remains, and it is controlled by the client.
The math of gatekeeping is unambiguous. If there are five clients, each with its own marketplace, a developer who wants full enterprise coverage must negotiate five commercial agreements. Each agreement will have different revenue terms, different approval latency, and different compliance requirements. The effective tax on an agent skill is the sum of those frictions. An open file format does not reduce that tax. It just makes the tax easier to calculate.
Mathematical collapse verified: the portability promise of Agent Plugins 1.0 is real at the packaging layer only. At the distribution layer, the system is fragmented by design. Fragmentation is not an accident. It is a feature for every client operator. Each client can now say “we support the open standard” while building a walled garden around its own marketplace. The walled garden is not incompatible with the standard. It is a separate layer. And the layer is where the revenue lives.
What has the coalition actually shipped? A packaging standard. A set of producer and consumer implementations. A governance process. A set of file conventions. What has it not shipped? A mechanism to verify that a plugin is what it claims to be. A mechanism to revoke a plugin after distribution. A mechanism to allow a plugin to run with least privilege across all clients. A mechanism to migrate a plugin from one platform to another without recertification. Those mechanisms are not details. They are the infrastructure of trust.
I have seen the same pattern in multi-signature custody models. I have seen it in algorithmic stablecoin designs. The common thread is a separation between formal openness and operational control. The formal layer is open. The operational layer is closed. The ledger does not lie, and the ledger here shows that the coalition members are not merely implementing a standard. They are positioning their clients as chokepoints.
A proper trust model would include signed artifacts, hash pinning, permission manifests, capability confirmation before install, and a revocation list. None of these are exotic. They have existed in the package management world for two decades. The decision to omit them is not a technical oversight. It is a deliberate boundary. The boundary protects the ability of each client to define its own security contract. But security contracts without auditability are not contracts. They are promises.
The future of this standard will be decided by three questions. First, will independent implementations of the plugin format emerge outside the coalition? If the format is truly open, any runtime can implement it. If only the coalition members implement it, the standard is a consortium format with a democratic facade. Second, will enterprises require a trust layer as a precondition for adoption? If they do, the open standard will be wrapped in proprietary governance products. Third, will Anthropic eventually support the standard as an import/export format while maintaining its richer native ecosystem? If so, the standard becomes a common interchange format without becoming a primary runtime. Any of those outcomes are possible. None is guaranteed.
The contrarian case remains. The coalition has executed with unusual speed. A working standard shipped in months, not years. The governance structure is deliberately anti-monopolistic. The licensing is genuinely permissive. The technical leadership has significant open-source credibility. I do not dismiss these facts. But speed is not the same as correctness. Shipping is not the same as governing. A standard without a trust model is a liability. The fact that it is an open liability does not change its structure.
The final question is for the enterprise buyer. When you install an agent plugin from a marketplace, you are not installing code. You are installing a relationship. The code is the object. The relationship is the control over updates, revoked permissions, license changes, and telemetry. The plugin format does not define the relationship. The client does. The client belongs to the gatekeeper. The gatekeeper sets the terms. In a fragmented ecosystem, the enterprise must manage multiple gatekeepers. That is the real cost.
Agent Plugins 1.0.0 is a milestone. It is also a warning. The packaging layer is open. The distribution layer is walled. The trust layer is absent. The governance layer is proprietary. That is not a neutral configuration. It is a business model.
The agent economy will not collapse because of a packaging standard. It will not be saved by one either. It will be shaped by the distribution layer, the trust layer, and the governance layer. The standard has fixed the easiest problem. The hard problems remain open. The industry chose shipping over consensus. Now it must choose whether to ship security, portability, and trust, or to ship gatekeepers. Audit gap confirmed. The next release will tell us which choice was made.