Files
hermes-agent/website/docs/user-guide/features/kanban-multi-gateway.md
T
teknium1 0b40f5a790 docs: fold the root docs/ tree into the Docusaurus site and delete it
docs/ was not the documentation site; it was a grab bag of long-form
design notes, wire contracts and observability guides that landed with
feature PRs because their authors needed somewhere to put them. Root
AGENTS.md already says long-form dev docs live in
website/docs/developer-guide/; this moves the 14 living documents there
(or to the matching user-guide section) so they are published, searchable
and linked from the sidebar instead of being found by grep only.

Developer guide: micro-compaction, gateway-session-lifecycle (was
session-lifecycle), state-db-recovery, multiplexing-gateway,
chronos-managed-cron-contract, relay-connector-contract, observer-hooks
(was observability/README), gateway-monitoring (observability/monitoring),
relay-shared-metrics, middleware, streaming-tts, billing-lifecycle.
User guide: egress/network-isolation (was security/network-egress-
isolation), features/kanban-multi-gateway (was kanban/multi-gateway).

Each page got title/description frontmatter and a sidebar entry; repo-
relative links became site links or GitHub blob URLs; two MDX brace
hazards escaped. Every in-tree pointer (module docstrings, config
comments, the relay conformance test's Path, the monitoring-doc test,
gateway-internals, cron-internals, kanban docs, .dockerignore, AGENTS.md)
now names the new location. `docusaurus build` passes with no unresolved
links on the moved pages.
2026-09-13 06:06:46 -07:00

2.2 KiB

title, description
title description
Kanban Multi-Gateway Deployment Running one kanban board across several per-profile gateways: single dispatcher, profile-owned delivery

Multi-gateway deployment

Hermes supports multiple gateway processes running concurrently — one per profile (default, writer, admin, coder, researcher). Each gateway opens its own connection to platform APIs and delivers messages for its profile's subscribers.

Task subscriptions also cover review feedback. A changes_requested review event is delivered as an actionable review-BLOCK notification. Subscriptions using notify+wake additionally wake the exact originating chat/thread/session so the controller inspects the existing card and current run; notify remains passive-only and wake remains wake-only. Review feedback never creates, unblocks, requeues, or otherwise mutates a task.

Single-dispatcher posture

Only one gateway owns the kanban dispatcher. The owning gateway keeps kanban.dispatch_in_gateway: true (the default); every other gateway sets it to false.

Why this matters: dispatching is single-owner so multiple gateways do not race to spawn the same work. Notification delivery is profile-owned instead: each gateway polls only subscriptions for profiles whose platform adapters it hosts. The atomic event claim prevents duplicate delivery across watcher processes.

Configuration

On the dispatch-owning gateway (typically the default profile), no change is needed. On every other profile gateway, add to ~/.hermes/config.yaml:

kanban:
  dispatch_in_gateway: false

Or set the env var: HERMES_KANBAN_DISPATCH_IN_GATEWAY=false

What each gateway does

Gateway role dispatch_in_gateway Opens subscribed board DBs? Dispatcher Notifier
default (confirmed dispatch-lock owner) true (default) yes yes owned profiles + legacy unstamped subscriptions
writer, admin, coder, etc. false yes, when the profile has subscriptions no that gateway's owned profiles

Non-dispatch gateways still deliver messages for their own platform adapters (Telegram, Discord, etc.). They do not dispatch tasks, and they skip boards that have no subscriptions owned by their profiles.