Skip to main content
Smithers ships first-class support for two agent runtimes: Hermes (Nous Research) via a native Hermes plugin, and Eliza (elizaOS), which has Smithers built in by default. In both, Smithers becomes the durable control plane: the agent launches crash-safe, multi-step workflows, clears human approval gates, and stays aware of every in-flight run. The relationship is bidirectional:
  • Hermes / Eliza drive Smithers: they run and operate durable workflows.
  • Smithers drives Hermes: HermesCliAgent lets a workflow <Task> delegate to the Hermes agent itself (see CLI agents).

​
Hermes: a native plugin (not just MCP)

Smithers installs a native Hermes plugin, far richer than a bare MCP entry (MCP can only expose tools). The plugin adds:
  • Slash commands (/smithers run|ps|inspect|output|approve|deny|watch) usable in the Hermes CLI and every gateway (Discord, Telegram, Slack).
  • A live-run status injector (pre_llm_call hook) so Hermes sees active and paused runs, and any pending approval gates, on every turn.
  • Tools: smithers_run, smithers_ps, smithers_inspect, smithers_approve, smithers_deny, smithers_output, smithers_human_answer.
  • A bundled skill (smithers:orchestrate) that teaches Hermes to prefer a durable workflow over a one-off skill.
  • Gateway push-back: a detached run launched from a chat session reports its result back into that same session.
  • Slack approval buttons: an approval gate becomes Approve / Deny buttons that map straight to bunx smthrs approve / bunx smthrs deny.

​
Distribution is one command

The plugin ships inside the Smithers CLI, so installing it is one command:
The command writes the plugin into ~/.hermes/plugins/smithers/, installs the gateway hook into ~/.hermes/hooks/smithers/, enables it in ~/.hermes/config.yaml, and registers the MCP server as a floor (so tools work even if user plugins are disabled). It’s idempotent: rerun it anytime to upgrade. Verify it loaded:

​
Eliza (elizaOS): built in by default

Eliza has Smithers support built in by default, no plugin to install. Any Eliza agent can launch and operate durable Smithers workflows out of the box, and a provider injects live Smithers run status into the agent’s context every turn. What the agent gets:
  • RUN_SMITHERS_WORKFLOW: start a durable workflow for any multi-step or background task (falls back to create-workflow to author one from the request).
  • SMITHERS_APPROVE / SMITHERS_DENY: clear approval gates.
  • SMITHERS_RUNS provider: every turn, the agent sees what’s running and what needs a human.
It reaches Smithers through the smithers CLI (override the binary with $SMITHERS_BIN).

​
Why a workflow, not a skill

In both runtimes the guidance is the same: a Smithers workflow is a superset of a skill, since a skill is static instructions while a workflow is executable, durable, typed, inspectable, composable, and optimizable. Capture reusable procedures as workflows (even small one-task ones), and optimize them like skills with bunx smthrs eval, scorers, and bunx smthrs optimize. See the smithers skill.