--- title: Meine KI-Agenten gehören nicht ihrem Werkzeug — isla Studio url: https://isla-stud.io/sv/ki-b2b/derselbe-agent-vier-werkzeuge/ date: 2026-07-29 --- # Meine KI-Agenten gehören nicht ihrem Werkzeug Was du hier mitnimmst: Warum die Identität meiner KI-Agenten in eigenen Dateien liegt statt im jeweiligen Werkzeug, wie sechs verschiedene Programme trotzdem dasselbe Team laden – und woran ich messe, was davon produktiv funktioniert. Mein Agents Brain entstand ursprünglich aus der Problemstellung, dass mein KI-Team in weiten Teilen in einem einzigen Tool (Harness) festhing: die laufende Orchestrierung, Kanäle, eingespielte Automatisierungen. Behalten konnte ich die Markdown-Dateien meiner Agenten – alles andere musste ich neu aufbauen. Seitdem baue ich so, dass mir das nicht noch einmal passiert. Wer meine Agenten sind, was sie dürfen und was sie gelernt haben, steht in Dateien, die erstens mir gehören und zweitens deren Änderungen ich nachvollziehen kann. Das Programm, in dem ein Agent gerade läuft, ist dagegen austauschbar – Fachleute nennen diese Laufzeit-Umgebung einen Harness, ich sage meist einfach: sein aktueller Körper. Ein Agent ist eben nicht das Chatfenster, in dem ich gerade mit ihm spreche. Das Fenster ist nur der Ort, an dem er heute arbeitet. Hier liest du, wie derselbe Agent in verschiedenen Werkzeugen arbeiten kann, ohne dass ich ihn jedes Mal neu erfinden muss. Was mir diese Trennung erspart Das klingt nach einem Architektur-Detail. Für mich ist es aber eine Geschäftsentscheidung. Wie schnell ein Werkzeug mehr Pflege verlangt, als es Arbeit abnimmt, habe ich bei OpenClaw im Januar und Februar 2026 erlebt. In so einem Moment will ich wechseln können, ohne mein Team zu verlieren – im Einkauf heißt das Problem, das ich damit vermeide, Vendor-Lock-in. Meine Agenten hängen an keinem einzelnen Anbieter, weil nichts Wesentliches nur in dessen Produkt existiert. Dazu kommt die Kontinuität. Wenn ich einer Agentin eine Arbeitsweise beibringe oder eine Korrektur dauerhaft festhalte, soll das den nächsten Werkzeugwechsel überleben. Sonst beginnt nach jedem Umzug wieder die mühsame Phase, in der das Team seine eigenen Regeln nicht kennt. Und weil meine Autorin Sol unter meinem Namen schreibt, gibt es einen dritten Grund: Verlässlichkeit bei den Freigaben. Dass sie niemals selbst veröffentlicht, darf nicht davon abhängen, in welchem Werkzeug sie heute läuft. Dazu gleich mehr. Eine kleine Datei sagt dem Werkzeug, wo der Agent wohnt Damit ein Werkzeug einen Agenten laden kann, wird eine Brücke benötigt. Bei mir ist das eine kleine Konfigurationsdatei, der Adapter: Er zeigt auf den Ordner des Agenten im Brain – dem privaten Git-Repository, in dem all diese Dateien versioniert liegen –, nennt die Lesereihenfolge für den Start, lädt die Freigaberegeln ausdrücklich mit und verlangt, dass der Agent am Ende einer Sitzung einen Tageseintrag in sein Gedächtnis zurückschreibt (der sogenannte Write-Back). Genauso wichtig ist, was nicht hineingehört: keine Kopie der Persönlichkeit, kein dupliziertes Fachwissen, keine zweite Fassung der Freigaberegeln. Jede Kopie beginnt zu veralten, sobald sie existiert. Genau das habe ich einmal gebaut – in einem frühen Setup lag eine zusammengesetzte Persona-Kopie auf dem Zielsystem, und mir wurde klar, dass sie bei der nächsten Korrektur im Brain still falsch werden würde. Ich habe das noch am selben Tag auf direkte Verweise umgestellt, und seitdem bleiben diese Dateien bewusst klein. Sechs Brücken zum selben Brain Inzwischen gibt es solche Brücken für sechs Werkzeuge. Claude Code von Anthropic liest projektbezogene Anweisungen samt Agentendefinitionen. Codex – das Kommandozeilen-Werkzeug aus OpenAIs ChatGPT-Welt – bekommt ein Projekt-Briefing. Google Gemini erwartet eine eigene Projektdatei, und Hermes von Nous Research lädt die Identität über einen System-Prompt. Kimi Code von Moonshot AI und Grok Build von xAI, die beiden jüngsten, bringen jeweils eigene Agenten-Formate mit. Sechs Formate, sechsmal andere Syntax. Inhaltlich steht trotzdem überall dasselbe: wo der Agent wohnt, was beim Start zu lesen ist, welche Freigaben gelten und was am Ende zurückgeschrieben wird. Nach demselben Prinzip übergeben meine Agenten einander Arbeit. Wenn Nox – mein Orchestrator, also der Agent, der Aufgaben verteilt und den Überblick hält – einen Auftrag an ein anderes Werkzeug delegiert, kopiert er die Persona nicht in den Auftragstext. Er schreibt sinngemäß: Arbeite als Sol, lies zuerst ihre Dateien. Das Ziel lädt dadurch immer den aktuellen Stand, einschließlich der jüngsten Korrekturen. Die Freigaberegeln reisen mit Der am wenigsten verhandelbare Teil dieses Systems sind die Grenzen. Sol darf Texte entwerfen und in WordPress als Entwurf ablegen; veröffentlichen darf sie nicht, das entscheide ich. Diese Regel steht in ihren eigenen Agentendateien – in RULES, ihrem Arbeitsvertrag mit Fähigkeiten und Freigaben, und in MASTER, ihrem ausführlichen Handbuch – und beide werden bei jedem Start geladen, egal in welchem Werkzeug. Beauftragt Nox sie also über Codex statt über Claude Code, ändert sich an dieser Freigabe nichts. Auch das leistungsfähigste Werkzeug bekommt keine zusätzlichen Rechte, nur weil es mehr kann: Ein längerer Delegationsweg macht aus einer Autorin keine Herausgeberin. Dasselbe gilt für alles, was Geld kostet, etwas löscht oder etwas produktiv schaltet – solche Schritte bleiben bei mir, unabhängig vom Werkzeug. Vier Stufen vom Versprechen zum Beleg An dieser Stelle könnte ich behaupten: sechs Werkzeuge, ein Team, alles läuft. Aber sechs Adapterdateien beweisen erst einmal gar nichts – eine Konfigurationsdatei ist ein Versprechen und noch lange kein Betrieb. Deshalb prüfe ich jeden Körper in vier Stufen und behaupte nur, was die jeweilige Stufe hergibt. Zuerst prüfen automatische Testskripte den Papierstand. Zeigt die Brücke auf das richtige Brain, lädt sie die Pflichtdateien, stehen die Freigaberegeln drin? Diese Tests fangen auch Kleinigkeiten ab, etwa wenn ein konkreter Name versehentlich in eine generische Vorlage gerät. Auf der zweiten Stufe muss das Werkzeug wirklich starten und die Identität in der vorgesehenen Reihenfolge lesen – nur lesend, ohne etwas zu verändern. Erst dann weiß ich, dass der Körper die Persona tatsächlich lädt und nicht bloß laden könnte. Die dritte Stufe ist meine Notfallprobe. Aus einer frischen Kopie des Repositorys, in einer bewusst kargen Umgebung ohne meine gewohnten Programme, muss sich ein Agent samt Regeln und Gedächtnisroutine wiederherstellen lassen – nur mit Git und Python-Bordmitteln. Wenn das klappt, hängt das System an keiner versteckten Installation auf meinem Rechner. Die vierte Stufe ist der volle Durchstich: Der Agent erledigt im laufenden Werkzeug eine echte Aufgabe, hält seine Freigaben ein und schreibt den Tageseintrag in sein Gedächtnis. Anschließend muss ein zweiter, unabhängiger Lauf diesen Eintrag wieder lesen können. Erst dann nenne ich einen Körper vollständig arbeitsfähig. Die Stufen bauen aufeinander auf, und keine erledigt die nächste mit. Wer sie vermischt, macht aus einer vorhandenen Konfiguration schnell einen erfundenen Praxisbeweis. Wo die sechs Körper heute stehen Fünf der sechs haben inzwischen echte Läufe hinter sich – aber nicht alle auf derselben Stufe, und genau so sage ich es auch. Hermes ist der Körper, in dem Nox ohnehin täglich arbeitet und sein Tagebuch führt. Claude Code hat den vollen Durchstich bestanden: echte Aufgabe, eingehaltene Freigaben, Tageseintrag geschrieben und unabhängig zurückgelesen. Grok Build, der jüngste Zugang, hat denselben Durchstich inzwischen ebenfalls geschafft. Zwei Einschränkungen gehören zu diesem Beleg: Die unbeaufsichtigten Läufe brauchten mehrere ausdrückliche Fortsetzungen derselben Sitzung, und Groks eingebautes Langzeitgedächtnis bleibt bewusst ausgeschaltet – erinnert wird ausschließlich im Brain. Codex hat den gemeinsamen Lesevertrag mehrfach real belegt, zuletzt im direkten Vergleich mit Claude Code und Hermes: Alle drei lasen dieselbe Startsequenz aus demselben Brain und kamen zur selben Auswertung. Kimi Code hat einen ersten echten Lauf hinter sich, bislang nur lesend. Für beide steht der volle Durchstich mit zurückgeschriebenem Tageseintrag noch aus – behauptet wird er deshalb auch nicht. Bleibt Gemini. Die Brücke ist gebaut und besteht alle Vertragstests, aber einen echten Lauf gibt es noch nicht – und das liegt inzwischen nicht mehr an meinem Setup: Google hat den kostenlosen Zugangsweg für dieses Werkzeug eingestellt und verweist auf ein Nachfolgeprodukt. Ob ich dorthin wechsle, einen Bezahlzugang nehme oder Gemini vorerst parke, entscheide ich in Ruhe. Bis dahin steht Gemini in meiner Liste als das, was es ist – vorbereitet, aber nicht belegt. Warum ich trotzdem von Körperwechsel spreche Die Metapher trägt, solange sie technisch sauber bleibt. Der Körper bringt die Fähigkeiten mit: Modellzugang, Terminal, Browser, Zeitsteuerung, Oberfläche. Das Brain liefert Rolle, Handwerk, Grenzen und Erinnerung. Ein Wechsel verändert also, was ein Agent kann und wo er arbeitet – nicht, wer er ist. Das funktioniert nur, solange beide Seiten getrennt bleiben. Sobald ein Körper anfängt, eigenes Wissen zu horten, das nirgendwo sonst gespiegelt ist, wird er wieder Teil des Gedächtnisses – und ich wieder abhängig von einem einzelnen Werkzeug. Falls du dich fragst, ob sich dieser Aufwand im Alltag lohnt: Genau diese Bilanz ziehe ich im letzten Teil – was beim Körperwechsel tatsächlich portabel war, welche Lücken sichtbar wurden und welche Nachweise noch fehlen. Quellen Projektquelle: agents-brain-Spezifikation, sechs Harness-Adapter, Interop- und Fresh-Clone-Prüfskripte sowie interne Laufzeitprotokolle (private Primärquellen) Pro Git: What is Git? Agents-Brain-Serie← Teil 4: Erinnern ist bei meinen Agenten eine SchreibroutineTeil 6: Was nach dem Körperwechsel wirklich geblieben ist →