Hermes Agent Lays Out Plugin Interface Expansion Across 18 Sub-Issues

What happened

On July 14, Hermes maintainer teknium1 opened tracking issue #64182: a four-phase plan to expand the agent's plugin interface. The plan consolidates a community discussion from the #plugins-interface-ideas Discord channel (July 4) into 18 concrete sub-issues with design sketches, backward-compat analysis, security notes, and acceptance criteria.

The stated goal:

"Contributors with long-queued PRs can ship stable, publishable features as plugins instead of waiting on core merges."

The plan is explicitly additive. No existing plugin API breaks. Every expansion is a new hook, a new ctx method, a new optional manifest field, or a new optional kwarg. An old plugin that loads today keeps loading and behaving identically -- with a versioning-policy CI invariant planned to enforce this.

The four-phase breakdown

What each phase delivers

Phase 0: The foundation

This phase establishes the invariants that every subsequent phase depends on. Three structural issues:

• API versioning and stability contract (#64179). A versioning policy with automated CI enforcement. The "never break old plugins" guarantee becomes testable rather than aspirational.
• Hook delivery parity (#64178). Fixes a class of bugs where hooks fire on some surfaces (CLI) but not others (gateway). Also adds symmetric force-reload so plugin changes take effect without restarting the gateway.
• Plugin lifecycle (#64229). Registration handles, a per-plugin ownership ledger that tracks which plugin owns which tool/hook/command, an on_unload method for cleanup, and supervised background tasks. This is the structural prerequisite for force-reload.

A parallel research spike (#64180) studies how Pi and OpenCode handle event bus and streaming, informing the Phase 2 designs.

Phase 1: Contracts and registries

The largest phase, adding the infrastructure that makes plugins stable and publishable:

• Manifest v2 (#64165). API version field, plugin dependency declarations, a pip-dependency seam so plugins can declare Python package requirements, and a config schema so plugins ship their own YAML defaults.
• Inter-plugin event bus (#64164). Plugins declare what events they emit and what events they listen to. This addresses the cross-mod compatibility problem -- analogous to Minecraft mod load order, as teknium noted.
• Cache-safe context injection (#64167). Plugin-added system prompt sections that persist across process restart and session resume. Byte-stable on resume; no prompt-cache invalidation.
• Config and state bridge (#64227). ctx.get_config/set_config namespace-jailed to the plugin's entry, durable ctx.state, and a ctx.cron facade. Adopts an existing community RFC (#58542 by thebizfixer).
• Capability declarations (#64228). Unifies per-feature trust gates into one declared, diffable model. Re-consent required on update when capabilities expand. Consent and audit over host API surfaces -- not a sandbox.
• Developer tooling (#64230). hermes plugins new scaffold, Plugin Doctor diagnostics, and a standalone test harness so plugin authors can run CI without cloning the full hermes-agent repo.

Phase 2: High-value, higher-risk surfaces

Three features that extend what plugins can observe and control:

• Streaming LLM output hooks (#64161). Observer-only v1: plugins receive deltas and interim messages through a host-owned bounded queue. The design correction explicitly states callbacks never run inline on the token path.
• Pluggable approval (#64162). Transport and gated policy interfaces. Security-critical surface: transport timeout/error denies by default, fallback is explicit opt-in.
• Gateway UX hooks (#64176). Titled/delivered/thread/platform-event hooks plus capability-gated platform actions for Discord and Telegram.

Phase 3: The ecosystem

Two issues that turn individual plugins into a shared ecosystem:

• Plugin packs (#64166). Declarative, shareable plugin sets -- the "modpack" idea from the community thread. Depends on manifest v2 for dependency declarations.
• Community plugin index (#64181). A discovery substrate with hermes plugins search. Includes provenance and capability metadata. The social dashboard (ratings, comments) is explicitly a community-run track, not core.

What already exists

The issue includes a table clarifying which community asks are already covered by the existing plugin system. The plugin system already has: ~20 lifecycle hooks, middleware, custom tools, slash/CLI commands, platform adapters, provider ABCs, and a secret-source interface. The gap is not "can you write a plugin" -- it is "can you write a plugin that is stable across Hermes versions, composable with other plugins, discoverable by other users, and testable without cloning the monorepo."

A ready-to-merge PR

The issue references PR #63359, which adds PluginContext.subagent_lifecycle: a typed, plugin-safe service for launching, monitoring, canceling, and retrieving results from Hermes child sessions. The PR is 650 additions across 4 files, has 42 contract and security tests, CI is green, and it makes zero breaking changes. It is blocked only on maintainer review and fits the tracking issue's charter directly.

Ground rules

Five ground rules apply to every sub-issue:

1. No breaking changes to existing plugin APIs.
2. Prompt caching stays sacred. No extension point may mutate past context or violate message-role alternation.
3. Observer-first. Where a hook could observe or mutate, the observer version ships first.
4. Fail-closed on anything security-adjacent. Approval, secrets, and tool override are behind explicit per-plugin config gates, defaulting off.
5. Desktop Chat GUI plugin surface is out of scope. That design is owned separately.

The tracker is a map, not a sprint plan. Phase 0 is the week-one commitment. The rest is sequenced by dependency, not deadline.

[^1]: teknium1. "Tracking: Plugin Interface Expansion — community ideas, July 2026." GitHub. July 14, 2026.