Why Paperclip vs Hermes Is the Wrong Question
People searching for 'Paperclip vs Hermes' are asking the wrong question. They sit at different levels of the stack. Here is the orchestrator-vs-runtime distinction and when Hermes runs as a per-agent adapter inside Paperclip.
Search for "Paperclip vs Hermes" and you find comparison threads where people are trying to decide which one to use. That framing imports a competition that doesn't exist between them. Paperclip and Hermes sit at different levels of the stack, and once you see those levels, the "which one" question dissolves.
Paperclip is an orchestrator. The Paperclip README gives you the frame in one sentence: "If OpenClaw is an employee, Paperclip is the company." It manages a company of agents: org charts, budgets, goals, assignments, and governance. Hermes is a runtime. The Nous Research adapter package describes it as a full-featured AI agent with 30+ native tools, persistent memory, session persistence, 80+ skills, MCP support, and multi-provider model access. One manages the team. The other is the work surface a single agent runs on to do its job.
Those two things don't compete. They compose. Hermes ships as a first-class built-in adapter in Paperclip, meaning an agent inside a Paperclip company can run on Hermes as its execution environment. Paperclip handles the company layer; Hermes handles the agent layer.
The adapter
Two Hermes adapter variants are listed in the Paperclip adapters documentation: hermes_local, which runs Hermes as a local subprocess, and hermes_gateway, which connects to a remote Hermes instance over its HTTP/REST API. The Nous Research adapter package states the relationship plainly: "A Paperclip adapter that lets you run Hermes Agent as a managed employee in a Paperclip company."
Once wired, Paperclip routes work to a Hermes-backed agent the same way it routes to any other: issues, assignments, heartbeat wakes. The agent answers in kind. Hermes handles agent-level execution. Paperclip handles company-level coordination. The layers don't reach into each other's job.
For the decision of which adapter to use within a Paperclip company (claude_local, codex_local, hermes_local, or others), the adapter comparison has the side-by-side. What follows here is the prior question: when does it make sense to bring Hermes in at all, versus running Paperclip with a different adapter or running Hermes standalone without Paperclip?
When Hermes as the adapter makes sense
The default adapter, claude_local, covers most roles. hermes_local makes sense when a specific agent has requirements the default doesn't satisfy.
Persistent memory across sessions
Hermes keeps a memory store that survives across runs. An agent on claude_local starts each heartbeat with only the context assembled from Paperclip's task records, and that context is discarded when the run closes. An agent on hermes_local remembers across sessions: structured, searchable knowledge the agent writes for itself. For roles where continuity matters, a research agent building on prior sessions or a support agent tracking account history, that persistence is a structural property of the runtime rather than scaffolding you build on top.
Model-agnostic routing
Hermes connects to eight inference providers: Anthropic, OpenRouter, OpenAI, Nous, OpenAI Codex, ZAI, Kimi Coding, and MiniMax. Routing between them is a Hermes concern; swapping providers or models doesn't require changes to the Paperclip configuration. For teams where the right model varies by task, or where provider concentration is a risk, the routing belongs in the runtime.
Self-hosted execution
Hermes installs locally via pip. Running it as the adapter means the agent's execution environment stays on your own infrastructure. The Paperclip documentation describes the overall posture as: "all data stays local, and nothing is sent to an external server (beyond the API calls your agents make to Anthropic or OpenAI)." Adding hermes_local keeps the runtime side consistent with that posture. For agents that need to keep inference as well as data on their own infrastructure, pointing Hermes at a locally hosted model makes that possible.
When Hermes runs standalone
The Paperclip adapter is optional. Hermes runs without it: install it, configure tools and skills, and run an agent directly against it. Standalone Hermes covers single-agent use cases, exploration before connecting to an orchestration layer, or any context where the orchestration overhead isn't needed. The runtime capabilities (persistent memory, tools, skills, multi-provider routing) are available either way. The adapter is an integration layer, not a prerequisite.
What the comparison framing misses
"Paperclip vs Hermes" arrives as a question because a lot of decisions in this space genuinely are binary choices: which cloud to run on, which framework to commit your codebase to. Dropped onto an orchestration layer and a runtime, it doesn't apply in the same way. They are not alternatives on the same axis.
If you are evaluating where Paperclip sits relative to actual competitors, the field is wider: other orchestration platforms, build-your-own coding frameworks like LangChain and LangGraph, and hosted managed services where data leaves your infrastructure. Those comparisons involve real axis differences. That is what the next article in this cluster covers: Paperclip alternatives and competitors: a category guide.
