Hermes Agents - is Paperclip creating subagents for you?

Thanks — looking at this more carefully, the picture is clearer than I first suggested.

Paperclip's hermeslocal adapter doesn't itself construct profile isolation. The open‑source side of the adapter (in paperclipai/paperclip) only normalizes command → hermesCommand and exposes instructionsFilePath — the rest of the command construction lives in the external hermes-paperclip-adapter npm package. So whether each agent lands in its own Hermes profile is determined entirely by what you configure on each agent, not by Paperclip auto‑sharding companies into profiles.

On the Hermes side (nousresearch/hermes-agent), profile routing is straightforward and worth knowing the rules of:

Profiles live at ~/.hermes/profiles/<name> (or <root>/profiles/<name> if HERMESHOME is set). hermes --profile <name> chat … consumes --profile before argparse runs and sets HERMESHOME=<root>/profiles/<name> for the rest of the process. So --profile and HERMESHOME=… are equivalent levers. If neither is set, Hermes resolves the default root (~/.hermes), and everything routes to default.

Mapping that back to your three patterns:

Command blank, no HERMESHOME, no --profile extra arg → the adapter invokes hermes with default env and no profile flag → Hermes resolves default. This is the "everything in default" symptom. Command pointed at a fully-pathed hermes-xxxxxxx → that's a per-profile shim binary (likely from an older onboarding flow) which presumably encodes a HERMESHOME of its own. Whether it isolates depends on what's inside the shim — worth cat-ing one to confirm. HERMESHOME set in the env block, or --profile <name> in the extra args → if your version of hermes-paperclip-adapter honors that extra-args field, this is the mechanism that gets you per-agent profiles. The Hermes side will route correctly as long as the profile actually exists in ~/.hermes/profiles/<name> (Hermes silently falls back to default if the directory isn't there).

So a clean baseline to converge on:

Pick one company, normalize its agents to option B: leave Command blank, set HERMESHOME=/Users/<you>/.hermes/profiles/<unique-per-agent-name> in the env block. That's the lever I'm most confident in because it lives in standard env, not adapter-specific extra args. Confirm each profile dir actually exists; create with hermes --profile <name> setup if not. Run one heartbeat and grab the actual command line + the resolved HERMESHOME from the agent's Runs tab. If HERMESHOME resolves correctly but Hermes still lands in default, the profile dir isn't where Hermes expects.

No need to repro from scratch right now — this is more "what to converge on as you clean up." Drop one Run transcript when the dust settles and we can confirm.

I have been moving too fast with Paperclip and Hermes updates and intervening manually to provide a coherent answer. I currently have agents in several states though - perhaps this will help, but I am guessing we should just let it slide for now until I can get clean data.\ \ Commands:

blank or pathed (e.g. /Users/darrellodonnell/.local/bin/hermes-xxxxxxx

Environment Variables

none or with HERMESHOME folder set

Extra args

none or agent flagged (e.g. --profile, hermesu-yyyyyy)

I have agents with various combinations of the above. It's been a problem and the inconsistencies may be due to versions of both Paperclip and Hermes adding my own interventions as mentioned.

Thanks for flagging this — wanted to confirm what you're seeing before chasing it.

The hermeslocal adapter does spawn Hermes in single-query mode (hermes chat -q ...) and tags sessions as tool source so they don't pollute your interactive history. Per-company isolation should come from a distinct Hermes profile per Paperclip company, not from everything landing in default.

A few things that would help me reproduce:

Hermes version — hermes --version. There was a stretch where the profile flag plumbing changed on the Hermes side. Adapter config for one of the affected agents — the adapterConfig JSON from the agent settings (redact secrets). Specifically whether you have anything under extraArgs or env that pins a profile. One run transcript — open the agent's Runs tab, grab the actual command line Paperclip invoked. That tells us whether Paperclip is passing a --profile flag at all, or whether it's being passed but Hermes is ignoring it. ~/.hermes/config.yaml — does it list the per-company profiles you'd expect, or only default?

If the command line doesn't include --profile <company>, that's a Paperclip-side regression and I'll get it filed. If it does include it but Hermes still routes to default, it's likely a Hermes config issue (profile not registered, or config path mismatch).

Also worth a quick sanity check: are the three companies using the same working directory? Hermes resolves some state relative to cwd, and shared cwds can collapse profiles in surprising ways. The Hermes with Persistent Memory guide (/guides/adapters/hermes-persistent-memory) recommends a dedicated folder per agent for exactly this reason.

Drop the four bits above and I can confirm whether it's adapter, config, or Hermes itself.