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, which is 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 is aware of 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 smithers-orchestrator approve / bunx smithers-orchestrator 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 also registers the MCP server as a floor (so tools work even if user plugins are disabled). It is idempotent: rerun it any time to upgrade. Verify it loaded:

​
Eliza (elizaOS): built in by default

Eliza has Smithers support built in by default: there is 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 on 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 automatically sees what is 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. A skill is static instructions; 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 smithers-orchestrator eval, scorers, and bunx smithers-orchestrator optimize. See the smithers skill.