--- title: Das Gehirn meiner Agenten ist ein Git-Repo — isla Studio url: https://isla-stud.io/ki-b2b/gehirn-meiner-agenten-git-repo/ date: 2026-07-22 --- # Das Gehirn meiner Agenten ist ein Git-Repo Was du hier mitnimmst: Du bekommst die sieben Regeln und die einfache Vault-Struktur, mit denen ich Agentenwissen lesbar, versionierbar und werkzeugunabhängig halte. Inhaltsverzeichnis Ein KI-Agent braucht für mich keine mystische Erinnerung. Er braucht Dateien, die ich lesen, prüfen und wiederverwenden kann. Deshalb liegt das Gehirn meiner Agenten in einem privaten Git-Repository. Markdown ist darin die Quelle der Wahrheit. Git dokumentiert, wann sich etwas geändert hat. Obsidian ist meine bequeme Oberfläche für Suche, Verlinkungen und Überblick – aber nicht die Voraussetzung, um an die Inhalte zu kommen. Wenn Obsidian nicht verfügbar ist, öffne ich die Dateien im Texteditor. Wenn ein Agentenwerkzeug wegfällt, zeigt sein Adapter auf denselben Ordner. Wenn eine zusätzliche Memory-Engine hinzukommt, darf sie den Bestand indexieren, aber nicht ersetzen. Das klingt schlicht. Damit es im Alltag nicht wieder zu einem undurchsichtigen Ablagehaufen wird, gelten sieben Hard Rules. Regel 1: Markdown ist die Quelle der Wahrheit Personas, Arbeitsregeln und kuratiertes Wissen liegen als Markdown vor. Eine semantische Suche, ein Vektorindex oder eine Memory-Engine darf daraus eine schnellere Sicht erzeugen. Die Ableitung ist jedoch nie der einzige Bestand. Das schützt nicht nur vor Tool-Bindung. Es macht Korrekturen überprüfbar. Ich kann im Diff sehen, welcher Satz geändert wurde, statt darauf zu vertrauen, dass ein unsichtbarer Memory-Prozess schon das Richtige gespeichert hat. Regel 2: Eine Persona hat genau ein Brain Derselbe Agent soll nicht in jedem Werkzeug eine leicht andere Version seiner Identität bekommen. Claude, Codex, Gemini und Hermes sollen auf dieselben kanonischen Dateien zugreifen. Sonst entsteht Persona-Drift: In einem Tool gilt eine neue Freigaberegel, im anderen noch die alte. Oder eine Korrektur landet nur in einem System-Prompt und ist beim nächsten Körperwechsel verloren. Eine Quelle verhindert diese stillen Abzweigungen. Regel 3: Adapter bleiben dünn Ein Harness ist das Werkzeug, in dem ein Agent arbeitet. Dafür braucht jedes System eine passende Brücke: eine Konfigurationsdatei, ein Projekt-Briefing oder einen System-Prompt. Diese Adapter sollen nur drei Dinge tun: den richtigen Agentenordner finden, die Lesereihenfolge nennen und den Memory-Write-back verlangen. Persona, Fachwissen und Governance werden nicht in den Adapter kopiert. Je dünner die Brücke, desto leichter lässt sie sich ersetzen. Regel 4: Geteiltes Wissen wird referenziert Mehrere Agenten brauchen dieselbe Brand Voice, dieselben Typografieregeln oder dieselben Sicherheitskonventionen. Solche Inhalte liegen in einem gemeinsamen Bereich und werden von dort geladen. Ich kopiere sie nicht in jeden Agentenordner. Eine Korrektur an der gemeinsamen Quelle soll alle betroffenen Rollen erreichen. Kopien würden schon nach der ersten Änderung auseinanderlaufen. Diese Regel ist unspektakulär. Genau deshalb ist sie wichtig. Infrastruktur ist unsexy. Aber sie hält länger als Features. Regel 5: Am Session-Ende wird geschrieben Ein Dateisystem erinnert sich nur an das, was tatsächlich in Dateien landet. Deshalb gehört ein Daily-Memory-Eintrag zum Abschluss einer Agentensession. Darin steht nicht der komplette Chat. Festgehalten werden Entscheidungen, erledigte Schritte, wichtige Befunde und offene Lücken. Später wird das Tageswissen in kuratiertes Langzeitwissen oder eine dauerhafte Lesson überführt. Ohne diese Routine wäre das Repository nur eine statische Prompt-Sammlung. Regel 6: Approval-Gates sind explizit Jeder produktive Agent hält fest, was er selbst tun darf und wo ein Mensch entscheiden muss. Bei Sol gilt zum Beispiel: Sie darf Drafts anlegen, aber nichts veröffentlichen. Ein anderer Agent darf Code ändern, aber keinen produktiven Rollout ohne Freigabe auslösen. Diese Grenzen stehen beim Agenten, nicht nur in einer Oberfläche. So reisen sie mit, wenn das Werkzeug wechselt. Regel 7: Das Brain ist kein Secret-Store Ein privates Repository ist nicht automatisch der richtige Ort für jeden Inhalt. Klartext-Secrets gehören dort nie hinein. Kundenbezogene Personas und vertrauliche Arbeitsinhalte bleiben in ihrem jeweiligen geschützten Projektkontext. Das zentrale Brain enthält nur das, was agentenübergreifend wirklich dorthin gehört. Diese Grenze ist Teil der Architektur, nicht nachträgliche Aufräumarbeit. So ist der Vault aufgebaut Die konkrete Struktur ist bewusst vorhersehbar: Am Anfang stehen die Spezifikation und Übersichten für Menschen und Agenten. Ein gemeinsamer Bereich enthält Brand Voices, Konventionen und agentenübergreifende Lessons. Vorlagen sorgen dafür, dass neue Agenten dieselben Kernbausteine erhalten. Harness-Adapter bilden die Brücken zu den verschiedenen Werkzeugen. Jeder Agent bekommt einen eigenen Ordner mit Persona, Handwerk, Fähigkeiten, Grenzen und Memory. Diese Ordnung ist wichtiger als der genaue Ordnername. Ein neuer Agent soll verstehen können, wo er lesen und wo er schreiben darf, ohne erst die gesamte Historie des Projekts zu kennen. Warum Git und keine Datenbank? Eine Datenbank könnte Abfragen schneller beantworten. Für die kanonische Identität meiner Agenten bringt Git jedoch drei Vorteile, die mir wichtiger sind. Lesbarkeit: Markdown lässt sich ohne Spezialsoftware öffnen. Nachvollziehbarkeit: Ein Diff zeigt, was sich verändert hat. Ein Commit verbindet Änderung, Zeitpunkt und Begründung. Portabilität: Ein geklonter Ordner kann auf einer anderen Maschine und mit einem anderen Werkzeug weiterverwendet werden. Das heißt nicht, dass Datenbanken oder Vektorsuche nutzlos sind. In meinem Setup dürfen sie als Index oder Cache dazukommen. Sie sind Beschleuniger, nicht Eigentümer des Wissens. Obsidian ist die Oberfläche, nicht das Fundament Ich nutze den Repository-Root zugleich als Obsidian-Vault. Dadurch bekomme ich Wikilinks, Graph, Suche und kuratierte Übersichtsseiten. Für mich als Mensch ist das sehr hilfreich. Der wichtige Punkt ist aber: Obsidian speichert die Notizen als lokale Dateien. Die Oberfläche kann wechseln, ohne dass die Quelle neu geschrieben werden muss. Genau diese Trennung wünsche ich mir auch auf der Agentenseite. Ein gutes Werkzeug darf Arbeit angenehmer machen. Es sollte nicht darüber entscheiden, ob mein Wissen noch lesbar ist. Der praktische Prüfstein Ein Agents Brain ist erst dann portabel, wenn du drei Fragen mit Ja beantworten kannst: Kannst du die Persona ohne das bisherige Tool lesen? Kann ein anderes Werkzeug dieselben Regeln laden, ohne dass du sie kopierst? Ist sichtbar, was ein Agent am Ende der Session dauerhaft festgehalten hat? Wenn eine Antwort Nein lautet, steckt an dieser Stelle noch Wissen im Werkzeug statt im Brain. Im nächsten Teil zerlege ich einen einzelnen Agenten in seine vier Kerndateien: SOUL, MASTER, RULES und MEMORY. Ihre Trennung macht aus einem langen Prompt eine wartbare Arbeitsidentität. Quellen Projektquelle: agents-brain-Spezifikation, Vault-Layout und Validatoren, Stand 15.07.2026 (private Primärquelle) CommonMark: offene Markdown-Spezifikation Pro Git: What is Git? Obsidian Help: How Obsidian stores data Agents-Brain-Serie← Teil 1: Ich habe OpenClaw abgeschafft. Was von meinem KI-Team übrig blieb.Teil 3: Ein Agent besteht bei mir aus vier Dateien →