Short version: Paperclip already has credible integration paths for both Hermes and OpenCode. OpenCode is not merely hypothetically compatible: the current Paperclip repo contains a built-in opencode_local adapter that runs opencode run --format json, validates explicit provider/model model IDs, supports session resume, skill injection, instructions bundles, remote execution targets, and JSON transcript parsing. Hermes is also integrated as hermes_local, using the standalone hermes-paperclip-adapter; current Paperclip source registers it alongside built-ins and normalizes Paperclip auth and prompt safety before invoking Hermes.
The strategic distinction is this: Paperclip should be the org/control plane, not another coder. Hermes and OpenCode should be worker runtimes beneath it. Hermes is the richer “generalist employee” because it brings memory, many native tools, skills, MCP, session search, delegation, and gateway/cron semantics. OpenCode is the cleaner “coder employee” because it is terminal-first, open-source, provider-agnostic, and already emits a machine-readable run stream that Paperclip can capture.
The caveat is maturity. All three projects are moving quickly. The Paperclip repo is large and active, but its own issue tracker and adapter code show active churn around OpenCode model discovery, environment handling, auth, runtime config, remote execution, and session artifacts. The Hermes adapter exists and is registered, but its public adapter repo is less active than Paperclip/OpenCode and has integration edges around CLI flags, quiet output parsing, prompt contracts, and non-interactive permissions.
Paperclip describes itself as a Node.js server and React UI for orchestrating teams of AI agents to run a business. Its own README frames it as “the company” above individual “employees,” with org charts, budgets, governance, goal alignment, agent coordination, work/cost tracking, and a dashboard. That framing matters: Paperclip is not trying to replace Claude Code, Codex, OpenCode, Hermes, or OpenClaw. It is trying to coordinate them.
The technical mechanism is the adapter. Paperclip docs define adapters as the bridge between its orchestration layer and agent runtimes. On each heartbeat, Paperclip looks up the agent’s adapterType and adapterConfig, calls an adapter execute(), spawns or calls the agent runtime, captures stdout, parses usage/cost/session state, and returns a structured result.
That means the right integration question is not “can Paperclip become Hermes?” It is “can Paperclip reliably wake Hermes or OpenCode as workers, give them bounded work, observe the run, persist session state, and enforce budgets/permissions?” On the evidence, the answer is yes, with operational caveats.
| Claim | Evidence | Grade | Notes |
|---|---|---|---|
| Paperclip is an agent control plane | Paperclip README and docs describe org charts, budgets, governance, heartbeats, agent coordination, and adapter invocation. | High | First-party repo/docs, current clone at commit 333a16b. |
| OpenCode integrates as a Paperclip coder | Paperclip docs list opencode_local; server registry registers it; adapter code invokes opencode run --format json and manages model/session/skills/runtime config. | High | First-party implementation, not just roadmap copy. |
| Hermes integrates as a Paperclip worker | Paperclip docs list hermes_local; server registry registers it; hermes-paperclip-adapter README and source implement CLI invocation, model/provider selection, skills, session codec, and environment diagnostics. | High | First-party Paperclip registration plus Nous adapter repo. |
| OpenCode is a strong coding runtime | OpenCode README: open-source AI coding agent; install options; built-in build/plan agents; provider-agnostic model support; client/server architecture. | High | Current repo anomalyco/opencode, commit d353a6b; GitHub API showed ~160k stars at research time. |
| Integration is production-smooth today | Adapter exists, but issues and code comments show active fixes around model discovery, auth, runtime config, and environment targets. | Medium | Functional evidence is strong; operational stability depends on exact versions, host auth, and sandbox/remote setup. |
| Hermes should replace OpenCode as the coder | Hermes can code, but OpenCode’s adapter is purpose-built for coding tasks and JSON logs; Hermes has broader tool/generalist strengths. | Medium | Architectural judgment; depends on Brian’s desired worker mix. |
There are two levels of integration:
Paperclip uses hermes_local to spawn Hermes CLI in single-query mode. The adapter passes model/provider/toolset/session options, tags sessions as tool-sourced, injects Paperclip env vars, captures stdout/stderr, extracts session IDs, and returns a structured result.
Hermes could expose a cleaner machine API or ACP/MCP-style execution bridge so Paperclip does not need to scrape quiet-mode CLI output. That would improve streaming, tool-card fidelity, cost accounting, cancellation, and resumption.
The standalone Hermes adapter README claims 8 provider lanes, Paperclip-managed plus Hermes-native skills, structured transcript parsing, comment-driven wakes, model detection from ~/.hermes/config.yaml, session codec support, filesystem checkpoints, and reasoning-effort control. Its execution source shows the concrete command shape: hermes chat -q ... -Q, optional -m, --provider, -t toolsets, --resume, --source tool, and --yolo for unattended runs.
Paperclip’s current server registry wraps that adapter with an auth guard: if Paperclip has an auth token, it injects PAPERCLIP_API_KEY and PAPERCLIP_RUN_ID, and it prepends a safety rule to custom prompt templates telling Hermes to use bearer auth and run IDs on Paperclip API writes. That is exactly the kind of glue a real integration needs.
Main Hermes caveat: the adapter is still CLI-mediated. That is acceptable and consistent with Paperclip’s local CLI adapter model, but the cleanest long-term version would be an adapter that consumes Hermes structured events directly rather than parsing terminal output and regular expressions for session/cost data.
OpenCode is already the most straightforward “coder” fit. Paperclip’s opencode_local adapter is present in source, registered as a built-in, and documented. It requires an explicit model in provider/model format, sets OPENCODE_DISABLE_PROJECT_CONFIG=true so OpenCode does not write config into the target repo, injects runtime permissions for headless operation, and runs:
opencode run --format json --session <id> --model <provider/model> --variant <reasoning>
The adapter reads instructions files, prepends instruction context, renders Paperclip wake prompts, sends the prompt over stdin, parses OpenCode JSONL output, stores session params including cwd/workspace metadata, and can sync skills/runtime config to remote execution targets. Paperclip feedback/export code also knows how to collect OpenCode-native artifacts such as session JSON, messages, message parts, project, todo, and session diffs.
That is a deeper integration than “run a shell command.” It means OpenCode can be a first-class Paperclip employee with resumable work, structured logs, model discovery, and trace export.
Main OpenCode caveat: it is operationally sensitive to model discovery and auth. Paperclip issues mention OpenCode adapter bugs around model lists, race conditions, Windows auth, output formatting, and runtime file leakage. Those are normal integration-hardening issues, but they matter if Brian wants a low-maintenance always-on coder fleet.
| Layer | Best owner | Why | What not to do |
|---|---|---|---|
| Business/org goals, budgets, governance, routing | Paperclip | This is Paperclip’s native abstraction: company, org chart, heartbeats, issues, approvals, run history. | Do not force Hermes/OpenCode to become the control plane. |
| General autonomous worker with broad tools | Hermes | Memory, skills, toolsets, MCP, browser/web/file/terminal, delegation, cron/gateway background workflows. | Do not use Hermes only as a narrow code-diff bot unless its broader abilities are needed. |
| Focused coding employee | OpenCode | Terminal-first coding flow, provider-agnostic models, build/plan agents, JSON run stream, session artifacts. | Do not wrap it with a generic process adapter when the native adapter is available. |
| One-off scripts or glue | Paperclip process/http adapters | Lower overhead for deterministic commands and webhooks. | Do not wake a full LLM agent for work a script can do safely. |
opencode_local rather than process.provider/model; Hermes adapter resolves provider but should be pinned for important workers.Yes. It already does, via hermes_local and the Nous hermes-paperclip-adapter. Best for generalist agents with memory/tools/skills. Hardening target: structured event API, stronger cost/session parsing, clearer version compatibility.
Yes, and more directly for coding. Paperclip has a built-in opencode_local adapter. Best for coder employees. Hardening target: auth/model discovery, sandbox/remote runtime setup, session artifact hygiene, unattended permission boundaries.
My final recommendation: do not choose Hermes vs OpenCode as mutually exclusive. Let Paperclip coordinate both. Hermes should be the “senior operator/researcher/generalist” employee; OpenCode should be the “coder” employee. Paperclip should decide what work exists, who owns it, how much budget/time it gets, when to wake, and when to escalate to Brian.
What might be wrong: Paperclip and OpenCode are changing fast. A repo clone and current docs can prove that integration exists now, but not that the exact installed version in Brian’s environment has the same adapter set. Also, GitHub star counts are weak evidence of production reliability. The report therefore weights source code and docs much more heavily than popularity metrics.
First draft risk was overstating “production-ready” because the adapters are implemented. I rewrote the conclusion to separate existence/fit from operational maturity. The most defensible answer is: integration is real and architecturally coherent; unattended production use still needs version pinning, adapter diagnostics, workspace isolation, and auth/model verification.
| Dimension | Hermes as Paperclip worker | OpenCode as Paperclip coder |
|---|---|---|
| Fit with Paperclip adapter model | 8/10 — CLI adapter maps cleanly to heartbeats, but structured events would be better. | 9/10 — native local adapter, JSON output, explicit model/session handling. |
| Value as worker runtime | 9/10 — broad tools, memory, skills, MCP, delegation, research/ops capabilities. | 8/10 — strong focused coding runtime, less general orchestration surface. |
| Operational simplicity | 7/10 — needs Hermes install/config/provider/toolset policy; non-interactive approvals need care. | 7/10 — needs OpenCode install/auth/model availability; model discovery issues are documented. |
| Observability in Paperclip | 7/10 — adapter parses stdout and produces transcript entries; still CLI-output mediated. | 8/10 — JSONL stream and native session artifacts improve traceability. |
| Risk | Medium — broad tool permissions and persistent memory can be a feature or footgun. | Medium — coder agents can mutate repos; unattended permission config must be bounded. |
| Recommended role | Research/generalist/operator/QA/documentation lead. | Coder/refactorer/test fixer/reviewer. |
claude_local, codex_local, opencode_local, hermes_local, process, HTTP, and external plugin adapters.execute(), test diagnostics, session persistence, skills sync, model detection, and installation paths.opencode_local, model config, headless permissions, skills, runtime config, session resume, and JSON parsing.opencode_local and hermes_local are registered built-ins in current source.