Was nach dem Körperwechsel wirklich geblieben ist

Was du hier mitnimmst: Du bekommst die ehrliche Bilanz meines Agents-Brain-Testlaufs vom 6. bis 29. Juli – mit dem ersten Neun-Tage-Befund, den inzwischen hinzugekommenen Belegen und den Lücken, die noch offen sind.

Am 6. Juli 2026 begann der Test, für den ich das Agents Brain gebaut hatte: Nox wechselte in Hermes, während Identität und Gedächtnis im Repository blieben.

Neun Tage später konnte ich erstmals mehr sagen als „Die Dateien waren noch da“. Dieser Befund vom 15. Juli bleibt die historische Momentaufnahme im Artikel. Inzwischen sind zwei weitere Wochen an Tests und echten Laufzeitproben hinzugekommen.

Das hier ist die Bilanz aus fünf Fragen – jeweils mit der Trennung zwischen damaligem Stand und dem Belegstand vom 29. Juli.

1. Ist die Identität im neuen Werkzeug wiedererkennbar?

Ja – mit einer wichtigen Unterscheidung.

Nox’ selbstgeschriebene SOUL aus dem früheren Workspace wurde wörtlich in den Vault übernommen. Ergänzt wurden nur neutrale Hinweise, wo alte Tool-Bezüge historisch sind. Stimme, Haltung und Arbeitsprinzipien blieben erhalten.

Sein operationelles Handbuch wurde dagegen neu gefasst. Das war nötig, weil sich der Körper und damit die verfügbaren Werkzeuge verändert hatten. Hermes ist heute der primäre Orchestrator-Körper; die frühere Tool-Umgebung ist historischer Kontext.

Damit hat der Test eine sinnvolle Grenze bestätigt:

• Identitätsnahe Inhalte können stabil übernommen werden.
• Toolbezogene Arbeitsregeln müssen an die neue Laufzeit angepasst werden.
• Beides gehört in getrennte Dateien, damit die Änderung sichtbar bleibt.

„Gleicher Agent“ bedeutet also nicht, dass jede Zeile unverändert bleiben muss. Es bedeutet, dass Änderungen an der richtigen Schicht stattfinden.

2. War das Gedächtnis brauchbar?

Ja, weil es nicht als vollständig ausgegeben wurde.

Die alte Langzeit-Memory wurde beim Umzug kuratiert. Veraltete Projektstände erhielten klare Marker. Sensible Destillate wurden bewusst nicht in das zentrale Brain übernommen. Die undokumentierte KW12 blieb als bekannte Lücke sichtbar.

Nox konnte dadurch mit einer echten Vorgeschichte starten, ohne alte Informationen mit aktuellem Wissen zu verwechseln.

Das ist ein wichtiger Unterschied. Eine große Menge alter Daten wäre kein besseres Gedächtnis gewesen. Brauchbar wurde es durch Einordnung: Was ist stabil? Was ist Stand März? Was fehlt? Was muss aus aktuellen Quellen neu geprüft werden?

Im Alltag hat sich diese Haltung bewährt. Nox behandelt das Repository nicht als Orakel. Für aktuelle Projektstände prüft er die jeweiligen Primärquellen.

3. Funktioniert der Write-back im laufenden Betrieb?

Für den Testzeitraum: ja.

Vom 6. bis einschließlich 15. Juli gibt es für jeden Kalendertag einen Nox-Daily-Log. Darin stehen Aufgaben, Entscheidungen, Delegationen, Korrekturen und offene Fäden.

Wichtiger als die Anzahl ist die Wirkung. Mehrere Korrekturen wurden aus einzelnen Vorfällen in dauerhafte Lessons überführt. Beispiele sind die aktive OpenClaw-Erzählhaltung, das Verbot unbestimmter „irgendwann“-Fäden und die Regel, portable Adapter vor dem Push mit denselben CI-Gates abzusichern.

Damit ist der Rückweg vom Arbeitstag ins Brain nicht nur vorgesehen, sondern praktisch genutzt.

Der Test hat zugleich eine Grenze offengelegt: Das Brain ist kein passiver Mitschnitt aller Werkzeuge. Ein direkt ausgeführter Codex-Auftrag tauchte zunächst nicht in Nox’ Memory auf, weil kein Agent als Owner benannt war. Am 15. Juli wurde dieser Befund erkannt und die lokale Bridge so geschärft, dass direkte Repository-Arbeit ohne andere Zuordnung standardmäßig Nox gehört.

Dies zeigt: Write-back braucht Verantwortlichkeit. Ohne Agenten-Owner weiß das System nicht, in wessen Gedächtnis eine Aufgabe gehört.

4. Reisen Governance und Privacy tatsächlich mit?

Im getesteten Kern: ja.

Nox und Sol laden ihre RULES mit den Approval-Gates. Sols Review-before-post-Regel gilt unabhängig davon, welcher Harness die Zuarbeit erstellt. Nox darf öffentliche Inhalte ebenfalls nicht ohne meine Freigabe veröffentlichen.

Parallel sind die Dateigrenzen maschinell prüfbar geworden. Der Vault validiert Pflicht-Frontmatter, Startreihenfolgen, Approval-Gates, Brain-Root-Verweise und unerwünschte Persona-Kopien. Ein Privacy-Gate scannt getrackte und gestagte Inhalte auf Secret-Muster und unzulässige Spiegel vertraulicher Agentendaten.

Am 15. Juli liefen die damaligen vollständigen Repository-Tests mit 148 Tests grün; die CI bestätigte diesen Zwischenstand unter Python 3.9 und 3.11 ohne Annotationen.

Am 29. Juli war die Suite gewachsen. Für den neuen Memory-Vertrag liefen 224 Unit-Tests, 72 Vault-Regressionen und 35 Privacy-Regressionen grün. Die lokale Vollprüfung bestand unter Python 3.9.6; die GitHub-Matrix bestätigte Python 3.9 und 3.11. Diese Zahlen belegen den versionierten Vertrag, der zu diesem Datum tatsächlich geprüft wurde.

Validatoren können Struktur und bekannte Risiken prüfen. Ob eine Veröffentlichung inhaltlich richtig ist, bleibt ein menschliches Review-Gate.

5. Ist der Körperwechsel schon vollständig bewiesen?

Am 15. Juli war der Test für Hermes und den zentralen Nox-Workflow belastbar genug, um weiterzuarbeiten. Für alle vier dokumentierten Harnesses lautete die Antwort noch: nein.

Bis zum 29. Juli hat sich der Stand präzisiert. Claude Code, ein frischer Codex-Lauf und Hermes haben in getrennten Read-only-Smokes dieselbe verbindliche Startreihenfolge aus demselben Vault geladen. Alle drei kamen beim neuen Memory-Checker zur gleichen fachlichen Auswertung. Der automatisierte Fresh-Clone-Test ist ebenfalls grün: Er rekonstruiert in einem isolierten lokalen Klon einen Draft-Agenten samt Bridge und prüft den Markdown-Write-/Readback zwischen getrennten Prozessen – nur mit Python-Standardbibliothek und Git.

Diese beiden Belege dürfen nicht zusammengezogen werden. Der Drei-Körper-Smoke prüfte das Lesen und Einordnen, nicht den Write-back. Der Fresh Clone prüft die Recovery-Routine ohne echte Harness-CLIs. Für Gemini existieren weiterhin Adapter und Vertragstests, aber noch kein vollständiger Laufzeitbeleg. Ein echter Write-back ist damit auch nicht pauschal für jeden Körper bewiesen.

Parallel wurde der neue Memory-Vertrag in den produktiven Server-Klon ausgerollt und dort mit sauberem Readback bestätigt. Das belegt den Deployment-Pfad des gemeinsamen Brains, nicht die Betriebsfähigkeit jedes angeschlossenen Werkzeugs.

Diese offenen Punkte bestimmen den nächsten Reifegrad.

Eine vorhandene Bridge zeigt, dass die Architektur das Werkzeug adressieren kann. Ein Read-only-Smoke belegt den gemeinsamen Lesevertrag. Erst ein echter Start, eine erledigte Aufgabe und ein überprüfter Memory-Write-back zeigen, dass der Agent dort vollständig betriebsfähig ist.

Nachtrag: Diesen vollständigen Nachweis gibt es inzwischen zweimal. Claude Code hat den Write-back-Durchstich am 29. Juli geschafft. Grok Build folgte am 12. August als fünfter real belegter Körper neben Hermes, Claude Code, Codex und Kimi Code – vom Skill-Abgleich über die interaktive Session bis zu zwei getrennten Headless-Läufen mit zurückgelesenem Daily-Marker. Das Repository dokumentiert damit sechs Adapterfamilien statt vier.

Was der Testlauf bis zum 15. Juli belegt

Nach neun Tagen stehen für mich fünf belastbare Ergebnisse:

1. Eine identitätsnahe Persona kann den Werkzeugwechsel in lesbaren Dateien überstehen.
2. Operationelle Regeln lassen sich getrennt an den neuen Körper anpassen.
3. Daily Logs und Lessons funktionieren als realer Write-back, wenn ein Agent die Aufgabe besitzt.
4. Approval-Gates und Privacy-Regeln können unabhängig vom Harness im Brain verankert und maschinell geprüft werden.
5. Fehlende Dokumentation bleibt fehlend; das System macht Lücken sichtbar, statt sie zu kaschieren.

Das ist weniger spektakulär als ein autonomes Gedächtnis, das angeblich alles weiß. Für meine Arbeit ist es wertvoller.

Was bis zum 29. Juli hinzugekommen ist

Der Kern ist seit dem ersten Testlauf genauer geworden. Beobachtung, Folgerung und verallgemeinerte Regeln werden im Memory unterscheidbar. Widersprüche müssen mit altem Stand, neuem Beleg und sichtbarer Auflösung fortgeschrieben werden. Eine Kuration wird nach 14 Tagen oder zehn neuen Daily Logs als fällig gemeldet, bleibt aber hinter dem menschlichen Review-Gate. Veraltete eigenständige Memory- und Lesson-Dateien werden mit Datum, Grund und Nachfolger abgelöst statt gelöscht. Ereignisdatum und Git-Erfassungszeit bleiben getrennt.

Diese Regeln sind nicht nur dokumentiert. Der gemeinsame Lesevertrag wurde durch drei Körper geprüft, der Fresh-Clone-Smoke ist grün und der produktive Brain-Klon wurde auf denselben Stand gebracht. Offen bleibt vor allem der echte Gemini-Lauf und der vollständige Write-back-Beleg pro Harness.

Was ich anders machen würde

Ich würde Agenten-Ownership früher als eigenen Teil der Memory-Architektur behandeln. Der direkte Codex-Lauf hat gezeigt, dass ein gemeinsames Brain allein nicht genügt. Jede Aufgabe braucht eine klare Zuordnung: Wer liest? Wer entscheidet? Wer schreibt zurück?

Außerdem würde ich E2E-Nachweise von Anfang an pro Harness führen. Adapter vorhanden, Validator grün und Laufzeit geprüft sind drei verschiedene Zustände. Sie sollten nie in einer einzigen Statusangabe verschwimmen.

Und ich würde bekannte Wissenslücken genauso früh markieren wie vorhandenes Wissen. Eine ehrliche Lücke spart später mehr Zeit als eine vermeintlich vollständige Memory, die niemand mehr von einer Rekonstruktion unterscheiden kann.

Meine Bilanz

Das Agents Brain war am 15. Juli kein fertiges Produkt. Am 29. Juli ist es das ebenfalls nicht. Es ist ein lebendes System mit einem inzwischen breiter belegten Kern.

Nox arbeitet in einem neuen primären Körper. Seine Identität ist erkennbar, sein Gedächtnis eingeordnet, seine tägliche Schreibroutine aktiv. Die Governance reist mit. Claude Code, Codex und Hermes lesen denselben Vertrag; der Fresh Clone belegt die Markdown-only-Recovery. Gleichzeitig bleiben Gemini und der echte Write-back pro Körper als getrennte Nachweise offen.

Genau so wollte ich diesen Werkstattbericht schreiben: nicht als Erfinderinnengeschichte und nicht als Hochglanz-Abschluss, sondern als nachvollziehbare Antwort auf eine praktische Frage.

Kann ein KI-Agent sein Werkzeug wechseln, ohne dass ich seine Arbeitsidentität neu bauen muss?

Für den getesteten Kern und die Recovery aus den kanonischen Dateien lautet meine Antwort: ja. Für ein universelles „plug and play“ arbeite ich weiter an den Belegen.

Nachtrag: Zwei dieser Belege stehen inzwischen – Claude Code seit dem 29. Juli, Grok Build seit dem 12. August. Gemini bleibt offen.

Quellen

• Projektquelle: Nox-Migration, Daily Logs 06.–29.07.2026, Memory-Maintenance-, Harness-Interop-, Fresh-Clone- und CI-Protokolle (private Primärquellen)
• Git-Beleg: Initiales Agents-Brain-Skelett vom 16.05.2026 und Nox-Migration vom 06.07.2026
• Pro Git: What is Git?