Das Hauptfeature von Hermes Agent v0.2.0 war weder eine Modellintegration noch ein Skills-System. Es war das Multi-Plattform Messaging-Gateway — ein einziger Hermes-Prozess, der gleichzeitig auf sieben Chat-Plattformen lauschte: Telegram, Discord, Slack, WhatsApp, Signal, E-Mail (IMAP/SMTP) und Home Assistant. Bis zum Release am 8. April war die Liste auf dreizehn angewachsen — Matrix, Feishu, WeCom, Mattermost, DingTalk und SMS (via Twilio) kamen dazu.
Was dabei leicht übersehen wird: einen Telegram-Bot zu bauen ist nicht besonders schwer. Sieben gleichzeitige Chat-Integrationen zu betreiben, die einen einzelnen Agenten, ein einzelnes Gedächtnis und eine einzelne Tool-Registry teilen — da steckt die eigentliche Architekturarbeit. Dieser Beitrag erklärt, wie Hermes das tatsächlich macht.
Der naive Ansatz, und warum er nicht funktioniert
Wenn du „einen KI-Bot, der auf Telegram und Discord antwortet" bauen sollst, ist der erste Instinkt, zwei separate Bots aufzusetzen. Jeder hat seinen eigenen Prozess, seine eigene Datenbank, seinen eigenen State. Beide rufen dieselbe Sprachmodell-API auf. Der User auf Telegram und der User auf Discord kriegen konzeptuell denselben Agenten, aber praktisch zwei Agenten, die nichts voneinander wissen.
So machen es die meisten Bot-Projekte, und es ist auf Arten schlecht, die erst mit der Zeit auffallen:
- •Das Gedächtnis divergiert. Ein User, der auf Telegram erwähnt, dass er gegen Erdnüsse allergisch ist, hat dieses Wissen nicht, wenn er auf Discord eine Kochfrage stellt. Dem Agenten muss dasselbe zweimal beigebracht werden.
- •Der Tool-State driftet. Ein Cron-Job, der über Slack eingerichtet wird, taucht nicht auf, wenn der User seine Crons auf Telegram prüft. Die Sitzungshistorie ist fragmentiert. Auth-Tokens für geteilte Ressourcen (eine Notion-Integration zum Beispiel) müssen in jedem Bot separat installiert werden.
- •Der Betriebsaufwand multipliziert sich. N Bots bedeuten N Prozesse, N Services, N Log-Streams, N Config-Dateien, N Stellen, die kaputtgehen können. Die Komplexität wächst linear mit der Anzahl der Plattformen.
- •Die Sicherheitsregeln fragmentieren. Wenn du eine Genehmigungsrichtlinie für gefährliche Befehle in einem Bot verschärfst, musst du daran denken, sie in den anderen auch zu aktualisieren. Sicherheitsdrift ist der Standardzustand.
Hermes hat anders entschieden: Es gibt genau einen Agent-Prozess, eine Session-Datenbank, einen Gedächtnisspeicher, eine Tool-Registry. Die Plattformen sind Adapter — dünne Eingangstüren, die Nachrichten in den und aus dem geteilten Agenten leiten.
Die Form des Gateways
Intern hat das Hermes-Gateway drei Schichten.
Ganz unten ist der Agent selbst — derselbe Hermes-Kern, der auch im CLI-Modus läuft. Er weiß nichts über Chat-Plattformen. Er empfängt Nachrichten, durchläuft seinen Agent-Loop (LLM-Aufrufe, Tool-Aufrufe, Gedächtnisabfragen, Checkpoints) und produziert Antworten. Seine einzige Schnittstelle zur Außenwelt ist eine queue-basierte API.
In der Mitte ist der Gateway-Kern — Session-Management, User/Plattform-Routing, Genehmigungsdispatch, Cron-Scheduling, Streaming, Medienhandling. Diese Schicht verwandelt „eine Nachricht von Plattform X, User Y, Channel Z" in „einen Agent-Run in Session S mit diesen Berechtigungen." Sie kümmert sich auch um übergreifende Anliegen: Rate Limits, Flood Control, Duplikaterkennung, Inaktivitäts-Timeouts, Routing von Genehmigungsbuttons, Cross-Plattform-State.
Oben sind die Plattform-Adapter. Einer pro Plattform: ein Telegram-Adapter, ein Discord-Adapter, ein Slack-Adapter und so weiter. Die Aufgabe eines Adapters ist eng — sich mit seiner Plattform verbinden (via Polling, Long-Poll, WebSocket, Webhook oder was auch immer das SDK der Plattform bevorzugt), eingehende plattformnative Events in das interne Nachrichtenformat des Gateways übersetzen und die ausgehenden Antworten des Gateways zurück in das übersetzen, was die Plattform erwartet (Markdown, MarkdownV2, mrkdwn, Discord Rich Embeds, Matrix HTML, Slack Blocks, E-Mail MIME).
Die Adapter sind absichtlich klein. Eine neue Plattform hinzufügen (ein Community-Contributor hat Mattermost in unter 300 Zeilen Python in v0.4.0 hinzugefügt) ist hauptsächlich eine Frage des Mappings zwischen SDK-Events und dem internen Nachrichtenformat des Gateways.
Wie Sessions plattformübergreifend funktionieren
Eine Hermes-Session ist ein Konversationsfaden mit eigenem Gedächtnisfenster, Tool-State und laufender Historie. Auf einer einzelnen Plattform passen Sessions natürlich — eine Session pro Telegram-Chat, eine pro Discord-Channel, eine pro Slack-Thread. Über Plattformen hinweg wird es interessanter.
Standardmäßig behandelt Hermes jede Plattform/Chat-Kombination als eigenständige Session. Dein Telegram-DM mit dem Bot, dein Slack-Thread mit dem Bot und dein Discord-Channel mit dem Bot sind drei separate Konversationen mit drei separaten Kontexten, aber sie teilen alle dasselbe Langzeitgedächtnis über den steckbaren Memory-Provider (ab v0.7.0 standardmäßig Honcho). Die Information, die du erwartest, dass sie mitgenommen wird — „der User ist allergisch gegen Erdnüsse", „der User heißt Alice", „das Projekt des Users heißt Atlas" — reist auf der Gedächtnisschicht, während der Kurzzeit-Kontext jeder Konversation auf die Plattform beschränkt bleibt, die du gerade nutzt.
Dieses Design lässt denselben Assistenten auf jeder Plattform wie denselben Assistenten wirken, ohne jede Nachricht in eine verworrene globale Ausstrahlung zu verwandeln.
Warum geteilte Thread-Sessions wichtig sind
In v0.4.0 hat Hermes ein Feature namens standardmäßig geteilte Thread-Sessions hinzugefügt — in Gruppenchats bekommt jeder User seine eigene Session innerhalb desselben Threads. Das klingt klein und ist riesig für jeden, der je versucht hat, einen Multi-User-Bot in einer Gruppe zu betreiben.
Ohne Per-User-Sessions in einem Gruppenchat ist jede Nachricht Teil einer einzigen geteilten Konversation. Wenn Alice dem Bot eine Frage stellt und Bob dreißig Sekunden später eine andere, ist der Kontext des Bots ein Durcheinander aus beidem. Antworten kreuzen sich. Alices Gedächtnis wird mit Bobs Daten verschmutzt. Der Gateway-Modus wird schlimmer, je mehr User dazukommen.
Mit geteilten Thread-Sessions haben Alice und Bob jeweils ihre eigene private Session im Thread. Sie sehen die Nachrichten des anderen im sichtbaren Chat, aber der Agent führt separate Kontexte und separate Gedächtnisschreibvorgänge pro User. In v0.8.0 wurde das zum Standardverhalten auf allen Gateway-Plattformen. Es ist die Art von Verbesserung, die unsichtbar ist, bis einen die Alternative verbrannt hat — dann will man nie zurück.
Wofür das Gateway eigentlich da ist
Wenn du die Architektur lange genug anschaust, hört das Gateway auf, wie „eine Methode, Bots auf Chat-Plattformen zu betreiben" auszusehen, und fängt an, wie das auszusehen, was es wirklich ist: eine Koordinationsschicht zwischen Menschen (in welcher App sie sich gerade befinden) und einem einzelnen KI-Assistenten mit geteiltem Gedächtnis und geteilten Tools.
Die Chat-Plattformen sind nicht das Produkt. Sie sind die Eingänge. Das Produkt ist der Assistent, der hinter ihnen existiert, und die Tatsache, dass du nie darüber nachdenken musst, welchen Eingang du gerade benutzt.
Das ist das Feature, das Hermes am ersten Tag ausgeliefert hat. Alles andere ist die Geschichte dessen, was diese Koordinationsschicht in den folgenden vier Wochen gelernt hat.