Finding
Hermes plugin capability is weak when teams jump to custom builds before checking whether a native plugin, dashboard extension, or small Hermes-native integration already solves the need.
Current
A real Hermes installation can extend through native plugins, dashboard surfaces, MCP/tool integrations, skills, cron jobs, and profile instructions. The weak point is usually discovery and governance: new needs are routed straight to custom dashboards, n8n workflows, or LangGraph agents without first checking the Hermes-native extension layer. That creates avoidable maintenance, duplicate UI, and extra operational risk.
Suggested
- Add a plugin-first decision gate before custom work. Exact change: add a “Plugin Goblin check” section to
SOUL.mdor the architecture review runbook: “Before proposing a custom build, check Hermes plugins, dashboard extensions, native toolsets, skills, cron, and existing MCP integrations; only build outside Hermes when the native path cannot meet the requirement.” - Create a lightweight plugin inventory page. Exact change: add a public-safe
docs/hermes-plugin-inventory.mdor Agent Info dashboard copy that lists plugin categories, what each is allowed to expose publicly, and which needs should route to native Hermes instead of custom infrastructure. - Add a verification habit to implementation planning. Exact change: patch the relevant planning skill or optimizer review prompt with: “For each proposed n8n, LangGraph, or dashboard feature, record one line: native Hermes option checked, result, reason for use/extension/build, and public-safety boundary.”
Impact
This keeps Hermes as the primary operating layer instead of surrounding it with unnecessary parallel systems. Plugin-first routing reduces custom code, lowers maintenance cost, and makes future upgrades easier because native capabilities remain visible and reusable. It also improves public Agent Info pages by explaining Hermes maturity patterns without exposing internal plugin settings or live controls.
Effort
Small — the work is a runbook rule, one inventory/checklist artifact, and a planning verification habit. No new infrastructure is required unless the review finds a genuinely missing plugin or dashboard extension.
Public page note
Safe public content includes the plugin-first operating principle, generic plugin categories, maturity benefits, and public-safe examples of when to use native Hermes before custom builds. Internal-only content includes actual plugin configs, credentials, private dashboard routes, raw logs, local filesystem details, internal prompts, customer-specific workflows, and any live action controls.