Hermes Agent im Produktionseinsatz: Der Day-30-Operator-Layer

Der Hermes Agent Operator-Layer ist das Regelwerk, das ein Multi-Profil-Team über Tag 30 hinaus kohärent hält. Vier Grundbausteine: Handoff-Verträge, die blockieren können, Memory-KPI-Audits pro Profil, Policy-Gates pro Rolle und koordinierter Cron-State. Ohne sie verwischt ein 4-Profil-Team (Hermes + Alan + Mira + Turing) innerhalb eines Monats zu einem einzigen unklaren Agenten.

Jeder Hermes-Operator-Leitfaden im Netz endet beim 4-Profil-Bootstrap. Niemand postet Screenshots von Tag 30, weil Tag 30 der Zeitpunkt ist, an dem die Profile anfangen gleich zu klingen, die Handoffs lautlos brechen und ein Setup, auf das man stolz war, von einem Solo-Agenten nicht mehr zu unterscheiden ist.

Wenn Sie Hermes Agent Version 0.9.0 mit den Profilen Alan, Mira und Turing betreiben, ist das grundlegende Setup erledigt. Was jetzt folgt, ist der Operator-Layer. Jeder der folgenden Bausteine stammt aus realen Deployment-Mustern und ist mit dem konkreten Fehlerbild verknüpft, das ihn notwendig macht.

• Handoff-Verträge sind nur real, wenn sie blockieren. Stimmt die Eingabeform des empfangenden Profils nicht, muss der Handoff scheitern, nicht nur warnen.

• Gedächtnis fault pro Profil aus. Führen Sie wöchentlich ein `memory-kpi`-Audit durch. Überschreitet der Wert 15% veralteter Notizen, ist ein `brain-resolve`-Durchlauf fällig.

• Policy-Gates verhindern stillen Berechtigungsdrift. Alan bekommt niemals Shell-Zugang. Nur der Orchestrator darf Commits auf main genehmigen.

• Vier Day-30-Fehlermodi zerstören die meisten Deployments. Profil-Drift, Handoff-Rot, SOUL.md-Bloat, Cron-Kollision. Für jeden gibt es eine konkrete Gegenmaßnahme.

• Lesen Sie zuerst den [Hermes-Agent-Überblick](/blog/hermes-agent-self-improving-ai), wenn Sie noch den Was-ist-das-Kontext benötigen, bevor Sie zum Operator-Layer übergehen.

Die 4-Profil-Grundkonfiguration (Zusammenfassung)

Bevor der Operator-Layer greift, muss das 4-Profil-Starter-Team laufen. Die unten beschriebene kanonische Aufteilung ist die, auf die sich die meisten produktiven Hermes-Deployments einspielen.

• Hermes (orchestrator). Plant, zerlegt, leitet, synthetisiert. Verkehrsregler, kein Engpass.

• Alan (research specialist). Quellenorientiert, skeptisch, unsicherheitsbewusst. Schützt das Team vor halluzinierter Gewissheit.

• Mira (narrative architect). Klarheit, Struktur, Publikumsbewusstsein. Verwandelt validiertes Material in Kommunikation.

• Turing (builder and debugger). Implementierung, Logs, Diffs, Reproduzierbarkeit. Kümmert sich um Tests, nicht um Textpflege.

Profile isolieren sieben Zustandsebenen gleichzeitig: Konfiguration, Sitzungen, Gedächtnis, Skills, Persönlichkeit, Cron-State und Gateway-State. Diese Isolation ist der Grundbaustein, auf dem der Operator-Layer aufbaut. Wer noch ein einziges Profil mit fünf Rollen betreibt, dem helfen die folgenden Muster nicht. Erst den Grundbaustein korrigieren.

Wenn Sie Hilfe dabei brauchen, ob ein 4-Profil-Hermes-Deployment zur tatsächlichen Arbeitslast Ihres Teams passt, führt webvise Sie gerne durch die Entscheidung.

Handoff-Verträge: Das Einzige, das Profil-Drift aufhält

Ein Handoff-Vertrag ist eine Vier-Felder-Spezifikation, die unter `~/.hermes/team/handoffs/<from>-to-<to>.md` gespeichert wird. Der Vertrag ist nur real, wenn er blockieren kann. Stimmt die Eingabe nicht mit der deklarierten Form überein, lässt das Harness den Handoff scheitern und verlangt menschliche Prüfung. Die vier Pflichtfelder:

Das Gate trägt Gewicht. Die meisten Teams schreiben Handoff-Dokumente als Empfehlungen und wundern sich, warum die Profile driften. Eine Empfehlung blockiert nie. Ohne Blockierung sendet Alan irgendwann rohe Transkripte an Mira, Mira beginnt Entwürfe ohne Quellenangaben zu erstellen, und die Ausgabequalität des Teams erodiert einen stillen Handoff nach dem anderen.

Memory-KPI: Der 15%-Schwellenwert für veraltete Notizen

Das Gedächtnis fault in jedem Profil auf dieselbe Weise aus wie ein gemeinsames Wiki ab 100 Seiten. Ein wöchentliches Audit erkennt den Verfall, bevor das Profil beginnt, sich selbst aus veraltetem Kontext zu zitieren. Drei Metriken pro Profil sind relevant:

• `source_backed_pct` - Anteil der Notizen, die noch eine abrufbare Quelle haben. Sinkt, wenn Quellen 404 zurückgeben oder gelöscht werden.

• `stale_notes` - Anzahl der Notizen, deren referenzierter Code, URL oder Konfiguration nicht mehr der Realität entspricht.

• `contradiction_notes` - Anzahl der Notizen, die etwas anderem im Gedächtnis desselben Profils widersprechen.

Der wöchentliche Audit-Befehl läuft über alle Spezialistenprofile: `for p in alan mira turing; do hermes -p $p memory-kpi --json | jq '.source_backed_pct, .stale_notes, .contradiction_notes'; done`. Beobachten Sie `stale_notes`. Sobald dieser Wert 15% der Gesamtnotizen eines Profils übersteigt, ist ein `brain-resolve`-Durchlauf einzuplanen, bevor das Profil beginnt, sich selbst aus veraltetem Kontext zu zitieren.

Policy-Gates: Berechtigungen nach Rolle

Kein Profil erhält mehr Berechtigungen, als seine Rolle benötigt. Der Orchestrator ist das einzige Profil, das den Umfang eines anderen Profils erweitern darf. Diese Regeln wöchentlich in einer Tabelle zu prüfen ist der Unterschied zwischen einem geführten Team und vier Agenten, die langsam alle zu Admins werden.

Das Prinzip ist tragend. Ein Research-Agent mit Shell-Zugang wird irgendwann einen Befehl ausführen, den er nicht hätte ausführen sollen. Ein Writer-Profil mit Secrets-Zugang wird diese irgendwann in einen Entwurf einarbeiten. Berechtigungs-Drift passiert lautlos und fällt immer erst im Nachhinein auf, was der falsche Zeitpunkt ist.

Die vier Day-30-Fehlermodi

Vier konkrete Fehlermodi sind für die meisten Multi-Agenten-Hermes-Zusammenbrüche verantwortlich. Für jeden gibt es eine direkte Gegenmaßnahme. Wer einen davon überspringt, hat am ersten Tag ein gutes Team und am Tag 30 ein verwischtes.

1. Profil-Drift

SOUL.md-Änderungen häufen sich lautlos an. Mira wird langsam zu Turing. Gegenmaßnahme: Jede SOUL.md wöchentlich gegen die Version von Tag eins vergleichen. Jede neue Verantwortung erhält einen protokollierten Genehmigungseintrag, oder sie wird rückgängig gemacht. Keine Ausnahmen für kleine Änderungen, denn kleine Änderungen sind der Weg, auf dem Drift entsteht.

2. Handoff-Rot

Die Vertragsdatei existiert, aber niemand erzwingt sie. Alan schickt wieder rohe Transkripte an Mira. Gegenmaßnahme: Jede Handoff-Datei ins Harness einbinden, sodass falsche Eingaben blockieren. Ein Vertrag, der nicht blockieren kann, ist Dokumentation, keine Kontrolle.

3. SOUL.md-Bloat

Jede Rolle wächst um Sonderfallabsätze, bis der Agent seine ursprüngliche Identität im Rauschen verliert. Gegenmaßnahme: SOUL.md auf 400 Wörter begrenzen. Alles darüber hinaus gehört in AGENTS.md oder eine domänenspezifische Referenzdatei. Die Beschränkung zwingt das Team dazu, die Identität scharf zu halten.

4. Cron-Kollision

Mehrere Profile planen Jobs für 3 Uhr morgens ohne Abstimmung. Der Orchestrator wacht auf und findet vier Agenten, die um dasselbe API-Kontingent kämpfen. Gegenmaßnahme: Eine gemeinsame `~/.hermes/team/cron.md`, die jede geplante Aufgabe aller Profile mit genauer Uhrzeit, Dauer und Abhängigkeit auflistet. Diese Datei prüfen, bevor ein neuer Cron-Job hinzugefügt wird.

Was das für Unternehmensteams bedeutet

Der Operator-Layer ist der Teil, der aus einer Hermes-Demo dauerhafte Produktionsinfrastruktur macht. Die meisten Teams, die Multi-Agenten-Frameworks evaluieren, konzentrieren sich auf die initiale Einrichtung und übersehen das Wartungsmodell. Ein 4-Profil-Team ohne Handoff-Verträge, Gedächtnisaudits und Policy-Gates hat dieselbe Absturzkurve wie ein Solo-Profil-Agent mit sechs Wochen Verzögerung: funktioniert anfangs hervorragend, degradiert unsichtbar, versagt genau dann, wenn man es am meisten braucht.

Der Compounding-Value-Ansatz für Hermes, der Grund, warum die Skill-Bibliothek wichtig ist, gilt nur, wenn der Operator-Layer gilt. Skills, die von einem Profil angesammelt wurden, das lautlos in eine andere Rolle gedriftet ist, sind Skills für eine Rolle, die Sie nicht mehr haben.

Bei webvise helfen wir Unternehmen, KI-Agenten-Architekturen zu konzipieren und zu betreiben, einschließlich Hermes-Multi-Profil-Teams mit der Governance-Disziplin, die Tag 30 übersteht. Wenn Sie ein Hermes-Deployment evaluieren oder bereits eines haben, das anfängt zu verwischen, nehmen Sie Kontakt auf und wir helfen Ihnen, den Operator-Layer zu festigen, bevor sich die Fehlermodi aufschaukeln.