Skip to main content

Hermes Memory Bank Strategy for Production

· 5 min read
Ben Bartholomew
Ben Bartholomew
Hindsight Team

If you are designing a Hermes memory bank strategy for production, the part that matters most is not the model choice. It is how you divide memory space across users, teams, and environments. That one decision controls recall quality, isolation safety, and how easy the system is to debug when something looks wrong.

The mistake I see most often is choosing one bank too early, then stretching it across unrelated workflows. That feels simple at first, but it turns recall into a grab bag. The healthier approach is to pick a bank naming scheme that matches how the agent will actually be used, then keep the scheme stable over time.

This guide walks through the bank patterns that work in production, when to use each one, and how to keep staging, production, multi-user, and shared-team setups from stepping on each other. Keep the Hermes integration docs, the quickstart guide, the Recall API reference, and the Retain API reference nearby while you design it.

Quick answer

  1. One user or one workflow should map to one bank identity.
  2. Add tenant and environment markers early, not after the first incident.
  3. Use a shared bank only when collaboration is intentional.
  4. Keep the naming scheme stable so recall quality compounds over time.
  5. Treat bank_id as architecture, not as a throwaway config field.

Prerequisites​

Before you lock in a production bank strategy, make sure:

  • Hermes already uses the native Hindsight provider.
  • You know whether the deployment is single-user, multi-user, or multi-agent.
  • You know whether staging and production share the same Hindsight backend.

Reference material: Hermes integration docs, docs home, quickstart guide, and Team Shared Memory for AI Coding Agents.

Step by step​

1. Match the bank to the memory consumer​

Start with the question, “who should this memory help?” The answer usually falls into one of four buckets:

PatternExampleBest for
Personaluser:12345one user, one assistant
Tenant plus usertenant:acme:user:12345multi-tenant apps
Shared teamteam:product-alphacoordinated group workflows
Environment-scopedtenant:acme:user:12345:env:prodstaging and prod on one backend

If you do not know which row fits, do not choose a bank yet.

2. Add environment scoping before you need it​

This is the easiest production win in the whole setup:

tenant:{tenant_id}:user:{user_id}:env:{environment}

That one suffix prevents staging data from showing up in production recall and makes debugging much easier.

3. Choose between per-user and shared-team memory deliberately​

Per-user memory is safer by default. Shared-team memory is better when several operators or agents need the same project context.

If you want one bank per user:

{
  "bank_id": "tenant:acme:user:12345:env:prod"
}

If you want one shared bank for a coordinated workflow:

{
  "bank_id": "team:product-alpha:env:prod"
}

The important thing is not which one you choose. It is that you choose it because the workflow demands it.

4. Keep the naming scheme stable​

Memory only compounds if the bank identity stays consistent. If the bank name drifts over time, the same workflow gets split into multiple half-useful banks.

Avoid patterns that depend on:

  • temporary session IDs
  • deploy timestamps
  • rotating container IDs
  • ad hoc branch names

5. Write the bank choice into your launch path​

Do not set bank_id manually by hand in production. Generate it from known inputs:

python - <<'PY'
import json, pathlib
user_id = '12345'
tenant_id = 'acme'
env = 'prod'
base = pathlib.Path.home() / '.hermes'
path = base / 'hindsight' / 'config.json'
path.parent.mkdir(parents=True, exist_ok=True)

cfg = {
    'provider': 'hindsight',
    'hindsight_api_url': 'https://api.hindsight.vectorize.io',
    'api_key': 'YOUR_HINDSIGHT_TOKEN',
    'bank_id': f'tenant:{tenant_id}:user:{user_id}:env:{env}',
    'memory_mode': 'hybrid',
    'prefetch_method': 'recall'
}

path.write_text(json.dumps(cfg, indent=2) + '\n')
print(f'Wrote {path} with bank_id={cfg["bank_id"]}')
PY

Verifying it works​

Check the effective bank ID​

python - <<'PY'
import json, os, pathlib
base = pathlib.Path(os.environ.get('HERMES_HOME', pathlib.Path.home() / '.hermes'))
path = base / 'hindsight' / 'config.json'
cfg = json.loads(path.read_text())
print('bank_id:', cfg.get('bank_id'))
PY

Check that the same workflow stays in the same bank​

Store a durable fact in one session, then confirm it is still recalled in the next session for the same user or team. That is the core production test.

Troubleshooting / common errors​

Staging and production contaminate each other​

You need an explicit environment suffix.

One team bank feels noisy​

It is too broad. Split by workflow or customer segment.

Returning users do not see old context​

The bank naming rule is not stable across launches.

FAQ​

Is one bank per user always best?​

No. It is the safest default, but team workflows often benefit from a shared bank.

Should I include tenant even if user IDs look unique?​

Usually yes. It makes future debugging much easier.

Can one deployment use multiple patterns?​

Yes. Different Hermes workflows can and often should use different bank shapes.

Next Steps​