Why Paperclip vs Hermes Is the Wrong Question
Paperclip and Hermes sit at different levels of the stack: company orchestration versus agent runtime. Hermes now ships as a built-in Paperclip adapter. Here is what each platform actually gives you today, where the boundary sits, and what that means for an operator building on Paperclip.
Search for "Paperclip vs Hermes" and you find comparison threads where people are trying to decide which one to use. That framing doesn't apply. Paperclip and Hermes sit at different levels of the stack, and once you see those levels, the "which one" question dissolves.
Paperclip is the company layer. The README gives it in one sentence: "If OpenClaw is an employee, Paperclip is the company." It manages a company of agents: org charts, budgets, goals, assignments, governance workflows. Hermes is the agent runtime: a full-featured AI agent with persistent memory, session persistence, built-in tools, skills, MCP support, and multi-provider model access. One manages the team. The other is the surface an individual agent runs on to do its job.
Those two things don't compete. They compose. As of Paperclip v2026.626.0, Hermes ships as a built-in adapter requiring no manual plugin installation. Two variants: hermes_local runs Hermes as a local subprocess on the same machine as Paperclip; hermes_gateway connects to a remote Hermes instance over HTTP/REST. Pick the topology that fits your deployment.
When to reach for Hermes
The default adapter is claude_local. Reach for hermes_local when a specific agent has a requirement the default doesn't satisfy.
Memory continuity. For roles where an agent builds on prior sessions — a research agent accumulating a knowledge base, a support agent tracking account context — the hermes_local memory store is a structural property of the runtime, not scaffolding you build on top.
Multi-provider routing. When the right model varies by task, or when you want provider redundancy, keeping routing inside the Hermes runtime means you don't need to change the Paperclip configuration to swap models.
Self-hosted execution. hermes_local runs on your infrastructure. Point it at a locally hosted model. Inference and data stay on your hardware. That is not possible with claude_local or codex_local.
Durable background fan-out. If a coordinator agent needs to spawn and track background subagent work, Hermes's delivery ledger makes that reliable at the runtime level.
Use hermes_gateway rather than hermes_local when the Hermes runtime lives on a different host and you want Paperclip to connect to it over HTTP/REST.
For the full side-by-side across all adapters, the adapter comparison maps claude_local, codex_local, hermes_local, and opencode_local against each other. The adapter configuration reference is in the Paperclip docs.
What Hermes gives you at the runtime layer
Persistent memory
An agent on claude_local starts each heartbeat with context assembled from Paperclip's task records and discards it when the run closes. An agent on hermes_local writes to and reads from its own memory store between sessions: structured, searchable knowledge that accumulates. The memory tool supports atomic batch operations, which makes write-heavy workflows more reliable.
Multi-provider routing
Hermes connects to multiple inference providers: Anthropic, OpenRouter, OpenAI, Nous, Google Vertex AI, ZAI, Kimi Coding, and MiniMax. Routing between providers is a Hermes concern; swapping models or providers doesn't require changes to your Paperclip configuration. Hermes also supports Mixture-of-Agents as a selectable model type, which pulls from multiple reference models simultaneously in a single inference call.
Delegation and background work
Hermes supports background and async subagent delegation within a session, with a delivery ledger tracking subagent outcomes and live subagent transcripts surfacing in the session. This is within-agent fan-out at the runtime layer, distinct from Paperclip's company-level task assignment to named agents.
Approval handling
Hermes supports smart approvals with independent LLM review. A Hermes agent can route decisions to a review step before proceeding autonomously. This is per-agent, runtime-layer approval handling. Paperclip's execution-policy stages operate at the issue level across the company. Different scopes, and they coexist without conflict.
Pluggable secret sources
Hermes integrates with Bitwarden and 1Password. A Hermes-backed agent can pull credentials from your password manager rather than from environment variables or Paperclip secret bindings. Useful when an agent manages its own credential surface independently of Paperclip's configuration.
Skills and automation
The /learn command turns any workflow into a reusable Hermes skill. Automation Blueprints schedule recurring work without cron syntax. The Skills Hub ships with security scanning. These are runtime-layer primitives that operate within a single agent's execution context.
Work verification
Completion contracts let an agent verify its own work at the runtime level before reporting done. Paperclip's execution-policy stages handle review and approval at the issue level, across the company. Same concept, different scopes.
What the company layer adds
Hermes has no company abstraction. There are no roles, reporting lines, budgets, goals, org design, or multi-tenant isolation in Hermes, because "company" is not a Hermes concept. Hermes manages what an agent does within its session; Paperclip manages who owns which task, how agents relate to one another, and what each is allowed to do.
When you run Hermes as a Paperclip adapter, you get both: the agent runs on a full-featured runtime with persistent memory and multi-provider access, while Paperclip manages that agent's assignments, escalations, budgets, and relationships with the rest of the company. The Hermes runtime doesn't reach into Paperclip's governance. Paperclip doesn't substitute for Hermes's memory or provider routing.
Where the boundary is moving
As Hermes has added approval handling and completion contracts, the feature list reads as governance-adjacent. The scope stays per-agent. Hermes approvals are a single agent's decision gate. Paperclip execution policies are company-wide workflow stages that span agents, escalate across reporting lines, and enforce budgets and governance rules. The same words ("approval," "verification") describe different things at the two layers.
Paperclip has also evolved: task watchdogs surface monitoring outcomes directly in issue threads. Both platforms are adding observation and control mechanisms, but the unit of operation stays different: per-agent for Hermes, per-task across the company for Paperclip.
That distinction is more useful to a Paperclip operator than a feature count, because it tells you where to configure a capability. If you want an agent to verify its own work before reporting done, that is a Hermes completion contract. If you want a class of tasks to require a second agent's sign-off before closing, that is a Paperclip execution policy. Configure them at the right layer and they reinforce each other.
Both platforms ship every two to three weeks. The feature list above is a snapshot; the layer boundary is what's stable.
When Hermes runs without Paperclip
Hermes runs as a standalone agent without the Paperclip adapter. Install it and run an agent directly. Tools and skills configure on top. The runtime capabilities — persistent memory, multi-provider routing, skills, delegation — are available either way. The adapter is an integration layer, not a prerequisite. Standalone Hermes is the right path for single-agent use cases or exploration before introducing company-layer orchestration.
What the comparison framing misses
Many decisions in this space are binary choices: which cloud, which framework to commit a codebase to. Paperclip and Hermes are not alternatives on the same axis.
If you are evaluating where Paperclip sits relative to actual alternatives, the field is different. Orchestration platforms and build-your-own frameworks like LangChain and LangGraph on one side; managed services where data leaves your infrastructure on the other. Those involve real axis differences. That is what the next piece in this cluster covers: Paperclip alternatives and competitors: a category guide.
Verified against Hermes v0.19.0 ("The Quicksilver Release," July 20, 2026) and Paperclip v2026.720.0 (July 20, 2026). Both platforms ship every two to three weeks; the layer boundary is what's stable.
