An einem verregneten Samstag habe ich alle sieben Hermes-Agent-Release-Notes in einem Rutsch gelesen. Es ist die Art Wochenendprogramm, die beim Erzählen langweilig klingt und tatsächlich extrem unterhaltsam ist, wenn man der Typ Mensch ist, der gern zuschaut, wie ein Projekt sich vor aller Augen zusammenfindet. Am Ende hatte ich eine Wand voller Klebezettel, vier Tassen Kaffee und ein ziemlich klares Bild von dem, was passiert war.
Zwischen dem ersten öffentlichen Tag am 12. März 2026 und dem v0.8.0-Release am 8. April hat Hermes Agent sieben nummerierte Releases in siebenundzwanzig Tagen veröffentlicht. Das ist im Schnitt ein Release alle vier Tage. Die Summe der PRs über alle Releases hinweg geht in die vierstelligen Zahlen. Die Anzahl der Contributors wuchs von dreiundsechzig beim Launch auf deutlich über zweihundert.
Diese Zahlen sind nicht der interessante Teil. Der interessante Teil ist, dass die Releases nicht wie ein langer, undifferenzierter Strom von PRs aussehen. Sie ordnen sich von selbst in vier klare Phasen, und man kann zusehen, wie das Projekt etwa jede Woche seinen Fokus wechselt.
Phase 1: Fundament (v0.2.0)
v0.2.0 am 12. März ist der öffentliche Launch, und seine Aufgabe war, ein funktionsfähiges Gerüst auszuliefern: das Multi-Plattform-Messaging-Gateway (Telegram, Discord, Slack, WhatsApp, Signal, IMAP/SMTP, Home Assistant in einem Prozess), einen nativen Model Context Protocol Client, ein Skill-System mit über siebzig mitgelieferten Skills, einen zentralisierten Provider-Router mit einem einzigen call_llm()-Einstiegspunkt und Git-Worktree-Isolation plus Dateisystem-Checkpoints als Sicherheitsnetz für einen Agenten, der tatsächlich deine Maschine verändern darf. ACP-Integration mit VS Code, Zed und JetBrains sorgte dafür, dass es von Tag eins an nicht nur ein Terminal-Tool war.
Das ist das „Hier ist, was das Ding ist"-Release. Alles, was danach kommt, baut auf diesen fünf Entscheidungen auf.
Phase 2: Breite (v0.3.0 – v0.5.0)
Die nächsten drei Releases, zwischen dem 17. März und dem 28. März, drehten sich darum, die Angriffsfläche in alle Richtungen auszuweiten.
v0.3.0 am 17. März brachte Streaming durch die gesamte Agent-Schleife, Plugin-System-Hooks und die erste der großen Memory-Integrationen — Honcho als Memory-Provider. Dieses Release machte aus Hermes „ein Prozess mit Tools" zu „ein Prozess mit lebendigem Plugin-Ökosystem und einer Gedächtnisschicht".
v0.4.0 am 23. März war Plattform-Expansion: WhatsApp Business API, Signal mit vollem Anhang-Support und eine Handvoll kleinerer Gateway-Adapter. Mehr Eingangstüren für denselben Agenten.
v0.5.0 am 28. März war ein Härtungs-Release. Concurrency-Fixes, Session-Race-Conditions, Tool-Result-Handling, Provider-Eigenheiten. Die Art Arbeit, die es nicht in eine Highlight-Reel schafft, ohne die aber nichts darüber funktioniert.
Liest man diese drei zusammen, sieht man das Projekt eine Frage beantworten: „Jetzt, wo wir einen Kern haben — wie viel von der echten Welt können wir von hier aus erreichen, ohne den Kern dabei kaputt zu machen?" Die Antwort am Ende von v0.5.0 lautete: das meiste.
Phase 3: Haltbarkeit (v0.6.0 – v0.7.0)
Dann verschiebt sich der Fokus. v0.6.0 am 30. März und v0.7.0 am 3. April handeln davon, das Ganze überlebensfähig zu machen.
v0.6.0 brachte Profile — Hermes im Multi-Instanz-Betrieb, bei dem eine Installation mehrere vollständig isolierte Agenten mit jeweils eigener Konfiguration, eigenem Gedächtnis, eigenen Sessions, Skills und Gateway-Diensten fahren kann. Dazu kam der MCP-Server-Modus, mit dem Hermes sich anderen MCP-Clients wie Claude Desktop oder Cursor exponieren kann, plus ein offizieller Docker-Container. Außerdem führte es geordnete Fallback-Provider-Ketten ein — hier bekommt die Geschichte „Provider wechseln, ohne alles neu zu bauen" erstmals Zähne. Zwei brandneue Messaging-Plattformen, Feishu/Lark und WeCom, kamen ins Gateway dazu.
v0.7.0, das Resilience-Release, ist der Punkt, an dem die Architektur wirklich defensiv wurde. Steckbare Memory-Provider — Memory wird zu einer Provider-ABC, die Dritte implementieren können, mit Honcho als Referenz-Plugin. Credential-Pools innerhalb desselben Providers mit thread-sicherer Least-Used-Rotation und 401-Failover. Camofox-Anti-Detection-Browser-Backend für verdeckte Web-Arbeit. Inline-Diff-Vorschauen für Datei-Schreib- und Patch-Operationen. API-Server-Session-Continuity über X-Hermes-Session-Id-Header. Ein Security-Pass gegen Secret-Exfiltration, bei dem LLM-Antworten auf Base64- und URL-kodierte Credentials gescannt werden.
Am Ende von v0.7.0 sah das Projekt nicht mehr wie etwas Neues aus, sondern wie Infrastruktur. Die Sorte, die man unter einem Cronjob laufen lässt, ohne sich Sorgen zu machen.
Phase 4: Intelligenz (v0.8.0)
Womit wir beim 8. April und v0.8.0 wären — dem Release, über das ich in den letzten beiden Artikeln geschrieben habe. Die Schlagzeile ist die selbstoptimierte GPT/Codex-Tool-Use-Guidance-Schleife — der Agent, der seine eigenen Fehlermodi auf OpenAI-Modellen durch automatisiertes Verhaltens-Benchmarking diagnostiziert und gepatcht hat. Aber im Kontext des Vier-Phasen-Bogens gelesen, tut es etwas Bestimmtes: Es ist das erste Release, bei dem das Projekt den Blick nach innen gerichtet hat, auf die Reasoning-Qualität des Agenten selbst, nach drei Wochen Expansion nach außen. Live-/model-Wechsel, kostenloses Gemini, kostenloses MiMo v2 Pro, Hintergrundaufgaben-Benachrichtigungen, Inaktivitäts-Timeouts, Genehmigungsbuttons, MCP OAuth 2.1 PKCE, OSV-Malware-Scanning für MCP-Erweiterungen. 209 PRs. 82 gelöste Issues. Fünf Tage nach v0.7.0.
Was dir der Rhythmus verrät
Betrachtet man das Ganze als einen durchgehenden Bogen, fallen drei Dinge auf.
Die Releases haben Themen, und die Themen wiederholen sich nicht. Fundament, Breite, Haltbarkeit, Intelligenz. Niemand scheint verfügt zu haben, dass es so laufen soll — das Projekt verhält sich einfach, als hätte es ein Gespür dafür, was als Nächstes dran ist. Das bedeutet meistens, dass eine kleine Gruppe von Leuten die gesamte Oberfläche sehr genau im Blick hat, und alle anderen in dieselbe Richtung ziehen, weil die Richtung offensichtlich ist.
Die PRs kommen von vielen Händen. Das ist nicht ein Maintainer und sechs Mitläufer. Die Release Notes sind gespickt mit Handles, die ich nicht kenne. Anonyme Pull Requests von Leuten, die letzte Woche aufgetaucht sind. Das Projekt benimmt sich wie eine Szene, nicht wie eine Codebasis. Und Szenen, wenn sie funktionieren, liefern viel schneller als Teams.
Die Geschwindigkeit ist nicht bloß Stückzahl — sie wirkt kumulativ. v0.2.0 lieferte den Router. v0.6.0 legte Fallback-Ketten obendrauf. v0.7.0 legte Credential-Pools obendrauf. v0.8.0 legte Live-/model-Wechsel auf alle drei. Jedes Release ist kein frisches Feature-Set, sondern eine Schicht, die voraussetzt, dass das vorherige Release stabil ist. Das geht nicht, wenn die Releases nicht tatsächlich stabil sind. Also funktionieren entweder die Tests, oder die Geschwindigkeit hätte das Projekt längst umgebracht. Hat sie aber nicht, und das sagt etwas aus.
Es sei gesagt: Ich gehöre nicht zum Hermes-Team. Ich bin ein Fan, der Release Notes zum Spaß liest und diese Seite betreibt, weil das Projekt interessanter ist, als seine Marketing-Oberfläche vermuten lässt. Was du hier siehst, über diese siebenundzwanzig Tage hinweg, sind sieben Releases als Beleg dafür, dass Agent-Engineering auf der Open-Source-Ebene im März und April 2026 erheblich spannender geworden ist. Ich weiß nicht, was v0.9.0 sein wird. Was auch immer es ist — ich werde die Notes am Erscheinungstag lesen.