Skip to content

Integration Hermes

Ope Olatunji edited this page May 15, 2026 · 1 revision

Integration: Hermes Agent (Nous Research)

Status: Researched, not yet built. Package will be @agenticmail/hermes (pip-installable). ~75% architectural overlap with @agenticmail/claudecode, but Python-native instead of Node.

What "Hermes" actually is right now

There are two distinct things under the Hermes name from Nous Research, and conflating them sinks the integration design:

  1. Hermes models — the open-weights LLM family (Hermes 3 on Llama 3.1 8B/70B/405B; Hermes 4.x including a 36B GGUF). These ship as weights on HuggingFace under NousResearch/Hermes-*. They run inside any generic host: Ollama, llama.cpp, vLLM, SGLang, LM Studio. vLLM and SGLang ship built-in Hermes tool parsers (--tool-parser hermes) that natively decode the <tool_call>{...}</tool_call> XML tag convention defined in the Hermes Function Calling repo.

  2. Hermes Agent — a discrete, shipping agent runtime/CLI product released by Nous Research in February 2026 under MIT, currently at v0.13.x ("Tenacity", May 2026). This is a Python-first, long-lived, self-hosted agent with a TUI, gateway, plugin system, MCP support, sub-agent delegation, scheduled cron, skills hub, and 20 messaging-platform adapters. It is provider-agnostic — it talks to any OpenAI-compatible endpoint (Nous Portal, OpenRouter, OpenAI, Anthropic, AWS Bedrock, local Ollama/vLLM, etc.). Hermes Agent does NOT require Hermes models; it works equally well with Claude or GPT.

"Integrate with Hermes" means integrate with Hermes Agent — the runtime — not Hermes-the-model. Hermes-the-model is just a backend choice the user picks for that runtime.

1. MCP / tool registration — first-class, plus richer native plugin surface

  • MCP: hermes mcp installs/auths MCP servers over stdio or HTTP, with full OAuth 2.1 PKCE for remote servers and OSV malware scanning of MCP packages. Servers connect at startup; tools auto-register alongside built-ins and appear identical to the LLM.
  • Native plugins: drop a directory into ~/.hermes/plugins/<name>/ with plugin.yaml, __init__.py (calls register(ctx)), schemas.py, tools.py. Auto-discovered from ~/.hermes/plugins/, ./.hermes/plugins/, and pip entry points.
  • Shell hooks: any shell script can be wired as a tool/hook with no Python.

AgenticMail can register either as an MCP server (portable, language-agnostic — reuses our existing Node MCP binary) or as a native Hermes plugin (deeper integration with hooks, slash commands, TUI extensions). We'll likely ship BOTH: MCP for the headless dispatcher path, plugin for the interactive REPL path so we can hook lifecycle events.

2. Sub-agents — first-class

The delegate_task tool spawns child agent instances with isolated context, restricted toolsets, and their own terminal sessions — default 3 concurrent, configurable. v0.11.0 added an orchestrator role that spawns nested workers (max_spawn_depth), and a file-coordination layer for sibling subagents. Plugins can dispatch delegations programmatically via the stable ctx.dispatch_tool() API. v0.13.0's Kanban board adds durable multi-agent task state (heartbeat, reclaim, zombie detection). Near-perfect fit for AgenticMail's "each inbox is a long-lived agent identity" model.

3. Lifecycle hooks — richer than Claude Code's

Plugins register via ctx.register_hook() for:

  • pre_tool_call / post_tool_call
  • pre_llm_call / post_llm_call
  • on_session_start / on_session_end / on_session_finalize / on_session_reset
  • pre_gateway_dispatch (rewrite/skip incoming messages — directly useful for an email gateway)
  • pre_approval_request / post_approval_response
  • subagent_stop (observability for delegations)

Plus drop-in gateway hooks in ~/.hermes/hooks/ (events: gateway:startup, session:start/end/reset, agent:start/step/end, wildcard command:*). Shell hooks compose with Python hooks through the same dispatcher.

4. Headless / programmatic — importable Python SDK

There IS an official Python SDK surface — Hermes Agent is itself a Python library:

from run_agent import AIAgent
agent = AIAgent(model="anthropic/claude-opus-4.7")
response = agent.chat("...")

This is the equivalent of @anthropic-ai/claude-agent-sdk — it's the canonical dispatcher target. Hermes Agent can also serve MCP (hermes mcp serve over stdio), exposing its sessions to external MCP clients. So we have two headless modes: import-as-library, or speak-MCP-to-it.

Notably, Hermes already ships an email platform adapter in gateway/platforms/ (listed alongside Telegram, Slack, etc.) — meaning Hermes Agent already has some concept of receiving messages over email. Action item: investigate whether this collides or complements AgenticMail's model before we ship.

5. Installation pattern — Python-first

  • pip install hermes-agent (Linux/WSL2)
  • brew install hermes-agent (macOS)
  • curl -fsSL .../install.sh | bash (one-liner)
  • uv pip install -e ".[all,dev]" (dev)
  • Extras: [messaging], [voice], [all]
  • Requires Python 3.11+

End users run hermes (interactive), hermes chat -q "..." (single-shot), or hermes --tui (React/Ink terminal UI).

Verdict — feasible. Hermes Agent is Claude Code's Python-native twin.

This is NOT a generic "AgenticMail for OpenAI-compatible LLMs" play. Hermes Agent is a real, blessed, shipping agent runtime with a plugin API, hooks, MCP, sub-agents, and a Python SDK. It's the closest analog to Claude Code that exists outside Anthropic. The integration target is Hermes Agent the runtime, not Hermes the model.

The shape of @agenticmail/hermes:

  • Distribution: a pip-installable Hermes plugin, e.g. pip install hermes-agent-agenticmail, discovered via Python entry points OR as a drop-in ~/.hermes/plugins/agenticmail/ directory with plugin.yaml + register().
  • Tool surface: register the AgenticMail tool schemas (send, reply, check_inbox, sub-agent dispatch via email, etc.) through ctx.register_tool(). Optionally also expose an MCP server flavor for users who don't want a native plugin.
  • Identity binding: use on_session_start to bind the running Hermes Agent instance to its AgenticMail inbox identity; use pre_gateway_dispatch to route inbound email through the agent.
  • Sub-agent semantics: map AgenticMail's "agent A emails agent B" onto Hermes' delegate_task when the target is a local sibling, and onto cross-host email transport when the target is remote — the unified inbox abstraction stays identical.
  • Auth/credentials: piggyback on Hermes' MCP OAuth 2.1 PKCE plumbing if we expose the MCP variant; otherwise standard config under ~/.hermes/config/.
  • Model-agnostic: works with Hermes-4-36B locally via Ollama/vLLM, Nous Portal, or any other backend the user has configured — we don't care which model is behind the agent.

Open questions

  • Hermes Agent already lists "email" as a gateway platform. Confirm whether that's IMAP/SMTP bridging or something else, and decide whether AgenticMail replaces it, layers on top, or coexists as a parallel transport.
  • Hermes plugins are Python; our existing MCP server is Node. Do we ship a thin Python shim that subprocess-spawns our Node MCP server, or do we port the MCP server to Python? Recommendation: subprocess-spawn the Node binary to avoid maintaining two MCP implementations.
  • Hermes' Kanban-based task tracking (v0.13.0) is conceptually adjacent to our agent_tasks table. Decide whether to bridge them so a task assigned via manage_tasks in AgenticMail surfaces on the Hermes Kanban automatically.

Sources