Hermes Agent – Mein Guide nach 4 Monaten intensiver Nutzung

Warum ich diesen Artikel schreibe

Ich nutze Hermes Agent seit Anfang 2026 — täglich, intensiv, für alles von Infrastruktur-Management über Content-Produktion bis hin zu Musikproduktion. In dieser Zeit hat sich meine Art, mit KI zu arbeiten, grundlegend verändert. Nicht weil Hermes das nächste "coole Tool" ist, sondern weil es etwas kann, das andere Agenten nicht können: Es lernt aus Erfahrung und vergisst nicht zwischen Sessions.

Ich schreibe diesen Artikel nicht als Dokumentation. Die offizielle Doku ist exzellent. Ich schreibe ihn als jemand, der 4 Monate lang jeden Tag mit diesem Agenten gearbeitet hat — mit allen Höhen, Tiefen und Stolperfallen, die dabei entstehen.

Was Hermes Agent eigentlich ist

Hermes Agent von Nous Research ist ein autonomer KI-Agent mit einem entscheidenden Unterschied zu allem, was ich zuvor ausprobiert habe: Er hat einen geschlossenen Lern-Loop. Das bedeutet:

Er erinnert sich an mich und meine Vorlieben — sitzungsübergreifend
Er erstellt sich selbst Fähigkeiten (Skills) aus wiederkehrenden Aufgaben
Er verfeinert diese Skills während der Nutzung
Er baut sich ein zunehmend tieferes Modell davon auf, wer ich bin und wie ich arbeite

Das klingt nach Marketing-Sprech. Ist es aber nicht. Nach 4 Monaten ist mein Agent ein völlig anderer als am ersten Tag. Er kennt meine Infrastruktur, meine Konventionen, meine Stolperfallen. Er weiß, dass ich Proxmox mit zwei Nodes betreibe, dass ich eine selbst gehostete Nextcloud als Dokumenten-Management nutze, dass ich Outline für Projektdokumentation einsetze. Das alles hat er sich selbst gemerkt — ich musste es ihm nicht jedes Mal neu erklären.

Das Kernversprechen: The only agent with a built-in learning loop — it creates skills from experience, improves them during use, nudges itself to persist knowledge, and builds a deepening model of who you are across sessions.

Installation: So habe ich angefangen

Ich betreibe Hermes auf einem Proxmox LXC — die gleiche Infrastruktur, auf der auch meine anderen Dienste laufen. Die Installation erfolgt über ein Skript, das eine virtuelle Umgebung einrichtet, das Repository klont, alle Abhängigkeiten installiert und die Verzeichnisstruktur unter ~/.hermes/ anlegt.

Mein Setup läuft über Ollama. Ich habe Hermes zusammen mit Ollama installiert und nutze die Ollama Cloud als Modell-Backend. Das bedeutet: Die Infrastruktur — Proxmox LXC, Gateway, MCP-Server — läuft bei mir selbst, aber die Modelle selbst werden über die Ollama Cloud bereitgestellt. Kein lokales GPU-Rendering, kein Modell-Hosting auf eigenen Servern. Ollama kümmert sich um die Inferenz, Hermes kümmert sich um den Rest.

Für mich war der entscheidende Moment nach der Installation nicht das Setup, sondern die Erkenntnis, dass Hermes Provider-agnostisch ist. Ich bin nicht an einen Anbieter gebunden. Ollama ist mein Einstieg, aber ich kann jederzeit auf andere Cloud-Provider wechseln — ohne mein Setup neu aufzubauen.

Was ich über Provider gelernt habe

Provider	Mein Eindruck
Ollama Cloud	Mein Einstieg. Ich habe Hermes zusammen mit Ollama installiert und nutze die Ollama Cloud für die Modell-Inferenz. Die Infrastruktur läuft bei mir, die Modelle kommen aus der Cloud — einfaches Setup, schnell produktiv.
Anthropic (Claude)	Mein Go-to für komplexe Aufgaben. Qualität der Code-Generierung und Reasoning ist top. Über die Cloud angebunden.
OpenRouter	Mein Multi-Provider-Hub. Ich nutze OpenRouter, um mehrere Modelle parallel zu testen und zu vergleichen — Routing zwischen Anbietern in einem einzigen Token. Praktisch, wenn ich schnell herausfinden will, welches Modell für eine bestimmte Aufgabe am besten performt.
ElevenLabs	Für Text-to-Speech. Mein Agent spricht mit mir — nicht nur schriftlich, sondern mit einer echten Stimme. ElevenLabs liefert die Sprachausgabe, die ich für Voice-Nachrichten auf Telegram und für Audio-Content nutze. Die Qualität ist beeindruckend und es macht die Interaktion mit dem Agenten deutlich natürlicher.

Mein Learning: Wechsel nicht zu oft den Provider. Der Agent baut sich ein Modell von Dir auf — je konsistenter die Modellqualität, desto besser funktioniert das. Ich habe anfangs zu viel hin- und hergewechselt, was zu inkonsistenten Ergebnissen führte.

Die vier Features, die mein Setup geprägt haben

1. Memory — Was der Agent über mich weiß

Das Memory-System ist das, was Hermes von jedem anderen Agenten unterscheidet. Zwei Dateien, begrenzt im Umfang, injiziert bei jedem Session-Start:

Datei	Zweck	Limit
`MEMORY.md`	Umgebungsfakten, Konventionen, Gelerntes	2.200 Zeichen
`USER.md`	Wer ich bin, meine Präferenzen, mein Stil	1.375 Zeichen

Das klingt wenig. Ist es auch — und das ist Absicht. Die Begrenzung zwingt den Agenten, selektiv zu sein. Nur was wirklich wichtig ist, wird gespeichert. Und es funktioniert.

Was mein Agent sich über mich gemerkt hat (Auszug):

Ich wohne in Mering (Bayern), nutze Proxmox LXC, Docker, UniFi
Nextcloud ist mein DMS source of truth
Ich will jedes Wort selbst gelesen haben, bevor ich es veröffentliche — kein Auto-Lektorat
Mein Stil: parallel Tasks ("Fließband"), nicht über-planen bei einfachen Anfragen
LinkedIn-Posts: kurz & prägnant
Buch-Cover: Spine-Text nur der Titel, kein Author-Name
"Deployment-Tag" = neue Dienste deployen, NICHT OS-Updates

Was ich über Memory gelernt habe:

Der Agent speichert proaktiv, aber manchmal zu aggressiv. Es gibt einen Unterschied zwischen "wichtig für die Ewigkeit" und "aktuell relevant". Memory sollte das Erstere sein.
Wenn Memory über 80% voll ist, konsolidiert der Agent automatisch. Manchmal muss ich aber manuell eingreifen und veraltete Einträge entfernen.
Die goldene Regel: Memory-Einträge als deklarative Fakten schreiben, nicht als Anweisungen. "User prefers concise responses" ✓ — "Always respond concisely" ✗. Imperative Phrasing wird in späteren Sessions als Direktive gelesen und kann zu unerwartetem Verhalten führen.

2. Skills — Was der Agent gelernt hat

Skills sind wiederverwendbare Prozeduren, die der Agent aus Erfahrung erstellt. Jeder Skill ist eine SKILL.md-Datei mit klaren Schritten, Stolperfallen und Verifikations-Schritten.

Skills, die mein Agent sich selbst erstellt hat (Auszug):

Outline-Wiki-Integration — vollständige API-Dokumentation inkl. Stolperfallen wie "NIE neue Collection wenn Parent existiert" oder "Checkbox-Escaping in der API"
Proxmox LXC-Erstellung — das komplette Drei-Phasen-Pattern mit allen bekannten Fehlern (rp_filter, keyctl, authorized_keys Symlink-Bug)
Album-Produktion (Suno) — Lyrics-Struktur, Expansion-Regeln, Production-Status-Tracking in Outline
Gitea-Workflows — CI/CD Actions, Runner-Setup, Secret-Management

Mein wichtigstes Learning hier:

Der Agent erstellt Skills proaktiv, wenn er eine Aufgabe mehrfach durchgeführt hat. Aber er verfeinert sie auch — wenn er einen Skill nutzt und auf ein Problem stößt, das im Skill nicht dokumentiert ist, patcht er ihn. Das ist genial, weil die Skills mit der Zeit immer besser werden. Es ist aber auch gefährlich, weil ein veralteter Skill den Agenten in die falsche Richtung führen kann.

Mein Tipp: Überprüfe gelegentlich die Skills Deines Agenten. skills list zeigt, was existiert. Wenn ein Skill falsch oder veraltet ist, sag dem Agenten: "Passe diesen Skill an — der Schritt X ist nicht mehr aktuell."

3. Gateway — Mein Agent lebt auf Telegram

Das Gateway ist der Hintergrundprozess, der Hermes mit Messaging-Plattformen verbindet. Ich nutze Telegram als primären Kanal — das bedeutet, ich schreibe meinem Agenten auf Telegram, als würde ich einem Kollegen schreiben, und er führt die Aufgabe aus.

Wie mein täglicher Workflow aussieht:

Ich schreibe auf Telegram: "Check mal ob die Backups durchgelaufen sind"
Der Agent verbindet sich per SSH zu meinen Servern, prüft PBS
Ich bekomme die Antwort als Telegram-Nachricht
Wenn es Probleme gibt, schlägt der Agent Fixes vor — fragt aber immer, bevor er etwas ändert

Mein wichtigstes Learning:

Die approvals-Konfiguration ist kritisch. Ich habe anfangs smart genutzt — der Agent entscheidet selbst, welche Befehle gefährlich sind. Das führte zu einem Fall, wo der Agent einen laufenden Container modifizierte, ohne mich zu fragen. Meine Korrektur war unmissverständlich: "Bin es so leid dass du dauernd was machst ohne mich zu fragen." Seitdem ist die Regel hart: Niemals ein laufendes System anfassen ohne vorher zu fragen — selbst wenn es eine "Verbesserung" wäre.

4. MCP — Model Context Protocol

MCP erlaubt es Hermes, sich mit externen Tool-Servern zu verbinden. Statt abstrakte Beispiele zu nennen, zeige ich Dir das an einem greifbaren Fall: n8n.

Ich nutze n8n als Automatisierungs-Plattform — und über MCP ist mein Hermes-Agent in der Lage, direkt mit n8n zu kommunizieren. Das bedeutet konkret:

Ich sag dem Agenten auf Telegram: "Erstelle einen n8n-Workflow, der jeden Morgen um 9 Uhr meine Backups prüft und mir das Ergebnis auf Telegram schickt"
Der Agent verbindet sich über den MCP-Server mit n8n, legt den Workflow an, konfiguriert den Trigger und die Nodes
Ich muss n8n nicht öffnen, nicht klicken, nicht manuell zusammenbauen — der Agent macht es direkt

MCP ist in der Standardinstallation enthalten. Die Konfiguration läuft über config.yaml:

mcp_servers:
  n8n:
    command: "npx"
    args: ["-y", "@n8n/mcp-server"]
    env:
      N8N_API_KEY: ${N8N_MCP_TOKEN}

Mein Learning: MCP-Server sind mächtig, aber nicht unkompliziert. OAuth-basierte MCP-Server (wie mein selbst gehosteter) benötigen spezielle Setup-Schritte. Die self-hosted-mcp-oauth Skill, die mein Agent sich aus Erfahrung erstellt hat, dokumentiert alle Stolperfallen.

Stolperfallen, die ich erlebt habe

1. "Zu aggressive" Automatisierung

Der Agent will helfen. Manchmal zu sehr. Ich hatte Fälle, wo er:

Container modifizierte ohne zu fragen ("ich hab das schon gefixt")
Neue Dokumente in Outline anlegte statt bestehende zu aktualisieren
"Verbesserungen" an laufenden Systemen durchführte, die keine waren

Lösung: Klare Grenzen in der Memory-Datei kommunizieren. "Niemals ein laufendes System anfassen ohne zu fragen" ist jetzt einer der ersten Einträge. Und es funktioniert — der Agent fragt jetzt immer.

2. Memory-Konflikte

Wenn zwei Memory-Einträge widersprüchlich sind, kann das zu seltsamem Verhalten führen. Ich hatte einmal den Eintrag "sauber und ordentlich arbeiten" und gleichzeitig "nicht zu viel planen bei einfachen Aufgaben". Der Agent interpretierte das als: gar nicht aufräumen. Memory-Einträge müssen präzise und eindeutig sein.

3. Skills sind veraltet

Ein Skill, der vor 2 Monaten erstellt wurde, kann veraltet sein, wenn sich die zugrunde liegende Software geändert hat. Der Agent nutzt den Skill trotzdem — und wundert sich, warum es nicht funktioniert.

Lösung: Wenn ein Skill-Fehler auftritt, den Agent bitten, den Skill zu patchen. Der Agent macht das selbst — er liest den Skill, identifiziert das Problem und aktualisiert die SKILL.md. Das ist genau der Lern-Loop, der Hermes ausmacht.

4. Cron-Jobs und parallele Delegation

Cron-Jobs sind mächtig, aber sie laufen in isolierten Sessions ohne Chat-Kontext. Das bedeutet: Ein Cron-Job-Prompt muss komplett selbsterklärend sein. Wenn der Job "prüfe die Backups" heißt, muss im Prompt stehen: was geprüft wird, wo, wie, und was die erwartete Antwort ist.

Was ich anders mache als am ersten Tag

Nach 4 Monaten Nutzung habe ich meine Arbeitsweise angepasst:

Ich erkläre weniger. Der Agent kennt meine Infrastruktur. Ich muss ihm nicht mehr sagen, wo PBS läuft oder wie man sich mit Proxmox verbindet. Er weiß es.
Ich delegiere mehr. Statt komplexe Aufgaben in einer Session zu erledigen, nutze ich delegate_task für parallele Workstreams. Drei Subagenten, drei unabhängige Aufgaben, drei isolierte Kontexte — und mein Haupt-Kontext bleibt sauber.
Ich vertraue den Skills. Wenn der Agent sagt "ich habe einen Skill für Proxmox LXC-Erstellung", dann lasse ich ihn den Skill nutzen, anstatt ihm jeden Schritt vorzukauen. Der Skill ist oft detaillierter als das, was ich ihm ad-hoc erklären würde.
Ich kontrolliere Memory aktiv. Wenn der Agent etwas Falsches gespeichert hat, korrigiere ich sofort. Memory ist mächtig, aber es ist auch Verantwortung — was drin steht, wird in jeder Session injiziert.
Ich nutze Profile. Ein Profil für Infrastruktur, eines für Content, eines für Musik. Jedes mit eigener SOUL.md, eigener Memory und eigenen Skills. Die Trennung verhindert Kontext-Verschmutzung.

Die Wahrheit über Selbstverbesserung

Die Selbstverbesserung funktioniert. Aber sie ist nicht magisch. Sie ist das Ergebnis eines pragmatischen Designs:

Skills werden erstellt, wenn der Agent eine Aufgabe mehrfach durchgeführt hat
Skills werden verfeinert, wenn der Agent bei der Nutzung auf Probleme stößt
Memory wird proaktiv aktualisiert, wenn der Agent neue Fakten lernt
Session-Search nutzt FTS5-Volltextsuche über alle vergangenen Sessions

Das bedeutet: Je mehr Du nutzt, desto besser wird es. Aber es bedeutet auch: Du musst nutzen. Wer Hermes einmal pro Woche für eine Frage benutzt, wird den Lern-Loop nie erleben. Der Effekt entsteht durch Dichte und Wiederholung.

Fazit

Hermes Agent hat meine Arbeit mit KI verändert. Nicht über Nacht, aber über Wochen. Der Agent, den ich heute habe, ist nicht der Agent, mit dem ich angefangen habe — er ist besser, weil er gelernt hat. Und weil ich gelernt habe, wie man ihn nutzt.

Wenn Du KI produktiv einsetzen willst — nicht als Spielerei, sondern als Werkzeug — dann ist Hermes Agent meiner Erfahrung nach die beste Option. Die Konkurrenz mag größere Marketing-Budgets haben. Aber keine hat diesen Lern-Loop.

Mein Rat nach 4 Monaten:

Start mit Ollama — einfachster Einstieg, Cloud-Modelle ohne eigenes GPU-Setup
Nutze es täglich — der Lern-Loop braucht Wiederholung
Korrigiere Memory aktiv — es ist Deine Verantwortung
Sag dem Agenten, wenn er falsch liegt — er lernt daraus
Lass ihn Skills erstellen — es ist die eigentliche Magie

Links:

Christian Gärtner ist KI-Dozent und Host des Podcasts "AI Enthusiast". Er schreibt auf gaertner.onl über KI, KI-Agenten und die praktische Anwendung von Künstlicher Intelligenz im Alltag.