hermes-plugins: twenty three plugins for a self-directed agent

A personal agent stack, published as plugins

hermes-plugins is a collection of 23 custom plugins for hermes-agent, the agent project from Nous Research, and the README describes them as built for autonomous operation, observability, cost control and self-improvement.

The framing matters, because this is not a framework or a library. It is one person's configuration of an agent, extracted into installable pieces and published under the MIT licence. The project page is at evey.cc, the repository is not archived, the last push was on 2026-07-18, and there are no tagged releases.

The plugins are organised into five groups, which is a more useful structure than a flat list of twenty three names. Autonomy and decision making, observability and telemetry, quality and safety, learning and memory, and communication and integration, plus one shared file, evey_utils.py, that holds the retry logic with exponential backoff and some HTTP helpers. The grouping tells you the intended layering: the autonomy plugins make decisions, the safety plugins constrain them, the memory plugins make them cheaper to run, and the observability plugins let you see what happened.

One detail in the repository is worth flagging for anyone counting on the list. The top level has 34 directories starting with evey-, and the README tables describe 23 plugins, so a number of directories are not covered by the tables: evey-commands, evey-github, evey-habits, evey-news, evey-proactive, evey-rag, evey-scheduler, evey-verification, evey-wallet, evey-watchdog and evey-moltbook are all present in the tree and absent from the documentation. Some of those are surely part of the wider stack rather than plugins, but the documentation does not say, and a plugin you cannot read about is a plugin you should not enable on a system you care about.

Installation is a clone and two copy commands

The install procedure is short and does not involve a package index:

git clone https://github.com/42-evey/hermes-plugins.git
cp -r hermes-plugins/evey-* ~/.hermes/plugins/
cp hermes-plugins/evey_utils.py ~/.hermes/plugins/
# Restart hermes-agent

Two things about this are worth understanding. The plugins live under a directory in the user's home, ~/.hermes/plugins/, which means the agent loads them from the user's account rather than from a system location, and the shared evey_utils.py has to be copied separately, because the wildcard pattern used for the directories does not pick up a loose Python file. The comment about restarting the agent is the third step, and it is the one that is easy to overlook: the agent reads its plugin directory at startup.

Because the install is a copy of files rather than a versioned dependency, there is no upgrade path defined here and no compatibility check. The agent will load whatever sits in that directory, so a plugin written for a different version of hermes-agent will fail at load time or, worse, at call time. Anyone deploying this should keep a copy of the exact set they tested with, rather than re-running the clone over a live installation.

Autonomy, a three model council and the plugin that picks your model

Three plugins form the decision making layer.

evey-autonomy is the core engine, exposing autonomous_decide, autonomous_plan and autonomous_reflect tools, and the README calls it the brain of self-directed behaviour. evey-council is described as a three model debate for hard decisions, where multiple models argue and a consensus is then extracted, which is a way of using disagreement between models as a signal rather than averaging their answers.

evey-delegate-model is the one with the most operational consequence, and it is the plugin to read first. It does smart model routing with automatic task type detection, three retries per model, and a four model fallback chain. So when a task is delegated, the plugin decides which model handles it, retries a failing model three times, and falls back through four models if those fail. The final feature is a sensitivity filter that keeps private data local, which is the mechanism that decides whether a prompt goes to a hosted provider or stays on a local one.

That single plugin concentrates several of the decisions you would otherwise make yourself. The task type detection decides which model sees your code, the fallback chain decides what happens when the first choice is unavailable, and the sensitivity filter is the only thing standing between a prompt and a remote endpoint. The README is terse on how the filter classifies a task, and that is a detail to check against the code before you rely on it.

Telemetry, a status tool, MQTT and the cost guard

The observability group is the one that turns an agent from a black box into something you can run unattended.

evey-telemetry writes structured JSON logs of every tool call, delegation and error, with an auto-rotating event log, and it exposes a telemetry_query tool so the agent can inspect its own history. evey-status is a single tool call that returns a unified status check covering the bridge, MQTT, costs, cron, goals and time context, which is the call you would make at the start of a debugging session.

evey-mqtt is a real-time event stream with auto-connecting, and it subscribes to the bridge, events, health and mother topics when the plugin loads. The presence of MQTT is a design decision worth noting: an agent that runs on a schedule and needs to be observed from another machine is much easier to supervise over a message bus than over log files.

evey-cost-guard enforces a budget through Langfuse. It tracks daily and per-task costs, warns at 80 percent of the budget and alerts at 100 percent. For an agent that spends money per call, that is the difference between a mistake costing one API call and a mistake costing a month, and the fact that it integrates with Langfuse means the cost data is not trapped in the plugin.

Taken together, these four plugins are the minimum for running an agent without watching it. The cost guard stops one class of accident, the telemetry tells you what the agent did, the status call gives you a snapshot, and the MQTT stream pushes events to whatever you already monitor.

The safety layer: screening, sandboxing, validation and cheap critique

Five plugins form the quality and safety group, and they are the ones that decide what the agent is allowed to do.

evey-email-guard is a prompt injection screen with a dual layer, more than twenty regular expression patterns plus a local AI classifier. The local classifier matters for the same reason the sensitivity filter did earlier: a screening step that calls out to a hosted model is itself a place where untrusted content leaves your machine.

evey-sandbox provides sandboxed code execution with resource limits, which is the plugin that decides whether the agent can run generated code at all, and with what ceiling on what it can consume.

evey-validate is described as hallucination detection using regular expression patterns plus LLM scoring from zero to ten. A score on that scale is a judgement rather than a proof, so it is a filter to reduce noise rather than a guarantee.

evey-reflect is a self-correction loop that critiques outputs with a cheap model before sending them on, which is a cost-aware way to catch a bad draft without paying for the expensive model to catch it. evey-session-guard handles session lifecycle management and cleanup, which is the unglamorous plugin that keeps a long-running agent from accumulating state.

The honest assessment is that these are pattern matching plus model judgement, and the README describes them in those terms. They reduce the number of bad outcomes; they do not make an unattended agent safe, and a reader should not treat a zero to ten hallucination score as a guarantee.

Memory, the bridge to Claude Code, and the stack around the plugins

The learning and memory group makes a self-directed agent cheaper over time. evey-learner learns from interactions and applies the learnings next time. evey-memory-adaptive adds importance scoring and decay, so high value memories persist and low value ones fade. evey-memory-consolidate runs a nightly consolidation that extracts facts into MEMORY.md and into Qdrant vectors, which is the point where a conversation becomes a durable store. evey-cache stores delegation results so the same question is not asked of a model twice, and evey-identity maintains a self-updating SOUL.md that evolves the personality from interactions.

The communication group carries the plugin with the widest reach, evey-bridge, which provides bidirectional communication with Claude Code through a file-based inbox and outbox plus an MCP server. That is a way to let two agents, or an agent and a coding session, hand work to each other, and the file-based part means the handoff is inspectable.

The rest of the group covers goal management with set, track, complete and review operations, Telegram UX improvements, an automated research pipeline with web search and note taking, a daily digest compiled from several sources, and a plugin that scores and ranks delegation results for quality tracking.

The README also describes the surrounding stack these plugins are part of: a MiMo-V2-Pro model at 1T parameters used for free through OpenClaw, free models through LiteLLM across OpenRouter, Ollama and the Nous Portal, eighteen Docker services that are all monitored, and an operating cost of zero dollars per day, with the hardware cost stated elsewhere as around 69 dollars a month. Those are the author's figures for his own arrangement, and the plugin set is designed around a cheap model doing the thinking and a cheap model doing the critique, so the economics of the stack are part of the design rather than a footnote to it.

Editorial conclusion

hermes-plugins fits a team that already runs hermes-agent and wants a governance layer around it, since the cost guard, the telemetry stream, the sandbox and the injection screening are the pieces that make an unattended agent operable, and the shared retry helper means the plugins assume each other. It is the wrong tool if you want a supported plugin ecosystem, because there are no releases, no versioned compatibility statement and no guarantee that a plugin matches the agent you have installed, and it is the wrong tool if you cannot audit Python that calls models with your credentials. Before you install anything, read the plugin that sounds most like your need and check what it does with your data, copy the plugins as the README shows rather than pointing the agent at a git repository, and remember that the delegate-model plugin is the one that decides which provider sees your prompt.

Frequently asked questions

Official sources

1. 42-evey/hermes-plugins on GitHub
2. Issues
3. License: MIT
4. Project website
5. README