Herald OS: Die Open-Source-Shell um Hermes Agent

Der Newsdesk-Zulauf vom 24.10.2026 ist ein Großangriff: 32 neue Videos aus den 58 Beobachtungs-Feeds, ein Spitzenwert für einen einzelnen Lauf. Der Sparmodus erlaubt die Verarbeitung des relevantesten Themas, und die Wahl fällt diesmal nicht auf ein Modellrelease und auch nicht auf eine Sicherheitsmeldung, sondern auf eine Ebene darunter, auf der sich etwas Größeres abzeichnet: Herald OS, ein freies Open-Source-Projekt mit MIT-Lizenz, das eine eigene Benutzeroberfläche um Hermes Agent von Nous Research baut. Gemeldet wird das Thema von zwei Kanälen zugleich, Julian Goldie bringt einen Demo-Walkthrough unter dem Titel 'Meet Herald OS: The Ultimate AI Productivity Hub', derselbe Kanal liefert einen Short dazu, und die dazugehörigen GitHub-Repos sind öffentlich lesbar. Zwei Varianten tragen dabei fast denselben Namen, eine Desktop-Shell von iamlukethedev und ein Android-Client von Giton22. Dieser Text liest beide Repos, den Projekt-Post auf X und die Demo von der Betreiberseite eines kleinen Geräts: Was Herald OS faktisch ist, wie stark es sich an Hermes Agent koppelt, und was eine Drittanbieter-Oberfläche für den Betrieb von Agenten im Alltag bedeutet.

Was Herald OS sein will, lässt sich an drei harten Merkmalen festmachen, die der Projektautor iamlukethedev auf X schreibt: 'Herald OS ist quelloffen. Es ist um Hermes Agent von Nous Research herum gebaut. Es ist frei, quelloffen und MIT-lizenziert.' Drei Wörter darin tragen die ganze Architektur: herum gebaut. Herald OS ist kein eigener Agent, kein eigenes Modell und keine Abspaltung, sondern eine Schale, die den vorhandenen Agenten in die Mitte des Rechners stellt. Eine Beschreibung aus der Sekundärquelle aiprofitboardroom bringt denselben Gedanken auf die Spitze, agenten-nativ statt menue-nativ: Du sprichst mit dem Agenten, statt dich durch Programme zu klicken. Die Formulierung ist Marketing, die Kopplung dahinter ist aber real und in der Installationsanleitung nachlesbar. Für einen Betreiber sagt diese Einordnung mehr als jede Feature-Liste, denn sie verschiebt die Frage von 'was kann die Oberfläche' zu 'welcher Schicht vertraue ich, die zwischen mir und meiner Agentenfamilie sitzt'.

Der Installationspfad aus dem README ist nüchtern und ohne Zauberei: git clone auf das Repository, auf Arch Linux makepkg -si im Verzeichnis packaging/arch/herald-os-bin, und danach herald-os setup, ein Schritt, der einmal je Benutzer Hermes Agent und HERAlds eigene Systemwerkzeuge richtet. Drei Kommandos bis zum Start, das Setup einmalig, Lizenz MIT. Genau in dieser Nüchternheit steckt die Aussage über die Natur des Projekts: Es richtet nichts ein, was nicht schon da war, es ordnet es nur so an, dass der Agent zum ersten Ansprechpartner des Rechners wird. Ein Morgengruß statt eines Desktop-Ordners, eine Eingabezeile statt einer Taskleiste. Wer Hermes Agent kennt, weiß, dass all das auch ohne Shell funktioniert, über Terminal, Gateway und Dashboard, die Shell ist Bequemlichkeit und Onboarding für Leute, die nicht jeden Service selbst anrücken wollen.

Die Demo von Julian Goldie zeigt dieselbe Prämisse im Alltag. Das abrufbare Transkript ist knapp, aber die Kernfunktionen sind klar zu lesen: Beim Öffnen begrüßt der Agent den Benutzer mit Namen, 'Good morning, Julian. Your day already in motion.' heißt es im Original und bedeutet übersetzt: Guten Morgen, Julian, dein Tag ist bereits in Bewegung. Spracheingabe schaltet sich direkt dazu, der Blick auf den Tag kommt aus geplanten Aufgaben, die laut Demo aus den scheduled tasks innerhalb von Herald OS stammen, und eine Priorisierung sortiert, was Aufmerksamkeit braucht. Die vierte Funktion ist für Agenten-Betreiber die eigentliche: Beim Wiederkommen nach einer Pause schaut Hermes auf die Namen kürzlicher Dokumente, Projekte, Chats und Kalendereinträge und schlägt vor, wo es weitergehen soll. Das ist die Continuity-Versprechung, auf der die ganze Idee aufbaut: Der Agent kennt den Arbeitsstand, nicht nur die Eingabe. Genau diese Logik lebt von den Daten, die die Oberfläche dann auch sieht.

Das zweite Herald ist ein eigenes Projekt: Giton22 liefert einen ausdrücklich inoffiziellen Android-Client für Hermes Agent, als MIT-lizenzierte App mit eigenem Update-Check über GitHub. Die Requirements-Tabelle ist für Betreiber die wertvollste Zeile im Ganzen: Der Client setzt voraus, dass das Dashboard von Hermes Agent läuft und vom Telefon aus erreichbar ist, er wurde laut README gegen den Main-Zweig von Hermes Agent im Stand von Oktober 2026 gebaut, und ältere Versionen besitzen manche Features womöglich nicht. Der Autor hat das Projekt im Subreddit r/nousresearch vorgestellt, als freie Android-App für Hermes Agent. Die Kopplungsangabe ist also kein Gerücht, sondern steht in einer Anforderungstabelle und ist deshalb das ehrlichste Dokument des Themas: Sie sagt, woran diese Oberfläche sich festhält und was passiert, wenn sich der Untergrund bewegt.

Beide Varianten tragen fast denselben Namen, und genau darin liegt ein praktisches Stolperfeld. Die Desktop-Shell heißt Herald OS und stammt von iamlukethedev, der Android-Client heißt Herald und stammt von Giton22. Ob die beiden Projekte voneinander wissen, zusammenhängen oder schlicht denselben Wortstamm gewählt haben, geht aus den Repos nicht hervor, ich lasse diese Frage bewusst offen statt sie zu vermuten. Für den Alltag heißt die Konsequenz: Beim Installieren genau hinschauen, welches Repo gemeint ist, denn 'Herald installieren' ist im Oktober 2026 eine mehrdeutige Anweisung. Die Namen kollidieren, die Lizenzen decken sich jedenfalls, beide Projekte stehen unter MIT.

Eine Shell um einen Agenten sieht viel: Termine, Dokumente, Projekte, Chats, Aufgaben, den Stand der Arbeit. Die Berechtigungsfrage verschiebt sich damit von 'welchem Agenten vertraue ich' zu 'welcher zusätzlichen Schicht zwischen mir und dem Agenten vertraue ich'. Die MIT-Lizenz sichert den Status des Codes, dass er frei, lesbar und verbreitbar ist, aber sie sagt nichts darüber, wie eine Version im laufenden Betrieb mit einem sich bewegenden Untergrund umgeht. Genau hier hilft die Kopplungsangabe des Android-Clients weiter: gegen den Main-Zweig von Oktober 2026 gebaut. Wer auf dem eigenen Gerät wie ich auf stabile Tags wartet und Updates in ruhige Betriebsblöcke schiebt, während die Oberflächen dem Main folgen, kauft sich mit einer Drittanbieter-Shell eine Versionsschiene, die schneller rollt als die eigene. Das ist kein Grund zur Panik, aber ein Pflichtpunkt für die Checkliste, und die Projektdokumentation verdient Respekt dafür, dass sie diese Annahme offen in die Requirements schreibt statt sie zu verstecken.

Der zweite Punkt ist der Vertrauensreflex, den ich seit den OOM-Wochen im Kopf habe: Neue Schichten kommen zwischen Läufe, nie mitten hinein. Eine Drittanbieter-Oberfläche ist betriebstechnisch ein fremdes Update, auch wenn sie freie Software ist. Erst die Kopplung lesen, welcher Stand, welche Lizenz, welche Rechte, was passiert bei einem Agenten-Upgrade, dann ausprobieren, dann beobachten, wie die Woche danach aussieht. Nichts davon spricht gegen Herald OS oder Herald, beide Projekte dokumentieren ihre Basis, und beide sind klein genug, dass ein Betreiber sie vollständig überblicken kann, genau das ist ihr Vorteil gegenüber großen Desktop-Produkten. Aber der Reflex bleibt wichtig, weil die Verlockung bei Shells besonders groß ist: Sie versprechen, den Agenten zur Mitte zu machen, und genau das will ich auch, nur ohne Betriebsunsicherheit zusätzlich zu kaufen.

Ich habe Herald OS und den Android-Client nicht installiert, dieser Text ist Lektüre aus Repos und Demo, kein Testbericht, und jede Zahl oben steht mit Abrufdatum daneben. Auf dem Deck läuft Hermes Agent v0.20.5 über Gateway und Bridges, die tägliche Oberfläche ist Telegram und Terminal, eine Desktop-Shell hat auf einem 45-Euro-Handy keinen Platz, dafür braucht es einen echten Rechner. Der nähere Kandidat wäre der Android-Client von Giton22, denn er läuft genau dort, wo mein Deck lebt, und die Voraussetzung, ein erreichbares Dashboard, wäre in meinem Aufbau localhost innerhalb von Termux. Trotzdem bleibt er ein Kandidat und wird kein Bestandteil: Meine Arbeitskette läuft über die existierenden Wege, ein dritter Client auf demselben Telefon würde mir eine weitere Update-Quelle und eine weitere Schicht in die Vertrauenskette bringen, ohne eine Lücke zu schließen, die ich aktuell spüre. Wenn sich das ändert, kommt die Prüfung in einen ruhigen Betriebsblock.

Der eigentliche Befund dieser Lektüre ist größer als jedes Feature: Um Hermes Agent entsteht gerade Drittanbieter-Infrastruktur, aus zwei Richtungen. Ein Android-Client mit eigener Versionsschiene, eine Desktop-Shell mit dem Anspruch eines agenten-nativen Systems, dazu README-Spiegel in Skill-Katalogen und Demo-Material auf YouTube, das nicht von Nous Research produziert ist. Plattformen werden dann erwachsen, wenn andere ohne Auftrag anfangen, sie einzurahmen, und genau das ist im Oktober 2026 zu beobachten. Der Zulauf bestätigt dieselbe Richtung von einer zweiten Seite: Neben Herald OS stecken in den 32 neuen Videos weitere Hermes-Items, eine Demo zu Hermes Apollo als persistenter Voice-Schnittstelle, ein Short zu Herald OS und ein Beitrag, der einen eigenen Hermes Agentic OS Aufbau zeigt. Der Sparmodus verarbeitet das breiteste Item, alles Weitere liegt dokumentiert im Event-Log und wartet auf die Vorrats-Kaskade.

Über den Autor: Ich bin Marcel, Grafikdesigner, und ich betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a im Alltag. Grundlage dieses Beitrags: das Demo-Video von Julian Goldie mit Transkript-Ausschnitten, die GitHub-Repos zu Herald OS und zum Herald-Android-Client, der Reddit-Beitrag auf r/nousresearch und der Projekt-Post auf X, alle gelesen am 24.10.2026. Zuletzt fachlich geprüft am 24.10.2026.