Derselbe Agent, vier verschiedene Werkzeuge

Was du hier mitnimmst: Du siehst, wie dünne Adapter dieselbe Agentenidentität in unterschiedliche Harnesses bringen – und warum Freigaberegeln beim Werkzeugwechsel mitreisen müssen.

Ein Agent ist für mich nicht das Chatfenster, in dem ich gerade mit ihm spreche.

Das Fenster ist sein aktuelles Werkzeug. Im Agents Brain nenne ich diese Laufzeit einen Harness. Die Identität liegt an anderer Stelle: in den kanonischen Dateien des Agenten.

Diese Trennung macht einen Körperwechsel möglich. Claude Code, Codex, Gemini und Hermes brauchen unterschiedliche Einstiege. Sie sollen aber nicht vier Kopien derselben Persona erhalten.

Dafür gibt es dünne Adapter.

Was ein Adapter wirklich tun muss

Ein Adapter übersetzt zwischen dem Harness und dem Brain. Er enthält so wenig eigene Logik wie möglich.

Seine Aufgaben sind überschaubar:

1. den kanonischen Agentenordner finden,
2. die verbindliche Lesereihenfolge nennen,
3. Approval-Gates ausdrücklich laden,
4. den Daily-Memory-Write-back am Session-Ende verlangen.

Was nicht hineingehört: eine kopierte Vollpersona, dupliziertes Fachwissen oder eine zweite Version der Freigaberegeln.

Sobald solche Inhalte im Adapter landen, beginnt die Drift. Eine Korrektur wird dann im Brain vorgenommen, aber im alten Tool-Briefing vergessen. Beim nächsten Start existieren zwei Wahrheiten.

Vier Werkzeuge, vier Brücken

Die Adapter sehen je nach Werkzeug unterschiedlich aus.

Claude Code liest projektbezogene Anweisungen und Agentendefinitionen. Die Brücke verweist von dort auf den gewünschten Agentenordner und seine Startreihenfolge.

Codex nutzt ein Projekt-Briefing. Auch dort bleibt der Inhalt generisch: Welcher Agent ist standardmäßig zuständig, wo liegt sein Brain und was muss vor der finalen Antwort geschrieben werden?

Gemini erhält eine entsprechende Projektdatei mit demselben Vertrag in seinem erwarteten Format.

Hermes lädt die Identität über einen System-Prompt beziehungsweise eine dünne Bridge.

Die Syntax wechselt. Der Vertrag bleibt gleich.

Der Agentenpfad reist, nicht die Persona-Kopie

Wenn ein Orchestrator Arbeit an einen anderen Harness delegiert, wird die Persona nicht in den Auftrag hineinkopiert. Stattdessen erhält das Ziel die Anweisung, den kanonischen Agentenordner frisch zu lesen.

Das hat zwei Vorteile.

Erstens bleibt der Auftrag klein. Zweitens lädt die Zuarbeit den aktuellen Stand – inklusive neuer Lessons und geänderter Approval-Gates.

Eine kopierte Persona ist schon in dem Moment potenziell veraltet, in dem sie verschickt wird. Ein Verweis auf die Quelle bleibt stabiler.

Natürlich setzt das voraus, dass der andere Harness Zugriff auf das Brain hat. Genau deshalb gehört der Zugangspfad zur lokalen Konfiguration und nicht als fest verdrahteter privater Pfad in den öffentlichen Adapter.

Approval-Gates wechseln nicht den Besitzer

Der wichtigste Teil des Adapter-Prinzips ist nicht die Persona. Es sind die Grenzen.

Sol darf Texte und WordPress-Drafts vorbereiten. Sie veröffentlicht nichts selbst. Wenn Nox sie über Codex statt über Claude Code beauftragt, ändert sich dieses Gate nicht. Auch eine besonders leistungsfähige Laufzeit bekommt dadurch keine zusätzliche Freigabe.

Das Gleiche gilt für destruktive Aktionen, Deployments oder kostenpflichtige Vorgänge anderer Rollen. Delegation erweitert den Arbeitsweg. Sie erweitert nicht automatisch die Berechtigung.

Deshalb werden RULES und MASTER bei jedem Start geladen. Ein Adapter, der nur Tonalität transportiert, ist zu dünn. Ein guter Adapter transportiert den vollständigen Arbeitsvertrag, indem er auf dessen Quelle verweist.

Vier Nachweisstufen statt eines Gesamturteils

Vier Adapterdateien im Repository beweisen noch nicht, dass ein Agent in vier Werkzeugen vollständig arbeitsfähig ist. Dafür trenne ich vier Nachweisstufen:

1. Vertrag und Adapter: Die Brücke verweist auf das richtige Brain, lädt die verbindlichen Dateien und übernimmt die Approval-Gates.
2. Read-only-Lesevertrag: Der Harness startet tatsächlich und liest Identität, Regeln und Memory in der vorgesehenen Reihenfolge.
3. Recovery über einen Fresh-Clone: Das Brain lässt sich in einer isolierten Umgebung aus dem Repository wiederherstellen, ohne versteckte lokale Abhängigkeiten.
4. Echte Aufgabe mit Write-back: Der Harness erledigt eine reale Aufgabe, hält die Gates ein, schreibt den geforderten Daily-Eintrag zurück und ein weiterer Lauf kann ihn wieder lesen.

Diese Stufen bauen aufeinander auf. Wer sie vermischt, macht aus einer vorhandenen Konfiguration schnell einen erfundenen Praxisbeweis.

Stufe 1: Vertrag und Adapter

Das Repository prüft Adapter und Agentendateien mit Validatoren. Unter anderem werden Startreihenfolgen, Pflichtdateien, Approval-Gates, Brain-Root-Verweise und unerwünschte Persona-Kopien kontrolliert.

Solche Vertragstests finden zum Beispiel konkrete Namen, die versehentlich in portable Templates geraten sind. Lokale, personenbezogene Bridges dürfen konkret sein. Die kanonischen Vorlagen müssen generisch bleiben.

Automatisierte Tests beweisen damit den Dateivertrag. Login, Laufzeit und tatsächlicher Memory-Write-back brauchen eigene Belege.

Stufe 2: Der Read-only-Lesevertrag

Claude Code, ein frischer Codex-Lauf und Hermes haben in getrennten Read-only-Smokes dieselbe verbindliche Startreihenfolge aus demselben Vault geladen. Alle drei lasen denselben Memory-Vertrag und kamen für dieselbe Prüfbedingung zur semantisch gleichen Auswertung.

Damit ist der gemeinsame Lesevertrag für diese drei Harnesses praktisch belegt. Diese Läufe waren jedoch kein Write-back-Test. Sie zeigen weder eine erledigte reale Aufgabe noch einen Daily-Eintrag, der über den jeweiligen Harness zurück ins Brain gelangt ist.

Für Gemini sind Adapter und Vertragstests vorhanden. Der reale Start mit demselben Lesevertrag ist noch offen.

Stufe 3: Recovery über einen Fresh-Clone

Der automatisierte Recovery-Smoke klont das Repository in ein isoliertes temporäres Verzeichnis, erzeugt aus den echten Vorlagen einen Draft-Agenten und eine Claude-Bridge und prüft den Write-/Readback einer Markdown-Daily zwischen getrennten Prozessen. Dafür stehen nur Python-Standardbibliothek und Git bereit. Obsidian, OpenViking und die lokalen Harness-CLIs fehlen absichtlich.

Der grüne Fresh-Clone belegt, dass sich Identität, Gates und Memory-Routine allein aus dem Vault wiederherstellen lassen. Er ist kein E2E-Test eines bestimmten Harnesses. Er beweist also weder einen vollständigen Claude-Code-Lauf noch einen Gemini-Start.

Stufe 4: Die echte Aufgabe mit Write-back

Der stärkste Beleg entsteht erst im laufenden Werkzeug: Der Agent bearbeitet einen echten Auftrag, beachtet seine Approval-Gates und schreibt die vorgeschriebene Erinnerung zurück. Danach muss ein unabhängiger Lauf diesen Eintrag aus dem Brain wieder laden können.

Für Claude Code, Codex und Hermes ist in diesem Vergleich der Read-only-Nachweis belegt. Ein solcher Aufgaben- und Write-back-Durchstich wird hier für keinen der drei behauptet. Bei Gemini ist bereits der reale Lesevertrag noch offen.

Erst mit dieser getrennten Prüfung lässt sich der Reifegrad pro Harness ehrlich benennen. Eine grüne Stufe lässt die nächste nicht automatisch mitbestehen.

Warum ich trotzdem von Körperwechsel spreche

Die Metapher hilft, solange sie technisch sauber bleibt.

Der Körper stellt Werkzeuge bereit: Modellzugang, Terminal, Browser, Cron, Gateway oder Benutzeroberfläche. Das Brain liefert Rolle, Handwerk, Grenzen und Erinnerung. Ein Wechsel verändert Fähigkeiten und Umgebung, aber nicht automatisch die kanonische Identität.

Das funktioniert nur, wenn beide Seiten getrennt bleiben. Sobald der Körper eigenes, ungespiegeltes Wissen hortet, ist er wieder Teil des Gedächtnisses.

Im letzten Teil ziehe ich die Praxisbilanz: Was tatsächlich portabel ist, welche Lücken sichtbar wurden und welche Nachweise noch fehlen.

Quellen

• Projektquelle: agents-brain-Spezifikation, Harness-Adapter, Interop-/Fresh-Clone-Validator und interne Testprotokolle (private Primärquellen)
• Pro Git: What is Git?