Share Memory Between Hermes Agents Safely

Steps

1. 1

   Decide what should actually be shared

   Write down the small set of facts every agent needs: project conventions, approved decisions, stable user preferences, or reusable research. Keep secrets, raw transcripts, temporary task state, and private client context out of the shared pool. Use Hermes profiles for isolation first; sharing should be an explicit exception.

2. 2

   Give every agent its own Hermes home

   Never point two running agent processes at the same HERMES_HOME or continuously sync the live ~/.hermes directory. Built-in MEMORY.md, USER.md, state.db, sessions, and provider config are profile-scoped. Create a separate profile with hermes profile create coder or a separate installation before adding shared recall.

3. 3

   Choose one external memory provider

   Run hermes memory setup and select one provider. Hermes supports Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, and Supermemory. Only one external provider can be active per profile, and it runs alongside built-in memory. Choose by storage location, cost, identity controls, and whether multiple agents can intentionally use one workspace, bank, user, or container.

4. 4

   Configure the same shared namespace deliberately

   Point only the cooperating agents at the same provider namespace. In Honcho, profiles can share a workspace and user peer while keeping a distinct AI peer per profile. Hindsight can use a shared bank for common knowledge or a bank_id_template such as hermes-{profile} for isolation. Supermemory can use named custom containers for shared project knowledge. Do not assume that using the same vendor automatically shares the right data.

5. 5

   Keep local memory and shared memory separate

   Store machine paths, private preferences, and agent-specific operating rules in each profile's built-in memory. Put only cross-agent knowledge in the provider namespace. External providers are additive: they can prefetch, retain, search, or synthesize knowledge, but MEMORY.md and USER.md still load as the local frozen snapshot at session start.

6. 6

   Verify provider status in every profile

   Run hermes memory status under each profile and confirm the intended provider is active. Then start a fresh session so the local memory snapshot and provider tools load cleanly. A successful setup wizard is not enough: verify the actual profile, provider, namespace, and storage mode on every machine.

7. 7

   Run a two-agent acceptance test

   Have Agent A save a harmless, unique project fact to the shared provider. Start a fresh turn or session with Agent B and ask for that fact without including it in the prompt. Confirm Agent B can cite it, then save an agent-private fact locally and confirm the other agent cannot retrieve it. This tests both sharing and isolation.

8. 8

   Add review, backup, and deletion rules

   Decide who may write, which tags or containers are allowed, how conflicts are corrected, and how provider data is exported or deleted. Enable built-in memory approval when local writes need review. Back up each profile separately with the Hermes backup guide; provider-side data may need its own export and retention policy.

Pro Tips

• 💡Start with one shared project namespace, not a global memory pool for every bot and user.
• 💡Use provider tags, banks, workspaces, peers, or containers to make the sharing boundary visible.
• 💡Keep raw logs and transcripts in session history; promote only reviewed conclusions into shared memory.
• 💡Test deletion and correction before trusting shared recall with production work.
• 💡If you only need a one-time move, use profile export/import or a controlled backup instead of permanent shared memory.

Troubleshooting

FAQ

Related setup and cost guides