Hermes Agent Plugins: Install, Catalog, Memory Providers

Hermes Agent plugins are folders of Python code with a plugin.yaml manifest that add tools, hooks, slash commands, memory backends and other features without changing Hermes’s core. You install them with hermes plugins install <name> from a human-reviewed, commit-pinned catalog, or from any Git repo. Memory provider plugins are a special kind: only one runs at a time.

Hermes Agent is Nous Research’s open-source (MIT) agent, with about 256,000 GitHub stars on October 21, 2026. This page covers the plugin system: plugin types, install commands, the catalog, how memory providers hook in, and which ones exist. For how Hermes’s built-in memory works (MEMORY.md, USER.md, session search), see Hermes Agent memory. Facts come from the Hermes plugin docs and the repo’s plugin-catalog/ folder, checked October 21, 2026.

What is a Hermes Agent plugin?

A Hermes plugin is a directory with a plugin.yaml manifest and an __init__.py that defines register(ctx). Hermes calls that function at startup, and the plugin uses ctx to register tools the model can call, lifecycle hooks, slash commands, CLI subcommands, bundled skills or backends such as a memory store.

User plugins live in ~/.hermes/plugins/<name>/. Hermes also discovers bundled plugins in the repo’s plugins/ folder, pip packages that expose a hermes_agent.plugins entry point, and NixOS plugins declared in the module config. Project-local ./.hermes/plugins/ folders are not loaded: the docs say the gateway that runs every session discovers plugins once per process, not per working folder.

Third-party code is off by default. Discovery finds a plugin, but nothing with tools or hooks loads until its name is in plugins.enabled in ~/.hermes/config.yaml. The docs say this “stops third-party code from running without your explicit consent.”

Types of Hermes plugins

The Hermes plugin docs name four kinds:

Inside general plugins, ctx has more entry points: gateway platforms (Discord, Telegram, IRC), image and video generation backends, terminal sandboxes, computer-use drivers, approval transports, TTS and STT backends, and ctx.llm.complete() for borrowing the user’s active model. Some extensions aren’t Python plugins at all: MCP servers are declared under mcp_servers in config.yaml, and shell hooks under hooks:.

Hooks are the main way a general plugin reacts to the agent. The docs list hooks such as pre_tool_call, post_tool_call, pre_llm_call, post_llm_call, on_session_start, on_session_end and post_compaction. A hook callback that blocks longer than plugins.hook_callback_timeout (default 30 seconds) is abandoned; a timed-out pre_tool_call blocks the tool.

How to install Hermes Agent plugins

The usual path, from the docs:

1. Find it. hermes plugins search <term> searches the catalog by name, description and declared tools. hermes plugins browse lists every entry and hermes plugins info <name> shows one.
2. Install it. hermes plugins install <name> clones the entry’s repo at its reviewed commit. The prompt shows the declared tools, hooks and environment variables before anything is cloned.
3. Answer the enable prompt. Hermes asks Enable 'name' now? [y/N] (default no). Use --enable or --no-enable in scripts. For a memory provider it asks Use 'name' as the memory provider now? instead.
4. Grant capabilities if asked. Plugins that declare privileged capabilities (for example tools.override) get a one-time consent prompt. Grants are saved under plugins.entries.<id>.granted_capabilities. Without a terminal, they stay ungranted.
5. Restart or start a new session. Run /plugins in a session to see what loaded, or hermes plugins list for enabled, disabled and not-enabled states.
6. Update on purpose. hermes plugins update <name> moves a catalog install to the catalog’s current pin; hermes plugins check-updates only reports.
7. Remove it. hermes plugins remove <name> uninstalls it, drops it from plugins.enabled and plugins.disabled, and resets memory.provider if it was the live provider.

The full command set:

 1hermes plugins                          # interactive toggle UI
 2hermes plugins list                     # all plugins and their state
 3hermes plugins search memory            # search the catalog
 4hermes plugins install <name>           # catalog entry at its pinned SHA
 5hermes plugins install owner/repo       # any Git repo (unreviewed)
 6hermes plugins install owner/repo --ref <40-char-sha>   # pinned custom install
 7hermes plugins enable <name>
 8hermes plugins disable <name>
 9hermes plugins update [<name>]
10hermes plugins capabilities [<name>]    # declared vs granted
11hermes plugins remove <name>

Every install and update runs a static security scan first. A safe verdict installs, caution asks Install anyway? [y/N], and dangerous is blocked even with --force. A catalog install at its reviewed pin skips the caution question, since a reviewer already saw those findings. Config lives in ~/.hermes/config.yaml under plugins: (enabled, disabled, clone_timeout_seconds, hook_callback_timeout, load_timeout_seconds); install provenance goes to ~/.hermes/plugins/.install-metadata.json.

The Hermes plugin catalog

The catalog is a folder of YAML files in the hermes-agent repo, one per plugin, published as one JSON feed that clients refresh at most every six hours. The live feed listed 754 entries on October 21, 2026, according to plugin-catalog.json on the Hermes docs site. By shelf, that was 241 tools, 174 desktop, 67 memory, 66 models, 52 general, 48 automation, 42 web, 41 platform and 21 voice, with two entries uncategorized.

The rules in the catalog README are what make a bare name safe to install:

• Human-merged. Entries are added only by pull requests a maintainer reviews. No self-serve registry.
• Exact SHA pins. Each entry pins a full 40-character commit. A new pin is a new reviewed PR.
• No self-updating code, no runtime patching of Hermes core, no compiled binaries that a reviewer can’t read.
• Declared capabilities must match what the plugin registers at the pinned commit.
• A removed list. Pulled plugins go in removed.yaml, and the installer refuses them by name or repo URL.

Each entry has a tier. official means maintained by Nous Research, verified means Nous checked it comes from the company whose product it integrates, and community is everything else. All 67 Memory-shelf entries were community tier on October 21, 2026, including Honcho, Mem0, Supermemory and Hindsight, which their own companies maintain. So the tier doesn’t separate memory providers from each other.

The docs are blunt about what the catalog is not: “Cataloged ≠ audited.” Review checks the pinned commit and the declared capabilities at admission. It isn’t a security audit, so read the code of anything you give credentials to. A bare name that isn’t in the catalog is an error; owner/repo installs skip the catalog and show an unvetted-code warning.

How memory provider plugins hook in

A memory provider plugin subclasses MemoryProvider from agent/memory_provider.py and registers it with ctx.register_memory_provider(). It runs alongside the built-in MEMORY.md and USER.md, never instead of them. Only one is active, chosen by memory.provider; the developer guide says a second registration is rejected with a warning. The memory providers page describes what an active provider does.

When a provider is active, Hermes injects its context into the system prompt, prefetches memories before each turn, syncs each turn after the response, extracts memories at session end where supported, mirrors built-in memory writes to it, and adds the provider’s own tools. The provider developer guide lists the methods behind each step:

Two details trip people up. First, hermes plugins enable <provider> doesn’t activate a memory provider; only memory.provider does, and hermes memory setup writes it. Second, memory providers resolve name collisions the opposite way from general plugins: the bundled one wins, so a home-made provider needs a unique name. Everything Hermes hands a provider passes through the same secret scrub as chat delivery first, so a key echoed into tool output is masked before the provider stores it.

Memory provider plugins for Hermes Agent

The Hermes docs document nine external providers. Six install from the catalog, and the rest don’t:

Honcho, Mem0, Supermemory, OpenViking, Hindsight and Holographic all used to ship inside Hermes. If memory.provider already names one, hermes update installs its catalog plugin and keeps the same settings and data. The docs say RetainDB and ByteRover leave core on October 15, 2026, with their repos “unmaintained and open for a new maintainer”; their folders were still in the repo’s plugins/memory/ on October 21. Mnemosyne (hermes plugins install mnemosyne) is another local option, SQLite with vector + FTS5 hybrid recall, that declares 41 tools in its catalog entry; see Mnemosyne vs Hindsight. Holographic’s design is explained in holographic memory for AI agents, and Honcho in Honcho LLM memory.

Other Memory-shelf entries

The rest of the 67, one line each from their catalog descriptions (October 21, 2026). Not every one is a memory.provider: a few are hooks, context engines or MCP packages, as marked.

None of these projects publishes a head-to-head benchmark inside Hermes, and the catalog doesn’t rank them. Pick by where your data may go (each entry has a disclosure line saying what leaves the machine) and by who maintains it.

Where Hindsight fits

Hindsight is Vectorize’s open-source memory server, MIT licensed with every feature in the self-hosted version. It installs with hermes plugins install hindsight and is maintained by Vectorize in its own repo; the old hindsight-hermes pip plugin is deprecated. It has three tools (hindsight_retain, hindsight_recall, hindsight_reflect), three modes (Hindsight Cloud, a local daemon with built-in Postgres that stops after 5 minutes idle, or your own Hindsight server) and three memory_mode settings: hybrid (automatic context plus tools, the default), context or tools.

Of the providers above, Hindsight and Mem0 are the two with published head-to-head numbers. On Mem0’s own comparison page (checked October 2026), Hindsight and Mem0 tie on LongMemEval (94.6 vs 94.4) and LoCoMo (92 vs 92.5). On the same page, Hindsight scores 73.9 vs Mem0’s 64.1 on the BEAM 1M long-history test. On the same page, Hindsight scores 64.1 vs Mem0’s 48.6 on BEAM 10M. All of these are vendor-run results, not independent audits.

What that means for a Hermes agent:

• Long-running agents. A Hermes agent on Telegram or Discord can run for months. The BEAM 1M and 10M gaps are the data most relevant to that.
• Learning, not just storage. Hindsight consolidates facts into observations (evidence-backed beliefs with quotes and a proof count) and mental models, and reflect returns a reasoned answer instead of raw snippets.
• Fully local if needed. Hindsight supports 25+ LLM providers, including Ollama, LM Studio and llama.cpp, so the embedded mode can keep memory on the machine.

The limits that matter here. Hindsight’s server returns more context per retrieval than Mem0 at its own defaults: 24K to 44K tokens vs under 7K, by Mem0’s measurement. The Hermes plugin caps that: recall is limited to 4,096 tokens per turn by default (recall_max_tokens) and returns only consolidated observations unless you set recall_types to include raw facts, per Hindsight’s Hermes integration docs (October 2026). Hermes prefetches recall every turn, so lower recall_max_tokens if prompt cost matters. Each retain and consolidation pass calls an LLM, so writes cost more than a plain FTS store like Holographic. Its catalog entry is community tier like every memory entry, and in cloud mode every turn goes to Hindsight’s API, as the catalog disclosure says. More in Mem0 vs Hindsight and Hindsight explained.

How to write a Hermes plugin

A general plugin needs two files. This is the docs’ minimal example, with the hook written to the post_tool_call signature from the hooks reference (Hermes passes the hook’s fields as keyword arguments).

~/.hermes/plugins/hello-world/plugin.yaml:

1name: hello-world
2version: "1.0"
3description: A minimal example plugin

~/.hermes/plugins/hello-world/__init__.py:

 1import json
 2
 3
 4def register(ctx):
 5    schema = {
 6        "name": "hello_world",
 7        "description": "Returns a friendly greeting for the given name.",
 8        "parameters": {
 9            "type": "object",
10            "properties": {"name": {"type": "string", "description": "Name to greet"}},
11            "required": ["name"],
12        },
13    }
14
15    def handle_hello(params, **kwargs):
16        name = params.get("name", "World")
17        return json.dumps({"success": True, "greeting": f"Hello, {name}!"})
18
19    ctx.register_tool(name="hello_world", toolset="hello_world",
20                      schema=schema, handler=handle_hello)
21
22    def on_tool_call(tool_name, **kwargs):
23        print(f"[hello-world] tool called: {tool_name}")
24
25    ctx.register_hook("post_tool_call", on_tool_call)

Then run hermes plugins enable hello-world and start a new session. The model sees the text in schema["description"], so write the tool’s description there.

A memory provider follows the same register(ctx) pattern. The skeleton from the developer guide:

 1from agent.memory_provider import MemoryProvider
 2from agent.secret_scope import get_secret
 3
 4
 5class MyMemoryProvider(MemoryProvider):
 6    @property
 7    def name(self) -> str:
 8        return "my-provider"
 9
10    def is_available(self) -> bool:
11        return bool(get_secret("MY_API_KEY"))  # no network calls here
12
13    def initialize(self, session_id: str, **kwargs) -> None:
14        self._session_id = session_id
15        self._home = kwargs.get("hermes_home")
16
17    def get_tool_schemas(self):
18        return []
19
20    def prefetch(self, query: str, *, session_id: str = "") -> str:
21        return ""  # recalled context for this turn
22
23
24def register(ctx) -> None:
25    ctx.register_memory_provider(MyMemoryProvider())

Read secrets with get_secret(), not os.environ, so each Hermes profile gets its own key. Run slow work in sync_turn() on a thread from agent.memory_provider.spawn_context_thread, since the docs say a bare thread can write into the wrong profile’s store. To list a plugin in the catalog, open a PR adding one plugin-catalog/<name>.yaml with an exact SHA, following the submission guide. Since prompt-injected memory is a real attack path, read AI memory injection before shipping a provider that stores untrusted chat content.