Why Paperclip vs Hermes Is the Wrong Question

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

claude_local is the adapter Paperclip's documentation recommends and calls the most commonly used, so it is where most agents land. That is a recommendation: the documentation names no default adapter, and you pick one for every agent at create time. Reach for hermes_local when a specific agent has a requirement claude_local 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, and pointing it at a locally hosted model is a property of the runtime: inference and data stay on your hardware without you configuring around it. The choice here is three-way, not two. codex_local can also be routed at a gateway or provider you control — set PAPERCLIP_CODEX_PROVIDERS on the Paperclip host — which is a documented path, but a configuration setting rather than a runtime property. claude_local has no documented path to a locally hosted model. Reach for hermes_local when you want local execution to be structural rather than configured.

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 Paperclip resumes the same Claude Code session on the next heartbeat, so the conversation carries forward. What carries forward is the transcript. An agent on hermes_local writes to and reads from its own memory store between sessions: structured, searchable knowledge that accumulates. That is a different thing — a transcript is replayed, a store is written to and read back — and it is the one hermes_local adds. 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. That is anonymous fan-out inside a single agent's own spawn tree, and it is a different mechanism from Hermes Kanban, Hermes's durable task board, where work is assigned to named profiles. The distinction worth holding is internal to Hermes: delegation is anonymous and scoped to the caller, board assignment is named and shared.

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

Start with what Hermes does ship, because the list is longer than a company-layer pitch would like it to be. Hermes has roles: in Bot Mode each Bot has "its own role, model, memory, skills, and avatar," and Kanban distinguishes worker profiles from orchestrator profiles. It has standing objectives: Persistent Goals, where /goal "gives Hermes a standing objective that survives across turns," bounded by a goals.max_turns setting. It has task assignment — a Kanban task is a row with a title, a status and one assignee, and that assignee is a profile name. It has tenancy: tenants are "soft namespaces within a board for multi-customer setups," and per-board isolation is described as absolute. Hermes also ships a standard specialist roster — researcher, writer, analyst, backend-eng, reviewer, ops. A reader who opens the Kanban page to test one of those should find it confirmed.

What is absent is the layer above them. There is no company entity over the board: boards are, in Hermes's own words, "the hard isolation boundary," and tenants sit inside a board rather than above it. There is no monetary spend cap — the documented cost controls are provider-side, and where Hermes uses the word "budget" it bounds run seconds, goal turns or worker iterations rather than money. And there is no execution-policy stage that spans boards.

That is the axis, and it is the one worth holding: Hermes is board-scoped, Paperclip is company-scoped. The board is a real ceiling rather than a missing feature, and the company layer is what begins above it.

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. Be precise about which mechanism is meant. Hermes's approvals.* subsystem is a decision gate, and the party deciding is not the agent whose action is gated: in smart mode an auxiliary model assesses risk, with uncertain cases escalating to manual prompts that reach the interactive user. Its policy lives in ~/.hermes/config.yaml and applies per-installation across all profiles unless overridden per-profile. 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, and both operate on the same unit — a task. What differs is scope. A Hermes Kanban task is a row with a title, a status and one assignee, and its scope tops out at the board. A Paperclip task spans the company.

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 rule that holds for a class of tasks across the whole company — independent of which board, which agent, or which runtime each task happens to run on — that is a Paperclip execution policy. The question to ask is not which platform can gate a piece of work, but how far the gate reaches. 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.

---

A note on what has been checked here, and what has not. On 2026-09-16 a specific set of passages on this page — the self-hosted-execution bullet, the delegation contrast, the company-layer section, and the three paragraphs on where the boundary is moving — were re-read against Hermes's published documentation and corrected where that documentation contradicted them. Six passages, not the page.

On 2026-09-20 a separate pass covered one claim rather than a set of passages: that claude_local is Paperclip's default adapter, which opened the "when to reach for Hermes" section and was repeated in the sentence after it. Paperclip's documentation names no default adapterType: it states other create-time defaults and not this one, gives claude_local and codex_local the same "Selectable (recommended)" availability tier, and describes the adapter picker as a decision made at hire time. The line now says recommended and most commonly used, which the documentation does say, and says that the adapter is a per-agent choice. What it no longer says is that no default exists: the documentation not naming one is what was checked, and that is what the line now claims. Sources, read 2026-09-20: the agents API reference, the adapters overview, the first-agent walkthrough and the agents guide. That claim only, checked across this whole page rather than at the one line it was reported on — nothing else on this page was part of the 2026-09-20 pass.

That was a documentation read on a date, not a check against a release. Hermes's documentation site carries no version indicator: no version selector, no versioned archive, no statement of which release it tracks. So nothing read there can honestly be pinned to a version number, and the date is the strongest stamp available. Where a version is named it comes from the releases API, which on that date gave the latest tagged Hermes release as v0.21.3 (tag v2026.9.14, 2026-09-14) and the latest Paperclip release as v2026.916.0 (2026-09-16). Those are what was current, not what was tested — nothing here was verified by execution, and neither platform was installed or run for this pass.

On 2026-09-25 a third pass covered one claim, again against Paperclip's documentation rather than Hermes's: that an agent on claude_local discards its context when the run closes. It does not. Paperclip's Claude Code adapter reference states that the adapter "stores the Claude Code session id and resumes it on the next heartbeat when the working directory still matches", and the adapters overview names session persistence or session resume for seven of the nine selectable built-in adapters. The sentence opening the persistent-memory section above has been corrected, and the argument it introduced has been narrowed to what the documentation supports. Session resume is conversation continuity — the transcript comes back. A memory store is knowledge an agent writes for itself and retrieves later, and the overview's adapter table credits hermes_local with persistent memory and no other adapter with it. So the contrast on this page is now between carrying a transcript forward and carrying knowledge forward, which is narrower than what it used to say and is the thing hermes_local actually adds. Qualifiers those pages state and this copy does not lean on: resume is keyed to the working directory, a changed directory starts a fresh session, and the adapter falls back to a fresh session automatically when it cannot resume. Sources, read 2026-09-25: the Claude Code adapter reference and the adapters overview, both also read on 2026-09-17 with the same result. That claim only, checked across this whole page — nothing else here was part of the 2026-09-25 pass, and two documentation reads are still documentation reads: nothing was installed or run for it.

The remaining feature detail on this page is as published on 2026-07-21 and was not part of any of the three re-reads. Both platforms ship every two to three weeks; the layer boundary is what's stable.