Ein Agent, der bleibt: Der Hermes-Agent und lokale KI-Modelle

Die meisten agentischen Systeme, die in den letzten zwei Jahren auf den Schreibtischen gelandet sind, haben eine Eigenschaft gemeinsam: Sie vergessen.

Man stellt eine Frage, bekommt eine ordentliche Antwort, schließt das Fenster — und beim nächsten Mal beginnt das Gespräch wieder bei null. Der Assistent kennt das Projekt nicht mehr, nicht den Kunden, nicht den Weg, auf dem ein Problem letzte Woche gelöst wurde. Für einen Chatbot ist das verzeihlich. Für etwas, das man ernsthaft in einen Betriebsablauf einbauen will, ist es ein Konstruktionsfehler.

Der Hermes-Agent von Nous Research, seit Februar 2026 unter MIT-Lizenz öffentlich, setzt genau hier an. Und es lohnt, ihn anzusehen — nicht weil er ein weiteres Werkzeug im überfüllten Regal ist, sondern weil er eine andere Frage stellt als die meisten: Was passiert, wenn ein Agent nicht an einen Tab gebunden ist, sondern auf einem Server lebt und dort bleibt?

Was Hermes anders macht

Der Kern ist eine geschlossene Lernschleife. Hermes legt nach komplexeren Aufgaben selbst sogenannte Skills an — kleine, wiederverwendbare Arbeitsanweisungen, die er beim nächsten ähnlichen Fall wieder hervorholt und im Gebrauch verbessert. Er durchsucht seine eigenen früheren Gespräche, baut über die Zeit ein Bild davon auf, woran man arbeitet und wie man arbeitet. Das ist kein Marketing-Versprechen, das ist die Architektur: ein Agent, der den Umstand, dass er auf einer dauerhaft laufenden Maschine sitzt, tatsächlich nutzt.

Dazu kommt eine praktische Eigenheit, die im Mittelstand mehr zählt, als man zunächst denkt. Hermes ist nicht an ein Terminal gebunden. Über einen Gateway-Prozess erreicht man denselben Agenten — mit demselben Gedächtnis — aus Telegram, Discord, Slack, WhatsApp, Signal oder per E-Mail. Der Server arbeitet, man schreibt ihm vom Telefon aus eine Nachricht, er antwortet dort weiter, wo das letzte Gespräch aufgehört hat. Ein eingebauter Zeitplaner (intern ein Cron-System) übernimmt wiederkehrende Aufgaben: der tägliche Bericht um sieben, das nächtliche Backup, das wöchentliche Audit — in normaler Sprache beschrieben, danach unbeaufsichtigt laufend.

Für größere Arbeit kann Hermes abgegrenzte Subagenten abspalten: kurzlebige, isolierte Arbeiter mit eigenem Kontext und eigenem Werkzeugkasten, die parallel laufen, ohne sich gegenseitig zu stören. Seit Mitte Juni geschieht das asynchron — delegierte Arbeit blockiert den Hauptchat nicht mehr.

Hermes Desktop

Nous Research hat im Juni Hermes Desktop veröffentlicht, die den Einsatz auch für technisch nicht versierte Anwender unter Windows, macOS und Linux möglich macht.

Der eigentliche Punkt: das Modell

Hier wird es für uns interessant. Hermes ist bewusst modell-agnostisch gebaut. Man kann ihn an die großen kommerziellen Anbieter hängen, an OpenRouter mit seinen zweihundert Modellen, an das hauseigene Nous Portal. Mit einem einzigen Befehl — hermes model — wechselt man, ohne eine Zeile Code anzufassen.

Aber das ist nicht der Grund, warum dieser Agent für einen Betrieb taugt, der seine Daten nicht aus der Hand geben will. Der Grund ist: Man kann ihn an ein Modell hängen, das auf der eigenen Maschine läuft. Und Hermes ist ausdrücklich für diesen Fall gebaut.

Das ist nicht selbstverständlich. Viele Agenten-Frameworks setzen stillschweigend voraus, dass im Hintergrund ein sehr großes, sehr teures Modell aus der Cloud antwortet. Sobald man sie auf ein lokales Modell mittlerer Größe stellt, fangen sie an zu stolpern — der Kontext wird zu lang, die Werkzeugaufrufe werden unzuverlässig, und man verbringt mehr Zeit mit Debugging als mit Arbeit. Hermes geht den umgekehrten Weg. Die isolierten Subagenten halten den Kontext klein und fokussiert, was kleineren Modellen entgegenkommt. Die mitgelieferten Skills und Werkzeuge sind durchgetestet. Das Ergebnis, so berichten Entwickler in Vergleichen mit identischen Modellen über verschiedene Frameworks hinweg, ist spürbar zuverlässiger — nicht weil das Modell besser wäre, sondern weil die Orchestrierung drumherum stimmt.

Konkret heißt das: Ein dichtes Modell der 30-Milliarden-Parameter-Klasse — etwa aus der aktuellen Qwen-3.6-Reihe — läuft bei Hermes brauchbar, ohne dass man dauernd nachjustieren muss. Das Qwen-3.6-35B kommt mit rund 20 Gigabyte Speicher aus und liegt dabei auf dem Niveau von Modellen, die früher 70 Gigabyte und mehr verlangt hätten. Das ist die Größenordnung, die auf einer einzelnen ordentlichen GPU im eigenen Haus läuft — auf einer NVIDIA-RTX-Workstation, auf einem DGX-Spark-Gerät, oder, wenn man die Hardware nicht selbst stellen will, auf einem gemieteten GPU-Server in einem deutschen Rechenzentrum.

Was das für Sie bedeutet

Wir haben in den letzten Jahren immer wieder denselben Vorbehalt gehört, und er ist berechtigt: Wo bleiben unsere Daten? Ein Steuerberater, ein Maschinenbauer, eine Arztpraxis — die können nicht einfach ihre Mandanten-, Konstruktions- oder Patientendaten durch eine fremde Cloud schicken, weil ein Assistent gerade praktisch ist. Die meisten KI-Angebote beantworten diese Frage mit einem Achselzucken und einem Verweis auf Allgemeine Geschäftsbedingungen.

Hermes erlaubt eine ehrlichere Antwort. Der Agent läuft auf einer Maschine, die man kontrolliert. Das Modell läuft auf derselben Maschine. Das Gedächtnis — die Skills, die Gesprächsverläufe, das aufgebaute Wissen über den Betrieb — bleibt lokal; die Projektbeschreibung spricht von keiner Telemetrie, keinem Tracking, keiner Cloud-Bindung. Wer will, hängt zusätzlich kommerzielle Modelle für unkritische Aufgaben an und behält die sensiblen Vorgänge auf dem lokalen Modell. Diese Trennung ist mit einem Befehl gemacht, nicht mit einem Beratungsprojekt.

Das ist die eigentliche Verschiebung. Souveränität war bisher meist ein Versprechen auf einer Folie. Hier wird sie zu einer Frage der Hardware-Auswahl und der Konfiguration — also zu etwas, das man tatsächlich anfassen und überprüfen kann.

Wo die Grenzen liegen

Es wäre unredlich, das ohne Einschränkung stehen zu lassen. Ein lokal laufender Agent mit lokalem Modell ist kein Selbstläufer. Die GPU kostet Geld, ob gekauft oder gemietet. Ein 30-Milliarden-Modell ist gut, aber es ist nicht das größte kommerzielle Modell — für manche Aufgaben merkt man den Unterschied, für viele betriebliche Routinen nicht. Und ein Agent, der dauerhaft läuft, Werkzeuge bedient und Befehle ausführt, will sauber eingehegt werden; Hermes bringt dafür Mechanismen mit (Befehlsfreigaben, Container-Isolation), aber jemand im Betrieb muss verstehen, was da läuft. Wer einen Agenten ungeprüft auf einen Produktivserver lässt, hat ein anderes Problem als ein fehlendes Werkzeug.

Das alles ändert nichts am Befund. Zum ersten Mal steht ein ausgereiftes, offenes Agenten-Gerüst zur Verfügung, das nicht stillschweigend voraussetzt, dass man seine Daten in eine fremde Cloud schiebt. Für einen Betrieb, der ernsthaft über KI nachdenkt und dabei die Kontrolle behalten will, ist das kein kleiner Unterschied. Es ist der Unterschied zwischen einem Werkzeug, das man mietet, und einem, das einem gehört.

---

Weiterlesen

• n8n - ein Werkzeug wie eine Tabelle mit Kabeln — die Abgrenzung zwischen selbststeuernder Agenten-Schleife und fest verdrahtetem Workflow
• Lokale Modelle sind kein Datenschutz-Kompromiss — wie weit offene Gewichte inzwischen an die kommerziellen Modelle heranreichen
• Sakana Fugu: Ein Modell, das andere Modelle dirigiert — der Gegenentwurf: Orchestrierung als zugekaufter Dienst statt auf eigener Hardware