Hermes Desktop schafft eine Bedienoberfläche für Hermes: Chat, Dateien, Profile, Cron, Gateway-Zugang und Remote-Backends an einem Ort. Die persönliche Agenten-Laufzeitumgebung Hermes Desktop erhält damit die Kontrollschicht, die dauerhaft laufenden Agenten bislang fehlte.
Die eigentlich wichtige Frage ist einfacher: Lässt sich nachvollziehen, was der Agent tut, welche Rolle er gerade verwendet und wie man vorgeht, wenn er fehlschlägt?
Deshalb ist Hermes Desktop die eigentliche Neuigkeit, auch wenn die Screenshots wie ein gewöhnliches Produktupdate wirken. Der Kern sind Profile, ein Remote-freundliches Desktop-Setup, das Portal-Onboarding und klare Richtlinien rund um lokale Agenten.
- Hermes Desktop ist eine gemeinsame Oberfläche über denselben Agentenzustand. Laut offizieller Dokumentation teilen Desktop, CLI, TUI, Dashboard und Gateway dieselbe Kernkonfiguration, statt separate Agenten zu erzeugen.
- Profile sind jetzt der Heimatort wiederkehrender Agentenrollen. Sie trennen Config, `.env`, `SOUL.md`, Memory, Sessions, Skills, Cron-Jobs und Gateway-Zustand, während die Dateisystem-Isolation weiterhin explizite Backend-Grenzen erfordert.
- Nous Portal beseitigt das Konto-Chaos beim ersten Start. Ein einziger OAuth-Fluss genügt, um Modellzugang und Tool-Gateway-Zugang einzurichten, statt Suche, Browser, Bildgenerierung, TTS und Sandbox-Tools einzeln zu verdrahten.
- Die Diskussion um lokale Agenten wird zur Sicherheitsdiskussion. NVIDIA und Microsoft sprechen jetzt über Identität, Containment, Richtlinien und OpenShell für Agenten, die den primären Rechner berühren.
Was sich mit Hermes Desktop geändert hat
Hermes Desktop ist bedeutsam, weil es auf demselben Hermes-Agent-Kern aufbaut wie Terminal und Gateway. Die Dokumentation ist eindeutig: Die App teilt Config, API-Keys, Sessions, Skills und Memory mit CLI, TUI und Dashboard.
Das verändert die Gestalt von Hermes grundlegend. Ein Terminal-Agent ist nützlich für alle, die ohnehin in der Shell leben. Eine Desktop-App mit Chat, Dateibrowser, Vorschau-Rail, Profilen, Skills, Cron, Messaging und Command Center macht den Agenten für längere Arbeit durchsichtig und steuerbar.
Das entscheidende Detail ist Zustandskontinuität: Eine Session lässt sich in einer Hermes-Oberfläche starten und in einer anderen fortsetzen, weil alle Oberflächen denselben Agentenzustand nutzen. Erst dadurch fühlt sich Hermes wie etwas an, das sich zuverlässig über Oberflächen hinweg betreiben lässt.
Wer einen wiederkehrenden Agenten-Workflow in einen Geschäftsprozess überführen möchte, findet den passenden Rahmen im AI-Automatisierungsangebot von webvise. Der relevante Scope ist selten die Chat-UI. Es geht um die Workflow-Grenzen, Zugangsdaten, Review-Gates und Recovery-Pfade rund um den Agenten.
| Ebene | Was Hermes jetzt bereitstellt | Warum das zählt |
|---|---|---|
| Desktop | Chat, Dateibrowser, Vorschau-Rail, Einstellungen, Profile, Skills, Cron, Messaging, Command Center | Der Operator kann Arbeit inspizieren und steuern, ohne zwischen verschiedenen Terminals zu wechseln. |
| Profile | Separate Home-Verzeichnisse mit Config, `.env`, `SOUL.md`, Memories, Sessions, Skills, Cron-Jobs und State-Datenbank | Eine wiederkehrende Rolle behält eigene Historie, Tools und Gateway-Zustand. |
| Portal | Ein einziger OAuth-Pfad für Modellzugang und Tool-Gateway-Zugang | Aus vielen API-Konten wird ein zentraler, verwalteter Einstiegspunkt. |
| OpenShell-Richtung | Identität, Containment, Richtlinien, lokales Routing und Maskierung persönlicher Daten | Persönliche Agenten brauchen klare Grenzen, bevor sie den primären Rechner dauerhaft nutzen. |
Profile sind jetzt die Agentenrollen
Hermes-Profile sind heute der klarste Ausgangspunkt für wiederkehrende Agentenrollen. Jedes Profil ist ein eigenes Hermes-Home-Verzeichnis mit eigenem Config, Secrets-Datei, Persönlichkeitsdatei, Memories, Sessions, Skills, Cron-Jobs und State-Datenbank.
Das trennt den Zustand gut genug für wiederkehrende Rollen. Ein Recherche-Profil kann Quellprüfgewohnheiten und Browser-Tools behalten. Ein Schreib-Profil kann Entwurfsregeln und Voice-Constraints pflegen.
Ein Entwickler-Profil hält Repo-Befehle und Testgewohnheiten vor. Jedes Profil kann einen eigenen Gateway-Prozess und Servicenamen betreiben.
Das hat am 8. und 9. Juni 2026 die eigenen Setup-Notizen verändert. Zuvor lag der Gedanke bei separaten Boxen für separate Agenten. Nachdem Profile in der tatsächlichen Architektur verfügbar waren, wurde die sauberere Standardlösung klar: eine Hermes-Installation, Desktop als Bedienoberfläche, Profile als Rollentrennung.
Dieselbe Dokumentation benennt die Grenze deutlich: Profile legen das Dateisystem nicht in eine Sandbox. Ein lokales Terminal-Backend läuft weiterhin mit denselben Dateisystemrechten wie das Benutzerkonto. Wer einen vorhersehbaren Startordner für Gateway- und Cron-Aufgaben braucht, setzt `terminal.cwd` in der Hermes-Config. Stärkere Isolation erfordert ein Backend wie Docker, SSH, Modal, Daytona oder Singularity.
Hier hat der erste Hermes-Profile-Artikel noch immer Bestand. Im Hermes-Profile-Leitfaden lautete die Regel klar: Ein Profil anlegen, wenn eine Rolle sich wiederholt und separates Memory, Tools, Gateway-Zustand oder geplante Aufgaben braucht. Desktop macht diese Regel leichter lebbar, weil der Profilwechsel jetzt sichtbar ist.
Das Setup, das heute Sinn ergibt
Das bevorzugte Setup heute: eine Hermes-Installation auf einem Remote-Rechner, Hermes Desktop über Remote-Gateway verbunden, Profile als Agentenrollen. Telegram oder ein anderer Nachrichtenkanal zeigt in der Regel auf ein einzelnes Assistenz-Profil. Dieses Profil kann über explizite Befehle oder Kanban-Tasks an Recherche-, Entwickler-, Schreib- oder Review-Profile delegieren.
Das hält den menschlichen Einstiegspunkt sauber: Eine Nachricht an einen Assistenten genügt. Der Assistent leitet die Arbeit an das Profil mit dem richtigen Memory und den richtigen Tools weiter. Längere Aufgaben werden zu dauerhaften Tasks, statt in einem komprimierten Chat-Verlauf zu verschwinden.
Eine Reparaturoberfläche außerhalb von Hermes bleibt dennoch sinnvoll. Logs, Gateway-Neustarts, Config-Änderungen und defektes Profil-Wiring erfordern ein Werkzeug, das unabhängig von Hermes selbst läuft.
| Komponente | Verantwortung | Aufgabe |
|---|---|---|
| Desktop | Menschlicher Operator | Sessions, Dateien, Profilzustand, Einstellungen, Skills, Cron und Gateway-Routing inspizieren. |
| Assistenz-Profil | Chatbasierte Hermes-Rolle | Telegram- oder Desktop-Anfragen empfangen, Ziel klären, Arbeit weiterleiten. |
| Recherche-Profil | Quellenbasierte Hermes-Rolle | Docs, Webseiten, GitHub-Issues lesen und quellengestützte Notizen zurückliefern. |
| Schreib-Profil | Entwurfs-Hermes-Rolle | Freigegebene Notizen in Entwürfe umwandeln, ohne Secrets oder Shell-Zugang zu halten. |
| Review-Profil | Sicherheits-Hermes-Rolle | Aussagen, Berechtigungen, Zugangsdaten und riskante Übergaben prüfen. |
| Unabhängige Admin-Oberfläche | Reparaturschicht | Das Laufzeitsystem reparieren, wenn das Agenten-Setup selbst fehlschlägt. |
| Option | Sinnvoll wenn | Nicht geeignet für |
|---|---|---|
| Desktop auf lokalem Runtime | Ein persönlicher Agent auf dem bereits verwendeten Rechner genügt. | Riskante Dateisystemarbeit ohne Sandbox. |
| Desktop plus Remote Gateway | Die UI soll lokal laufen, der Hermes-Runtime auf einem Remote-Rechner. | Das Kaschieren schwacher Profilberechtigungen. |
| Profile | Rollen benötigen separates Memory, Tools, Cron, Zugangsdaten oder Gateway-Zustand. | Betriebssystem-Isolation. |
| Docker, SSH, Modal, Daytona oder Singularity Backend | Ein Profil braucht eine härtere Ausführungsgrenze. | Das Beheben eines vagen Übergabe-Vertrags. |
| OpenShell oder Windows-Agent-Primitives | Lokale Agenten berühren Dateien, Zugangsdaten, Apps oder Model-Routing auf dem primären Rechner. | Das Überspringen menschlicher Prüfung bei Hochrisiko-Aktionen. |
Bittet ein Team webvise, dieses Setup zu kartieren, beginnt die Arbeit mit der Berechtigungstabelle, bevor auch nur ein einziger Skill geschrieben wird. Der AI-Automatisierungsansatz zahlt sich aus, sobald Verantwortliche, Tools, Zugangsdaten und Review-Gates klar genug definiert sind, dass ein fehlgelaufener Agentenlauf sofort sichtbar ist.
Portal beseitigt das Konto-Chaos
Die offizielle Nous-Portal-Dokumentation bezeichnet `hermes setup --portal` als schnellsten Einrichtungsweg. Ein einziger OAuth-Fluss setzt Nous als Inferenz-Anbieter, erlaubt die Modellauswahl und aktiviert das Tool-Gateway.
Das zählt, weil Agenten-Setup erfahrungsgemäß vor dem ersten nützlichen Workflow scheitert. Suche erfordert ein Konto. Browser-Automatisierung ein weiteres. Bildgenerierung, Text-to-Speech und Terminal-Sandboxing fügen weitere Keys, Dashboards, Guthaben und Fehlerpunkte hinzu.
Portal bündelt Zugang zu über 300 Modellen und einem Tool-Gateway für Suche und Extraktion, Bildgenerierung, Text-to-Speech, Cloud-Browser-Sessions und eine optionale Terminal-Sandbox. Die genaue Modellliste wird sich ändern. Die Produktrichtung ist stabil: Hermes soll das erste nützliche Agenten-Setup auf einen einzigen Befehl statt auf fünf Anbieter-Konten reduzieren.
Portal verändert auch, wo Secrets leben. Laut Dokumentation hinterlässt OAuth ein Refresh-Token in `~/.hermes/auth.json` und prägt kurzlebige JWTs pro Anfrage, statt `.env` mit Dutzenden langlebiger API-Keys zu füllen. Das ist sauberere Setup-Hygiene, aber Regeln auf Rollenebene bleiben trotzdem nötig.
Die eigentliche Arbeit bleibt: Welches Profil besitzt welche Zugangsdaten? Welches Tool darf Daten verändern? Welche Aktion erfordert menschliche Prüfung? Wo möglich, bekommen Agenten benannte Konten und benannte API-Keys. Secrets gehören in Config, `.env` oder Container-Umgebungspfade, niemals in Chat-Verläufe.
Lokale Agenten brauchen Richtlinien vor Autonomie
Hermes Desktop erschien genau dann, als die Hardware-Diskussion lauter wurde. Im RTX-AI-Garage-Beitrag schrieb NVIDIA, dass Hermes in weniger als drei Monaten 140.000 GitHub-Stars überschritten hatte und in der Vorwoche der meistgenutzte Agent auf OpenRouter war.
Am 31. Mai und 2. Juni 2026 veröffentlichten Microsoft und NVIDIA die Windows-Seite derselben Geschichte. Microsofts Windows-Beitrag nennt OS-erzwungene Identität, Containment und Verwaltbarkeit. NVIDIAs Entwickler-Beitrag nennt Microsoft eXecution Containers, OpenShell, Richtlinienerstellung, Inferenz-Routing und PII-Obfuskation.
Das ist die richtige Richtung für Hermes. Ein persönlicher Agent mit Datei-, Terminal-, Browser-Zugang, Memory, Voice, Cron und Gateway-Routen berührt schließlich denselben Rechner, den man für Banking, Code, Dokumente und Arbeitskonten nutzt. Die Fähigkeit ist bereits vorhanden. Das Schwierige ist zu begrenzen, wer Dateien lesen, Geld ausgeben, Secrets preisgeben oder Produktivumgebungen ändern darf.
Die OpenShell-Dokumentation benennt die Risikotabelle klar: Datenexfiltration, Zugangsdaten-Diebstahl, unbefugte API-Nutzung und Privilege-Escalation. Im Beitrag zur Hermes-Operator-Schicht nach Tag 30 war das Argument bereits: Übergabe-Verträge und Berechtigungs-Gates zählen nach der ersten Demo. Desktop und Profile machen diese Gates sichtbarer. OpenShell und Windows-Richtlinien-Primitive zeigen auf die nächste Grenze: das Betriebssystem.
Das Setup diese Woche ausprobieren
Empfehlenswert ist ein Einstieg mit einem Runtime und drei Profilen. Das Assistenz-Profil wird zur Standard-Route für menschliche Anfragen. Recherche- und Schreib-Profil arbeiten als separate Worker. Secrets bleiben aus dem Schreib-Profil heraus.
| Schritt | Befehl oder Aktion | Prüfung |
|---|---|---|
| Recherche-Profil erstellen | `hermes profile create researcher --description "Reads docs and returns source-backed notes."` | Das Profil besitzt eigene `SOUL.md`, Memory, Skills und Sessions. |
| Schreib-Profil erstellen | `hermes profile create writer --description "Turns approved notes into drafts."` | Das Profil hat keine Shell und keine privaten Zugangsdaten, die es nicht benötigt. |
| Projektordner festlegen | `hermes config set terminal.cwd /absoluter/pfad/zum/projekt` | Gateway- und Cron-Tool-Aufrufe starten in einem vorhersehbaren Verzeichnis. |
| Desktop mit Remote-Backend verbinden | `hermes dashboard` auf dem VPS starten, Desktop über Remote-Gateway verbinden. | Desktop sieht Sessions und Profilzustand des Remote-Runtimes. |
| Reparaturschicht bereithalten | Eine Admin-Oberfläche außerhalb von Hermes einrichten. | Dashboard, Gateway und Config lassen sich beheben, wenn Hermes selbst nicht mehr reagiert. |
| Berechtigungsregel schreiben | Festlegen, welches Profil Dateien lesen, APIs aufrufen, Entwürfe schreiben, Shell-Befehle ausführen oder Geld ausgeben darf. | Jede Hochrisiko-Aktion hat einen Verantwortlichen und ein Review-Gate. |
| Memory-Timing prüfen | Eingebautes Memory als Kontext zum Session-Start behandeln. | Memory-Schreibvorgänge mid-Session werden zuverlässiger Kontext in der nächsten Session, nicht sofort. |
Der erste Erfolgsmaßstab klingt unspektakulär: Lässt sich beim Assistenten ein quellengestütztes Briefing anfordern, der Aufgabenweg nachverfolgen, die Ausgabe inspizieren und ablesen, welches Profil welche Dateien oder Tools berührt hat? Wer das mit Ja beantworten kann, hat eine Bedienoberfläche. Wer die Antwort nur in einem einzigen Chat-Verlauf findet, hat eine Demo.
Bei webvise entscheidet diese Art von Agenten-Setup-Analyse, welche Workflows Automatisierung verdienen und welche als geprüfte Tools besser aufgehoben sind. Eine gute erste Kartierung zeigt den wiederkehrenden Prozess, die berührten Tools und die Aktionen, bei denen ein fehlgelaufener Agent echten Schaden anrichten könnte.
Die Praktiken von webvise sind an den ISO 27001- und ISO 42001-Standards ausgerichtet.