Hermes Agent Adds Opt-In Support for Agent Plugins v1, the First Cross-Vendor Standard for Agent Extensions
On August 6, 2026, Vercel published Agent Plugins 1.0.0, an open, vendor-neutral standard for packaging agent extensions into portable plugins. The standard defines a single directory format — a plugin.json manifest, an optional skills/ directory of markdown workflows, and an optional mcp.json for tool-server configurations — that any conformant agent client can discover and load.
Within hours, Hermes Agent had a community PR open to support it. PR #80593, submitted by GodsBoy on the same day, adds an opt-in compatibility layer that lets Hermes load portable Agent Plugins v1 packages through its existing skills and MCP runtimes.
What Agent Plugins v1 actually defines
The specification was developed by a Technical Steering Committee with core maintainers from AWS, Cursor, Microsoft, OpenAI, and Vercel. Google joined as a core maintainer on launch day and announced support in its Agents CLI and Data Agent Kit.
A plugin is a directory. The spec is explicit about what it does and does not cover:
Agent Plugins 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.
The manifest uses a plugin.json at the plugin root with exactly two required fields: $schema and name. Components live at fixed locations — skills/<name>/SKILL.md for skills, mcp.json at the root for MCP server configurations. Clients must validate containment: no path in the plugin may resolve outside the plugin root after symlink resolution. If one MCP server in a plugin fails to start, the spec requires the client to continue loading the remaining components.
At launch, the format is supported across ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, and VS Code. Hermes becomes the first open-source agent framework outside the launch cohort to add compatibility.
How the Hermes PR works
The implementation is +1,842/-96 lines across 17 files. It does not introduce a second plugin runtime. Instead, it maps Agent Plugins v1 components into Hermes' existing plugin discovery, skill listing, and MCP configuration paths.
| Design choice | What it means |
|---|---|
| Opt-in only | Portable packages must be explicitly enabled. They can launch local processes and expose instructions — Hermes does not activate them by default. |
| No network validation | Manifests are validated against local schemas. The compatibility layer never fetches schemas from the network during plugin loading. |
| Path containment enforced | Symlink escapes, `../` traversal, and any path that resolves outside the plugin root are rejected at the narrowest possible boundary. |
| Native plugins win | Hermes' native plugin.yaml and Python register(ctx) plugins retain precedence. The Agent Plugins path is a compat layer, not a replacement. |
| No model-visible core tool | The compatibility layer adds no tool to the conversation. Skills are discovered through the existing skill system; MCP servers wire into the existing MCP runtime. |
| Component isolation | An invalid MCP server entry does not block valid skills in the same plugin. Each component failure is scoped to that component only. |
The implementation supports the skills/*/SKILL.md fixed location for skills and root mcp.json stdio entries for MCP servers. It expands the standard ${PLUGIN_ROOT} and ${PLUGIN_DATA} placeholders defined by the spec, including creating per-server working directories under PLUGIN_DATA with proper containment.
What's supported and what's next
The initial PR implements a deliberate subset: stdio MCP servers only. The Agent Plugins specification requires an MCP-capable client to support at least one of stdio or streamable-http and recommends both. Hermes already has a native MCP runtime for URL-based Streamable HTTP servers with headers and OAuth handling. As one reviewer noted on the PR:
Hermes already has a native MCP runtime for URL-based Streamable HTTP servers, including headers and OAuth handling. The next compatibility slice should map portable
mcp.jsonStreamable HTTP entries into that existing runtime, preserving the current opt-in and trust boundary.
GodsBoy confirmed this is the planned follow-up. The current stdio subset satisfies the mandatory floor of the spec. Desktop marketplace UX for browsing and installing portable plugins is tracked separately in issue #69921.
The focused test suite for the PR passed 237 tests covering symlink escape rejection, path containment, sibling isolation, and integration with existing MCP configuration paths.
Why this matters
Before Agent Plugins v1, every agent had its own extension format. A skill written for Cursor required a rewrite for Codex. An MCP server configured for VS Code needed a different wrapper for ChatGPT. The overhead of maintaining per-platform versions of the same extension meant most developers simply didn't bother targeting more than one agent.
A single plugin.json manifest and a set of fixed component locations changes the economics. A developer builds one plugin directory. Every conformant client reads the same folder. The plugin author doesn't need to know which agent the user runs.
For Hermes specifically, this means the broader ecosystem of Agent Plugins-compatible skills and MCP servers — anything built for Cursor, Codex, Copilot, or VS Code — can now be loaded in Hermes through hermes plugins install. The reverse is also true: Hermes-native skills packaged under the Agent Plugins format become portable to every other conformant client.
The standard does not touch marketplaces, permissions, or sandboxing. Those are explicitly deferred to future versions or client-specific extensions. What version 1.0.0 delivers is the portable package format itself — a contract that, if both the plugin author and the client hold up their end, the extension works without platform-specific glue.
[^1]: Vercel. "Introducing Agent Plugins." August 6, 2026. [^2]: GodsBoy. "feat(plugins): support portable Agent Plugins v1 packages." PR #80593, NousResearch/hermes-agent. August 6, 2026. [^3]: Agent Plugins Specification. "Agent Plugins Specification 1.0.0." August 2026. [^4]: Google Developers Blog. "Agent Plugins package your skills, tools, and more." August 6, 2026.