Du führst hermes update aus, startest den Agenten neu und fragst ihn, was gestern bei dem Refactoring herausgekommen ist. Er hält kurz inne und antwortet dann, dass er dazu nichts gespeichert hat. Du öffnest config.yaml: memory.provider: honcho steht noch da, der ganze memory.honcho-Block ist unversehrt. Es fehlt nur der Code — der Provider ist aus dem Core-Repository ausgezogen, und dein Upgrade hat nur die Core-Hälfte ersetzt.

Verloren gegangen ist dabei nichts. Du siehst hier die unangenehmste Art von Fehler: eine Konfiguration, die auf eine Implementierung zeigt, die es nicht mehr gibt. PR #114569, am 18. September 2026 in main gemergt, ist genau für diesen Zustand gebaut: Wenn Hermes merkt, dass der konfigurierte Memory-Provider fehlt, installiert es ihn aus dem Plugin-Katalog nach — auf dem geprüften Pin. Im Folgenden: wie Hermes entscheidet, über welchen Pfad die Installation läuft, was passiert, wenn sie nicht möglich ist, und ob du selbst etwas tun musst.

Was gleich bleibt: Name, Konfiguration, Daten

Das Beruhigende an dieser Migration ist, dass nur der Code wandert. Wenn aus einem mitgelieferten plugins/memory/<name> ein eigenständiges Katalog-Plugin wird:

• der Provider-Name bleibt (memory.provider: honcho funktioniert weiter);
• der Konfigurationsabschnitt bleibt (jeder Schlüssel unter memory.<name> bleibt unangetastet);
• das Datenverzeichnis bleibt (alles, woran sich dein Agent erinnert hat, liegt noch dort, wo es lag);
• die Tool-Namen bleiben (die Anweisungen in seinem Memory zur Benutzung des Memory müssen nicht neu gelernt werden).

Die einzige Änderung: Der Code liegt jetzt unter HERMES_HOME/plugins/<name>. Theoretisch hätte der für Nutzer sichtbare Effekt eine unauffällige Neuinstallation sein sollen. Dieser PR sorgt dafür, dass die Theorie stimmt.

Zwei Hooks: hermes update und der Agent-Init

Das neue Modul hermes_cli/memory_provider_migration.py stellt einen einzigen Einstiegspunkt bereit: migrate_home(). Es tut drei Dinge: memory.provider für dieses Home lesen, prüfen, ob der Name noch irgendwo auflöst, wo Hermes nachschaut (das mitgelieferte Verzeichnis, die User-Plugins dieses Homes, ein Entry Point), und — nur wenn er nirgends auflöst — nach einem Katalogeintrag mit demselben Namen suchen. Alle drei Bedingungen müssen zusammenpassen, bevor etwas installiert wird.

Zwei verschiedene Aufrufstellen decken zwei verschiedene Upgrade-Gewohnheiten ab:

• hermes update führt es für jedes Profile-Home aus, das dieselbe Virtualenv nutzt. Das ist der natürliche Ort: Das Update baut ohnehin Abhängigkeiten neu, und Plugin-Abhängigkeiten werden unter den Core-Pins erneut angewendet.
• Der Agent-Init führt es aus, wenn load_memory_provider None zurückgibt — also wenn der Provider gar nicht geladen werden kann —, einmal pro Prozess und pro Name. Diesen Hook gibt es für Desktop-Nutzer, die über die App aktualisieren und hermes update nie von Hand aufrufen.

Die Installation selbst läuft über den normalen Plugin-Installationspfad: den geprüften Pin des Katalogeintrags, die Kill-List, die Abhängigkeits-Constraints und das Aktivieren bei der Installation. Nichts bekommt eine Abkürzung, nur weil der Vorgang automatisch abläuft, und eine selbst konfigurierte Quelle wird nie ersetzt.

Ein Schalter ist hier wichtig. Weil dieser Schritt Code installiert, respektiert er security.allow_lazy_installs (standardmäßig an). Wenn du das aus Sicherheitsgründen abgeschaltet hast, findet die automatische Migration nicht statt — und das Log sagt das auch, statt das Memory still und leise sterben zu lassen.

Wenn die Installation nicht möglich ist: ein echter Befehl statt stiller Amnesie

Die beste Engineering-Gewohnheit in dieser Änderung: Ein Fehlschlag ist sichtbar und sofort handhabbar. Drei Pfade, drei Ausgaben:

Situation	Verhalten
Der Katalog hat keinen Eintrag für diesen Provider	Eine Warnung, die den genauen auszuführenden Befehl hermes plugins install <source> nennt oder einen anderen memory.provider vorschlägt
Der Katalog hat ihn, aber die Installation schlägt fehl (Netzwerk, uv, Kill-List)	Der Fehlertext des Installers selbst, plus derselbe Einzeiler
security.allow_lazy_installs ist aus	Eine Log-Zeile, die feststellt, dass die Konfiguration die automatische Installation verhindert hat

Vorher war dieser Hinweis eine Zeile auf DEBUG-Level und sonst nichts; deshalb war das sichtbare Symptom schlicht „der Agent erinnert sich plötzlich an nichts“. Außerdem gilt innerhalb der Funktion bewusst eine zurückhaltende Regel: Sie wirft nie eine Exception. Der Kommentar sagt es klar — ein ausgefallenes Memory darf nicht das Update oder den Agenten mitreißen.

Eine kleine Korrektur an der Installationssyntax, auf der die Migration aufsetzt

Derselbe PR sorgt dafür, dass hermes plugins install owner/repo#subdir korrekt geparst wird. Vorher wurde das # an die Clone-URL geklebt, sodass jedes Plugin, das in einem Unterverzeichnis seines Haupt-Repos liegt, auf diesem Weg nicht installierbar war.

Diese Syntax ist keine Theorie. Honcho liefert sein Plugin innerhalb des Haupt-Repositories aus, seine Quelle nach der Migration ist also plastic-labs/honcho#hermes-plugin-honcho; bei supermemory lautet sie supermemoryai/hermes-supermemory. Der PR hat den ganzen Pfad an einer echten Installation überprüft: mit aus einem Probe-Checkout gelöschten mitgelieferten honcho- und supermemory-Verzeichnissen, gesetztem memory.provider: honcho und einem echten AIAgent() hat der Agent-Init plugins/honcho aus dem Repo des Maintainers installiert, die Abhängigkeiten (honcho-ai, httpx) innerhalb der Core-Pins aufgelöst und das Plugin geladen. Das Desktop-Konfigurationspanel für honcho zeigte weiterhin seine 33 Felder, die hermes honcho CLI wurde weiterhin gefunden, und ein zweiter Start war ein No-op.

Was jetzt zu tun ist: ein Fünf-Minuten-Check

Dieser PR ist Vorarbeit — von sich aus entfernt er nichts aus dem Core. Die Richtung ist aber öffentlich: Die eingebauten Memory-Provider gehen in die Repos ihrer Maintainer und in den Katalog (der PR erwähnt die Absprache mit den Maintainern von Hindsight, Honcho und Supermemory). Es lohnt sich also zu wissen, wo du stehst:

1. Schau nach, welchen Provider du nutzt: hermes config get memory.provider. Ist es einer der mitgelieferten (honcho, supermemory, mem0 und Verwandte), notier dir den Namen.
2. Prüfe, ob er aktuell mitgeliefert oder ein eigenständiges Plugin ist: hermes plugins list. Wenn er nach einem künftigen Upgrade aus dem Repo des Maintainers installiert ist, ist das erwartet und kein Problem.
3. Sollte dich irgendein Upgrade einmal mit einem Agenten ohne Gedächtnis zurücklassen, führe zuerst die Zeile hermes plugins install aus dem Log aus. Wenn das Memory wieder da ist, prüfe mit hermes doctor den Zustand von State-Datenbank und WAL — die Diagnose zum großen WAL aus dem Live-Writer-Leitfaden ist der richtige Einstieg.

Wenn du zuerst den größeren Zusammenhang willst: Der Plugin-Katalog-Leitfaden und die hermes plugins-Referenz erklären, wie Katalogeinträge geprüft und installiert werden. Und wenn du Honcho für Session- und Workspace-Routing verwendest, funktionieren die Einstellungen aus diesem Routing-Leitfaden nach der Migration unverändert weiter.

Release-Status

Diese Commits wurden am 18. September 2026 in main gemergt, und der neueste Tag ist v0.21.3 (Tag-Name v2026.9.14, veröffentlicht am 14. September), die Migrations-Hooks sind also noch in keinem getaggten Release. Git-Installationen, die hermes update ausführen, haben sie bereits; Docker-Image- und Cloud-Nutzer bekommen sie mit dem nächsten Tag. Prüfe, wo du stehst:

hermes --version
hermes update

Zum Kontext: Die Release-Seite zu v0.21.3 merkt an, dass die vollständigen kuratierten Notes zu allem seit v0.21.0 mit v0.22.0 erscheinen — der Umzug der Memory-Provider dürfte dort einer der lesenswerten Abschnitte sein.

Die Lehre

Interessant ist nicht die Auto-Installation, sondern die Fehlerklasse, die sie sichtbar macht: Wenn eine Konfiguration auf eine Implementierung verweist, die woandershin gezogen ist, sieht der Nutzer keinen Fehler — er sieht eine Fähigkeit, die still verschwindet. Drei Gewohnheiten lohnt es sich, aus dem Fix zu übernehmen: „die Implementierung fehlt“ als eigenen, erkennenswerten Zustand zu behandeln, die automatische Reparatur über den bereits geprüften Pfad statt über eine Abkürzung laufen zu lassen und — wenn Reparatur unmöglich ist — einen Befehl auszugeben, den man tatsächlich ausführen kann; und das aus Code, der garantiert niemals das Upgrade oder den Agenten mitreißt.