Design discussion: multi-profile deployments in a single gateway process

Summary

Today a hermes gateway run --profile <name> process is bound to exactly
one Hermes profile, which means one model, one system prompt, one MEMORY.md,
one set of skills/tools. For deployments where an operator wants to run
multiple agent personalities in the same Hermes installation — each backed
by a different model or prompt, talking to its own platform endpoint — the
canonical answer today is "run N gateway processes, one per profile."

This works (and we're doing it), but it scales linearly in operational cost
(N supervisors, N ports, N tunnels, N memory footprints). At small N it's
fine; past ~5–10 it starts to bite.

This issue isn't asking for a PR — it's asking whether multi-profile-per-gateway
is on the roadmap, what shape you'd want it to take if so, or whether
"N gateway processes" is the canonical answer indefinitely.

Use case

We're shipping a Hermes integration with Microsoft Agent 365 (Hermes-A365).
An A365 "blueprint" is Microsoft's term for an agent definition: an Entra
app + service principal + bot messaging endpoint + permissions, registered
in a tenant. Each blueprint has its own identity and its own purpose.

A realistic enterprise deployment looks like:

Today this is 4 hermes gateway run processes. Each binds a port, each is
fronted by a tunnel (cloudflared) or reverse proxy, each is its own
process-supervisor entry.

Adapter-level multi-instance is already in Hermes

For reference: the framework already has adapters that handle multiple
instances of the same platform internally. gateway/platforms/slack.py:507
documents the multi-workspace pattern (comma-separated bot tokens, internal
routing); weixin.py keys state by account_id; matrix.py similar.

That pattern works great for same personality, many endpoints — one
Slack adapter, one Hermes agent, N workspaces feeding into it.

But it doesn't help with different personalities, many endpoints — which
is the multi-blueprint A365 case above and (we suspect) a class of use cases
for other platforms too: agencies running differentiated bots for different
clients in the same Hermes install, MSPs running per-tenant bots, etc.

Three deployment shapes (today's space)

1. N gateway processes, one profile each — today's canonical path.
   Works at small N. Cost: N supervisor entries, N ports, N tunnels,
   N memory footprints.

2. One gateway, multi-adapter for one platform — adapter-internal
   multi-instance (Slack pattern). One Hermes agent backs all instances.
   Useful for "same personality, many endpoints" but not the multi-blueprint
   case above.

3. One gateway, multi-profile — what this issue is about. One process,
   N profiles co-resident, each with its own agent loop. Adapter selects the
   right profile based on incoming activity metadata (BF aaInstanceId,
   Slack workspace ID, etc.).

Path 3 is the one that isn't possible today as far as we can tell. If we've
missed an existing mechanism, please redirect.

What we're asking

• Is multi-profile-in-one-gateway on Hermes' roadmap, or is "N processes"
  the canonical answer indefinitely?
• If on the roadmap: what shape would you want it to take? Some axes:
  • ~/.hermes/config.yaml representing multiple profiles inline, vs.
    one config file per profile (today's shape) with the gateway loading N
    of them.
  • Profile selection: keyed by inbound metadata, by adapter, by routing
    rule, or operator-pinned per platform?
  • Session-store / memory isolation: presumably already correct since
    SessionSource includes platform + chat_id, but worth confirming for
    cross-profile guarantees.
  • Plugin / hook scoping: do pre_tool_call hooks fire per-profile or
    globally? Backwards compatibility?
• If not on the roadmap: we'll lean further into path 1 + reverse proxy
  fronting N bridges, and skip the design work. Useful to know.

Why we're asking now (not later)

We just shipped v0.1.x of Hermes-A365 to PyPI. The wrapper's register → publish → cleanup loop works end-to-end against a live tenant from a fresh
pip install. The 1-blueprint case is fully supported.

The first operator with a 5+ blueprint deployment is when path 1's
operational tax starts to land. We'd rather have the design conversation
asynchronously now than scramble when that operator surfaces. We're not
asking for a PR or commitment to ship — just a read on whether this is a
direction Hermes wants to grow in, and what shape would be acceptable if
we eventually contribute it.

Happy to spec further or open a discussion in whatever forum makes most
sense (issue, discussion, RFC doc).

— from the Hermes-A365 maintainers