Überarbeitet am 24. September 2026. Der Stand unten ist der von heute, nicht der vom Juni.

Ein KI-Coding-Agent beginnt jede Sitzung ohne Erinnerung. Man erklärt ihm wieder, für welchen Kunden man gerade arbeitet, welche Repos dazugehören, welche Regeln dort gelten und was letzte Woche entschieden wurde. Wer zwischen mehreren Kunden wechselt, lädt dabei früher oder später den falschen Kontext.

Wir hatten dieses Problem jeden Tag. Die Lösung, die sich bei uns gehalten hat, ist kein besserer Prompt. Es ist ein fester Ort, den der Agent zu Beginn jeder Sitzung liest und während der Arbeit fortschreibt. Dieser Ort heißt BKS open-bridge. Wir haben ihn gebaut, um BKS-Lab selbst zu betreiben, und im Juni unter MIT-Lizenz geöffnet.

Was BKS open-bridge ist

BKS open-bridge ist ein Git-Repository aus Markdown- und YAML-Dateien. Der Agent liest es zu Beginn jeder Sitzung, egal welches Modell oder welches Werkzeug dahintersteht. Es läuft nichts: keine Datenbank, kein Dienst, keine zweite App. Es sind Dateien, die einem selbst gehören.

Das hat eine praktische Folge. Man muss keiner Blackbox vertrauen. Jede Datei, die der Agent liest, lässt sich mit cat ansehen, diffen und versionieren. Was heute hineingeschrieben wird, liest ein Agent in sechs Monaten noch, ohne Migration und ohne Anbieterwechsel.

So sieht das am Morgen aus. Auf „good morning“ antwortet der Agent im mitgelieferten Beispiel:

Morning. You're mid-incident on bigcorp: Stripe webhook retries are
failing in prod (P1, opened yesterday). Root cause traced to the
webhook secret; next step is the retry fix. startupxyz onboarding:
email-verification wired, 6 tests green. Board: 2 doing · 1 review ·
cart-a11y waits on PR #214.

Jede Angabe darin stammt aus einer Datei im Repo. Wer das Arbeitsprotokoll daneben öffnet, sieht, woher.

Wie es aufgebaut ist

Drei Ordner beschreiben die eigene Welt, ein vierter die Arbeit:

deine-bridge/
├── identity/        wer bin ich, an wen sende ich
├── infra/           wo läuft was, wie erreiche ich es
├── workflow/        was passiert wann
└── work/
    ├── board.md     erzeugtes Aufgaben-Board
    ├── log.md       tägliches Arbeitsprotokoll
    ├── tasks/       Aufgaben mit Ende
    ├── streams/     Daueraufgaben
    └── done/        Abgeschlossenes, monatlich abgelegt

Jede Aufgabe ist ein Ordner mit einer Datei STATUS.md. Oben steht ein kleiner YAML-Kopf mit Status, Priorität und Herkunft, darunter freier Text. Der Status kennt genau vier Werte: backlog, doing, review, done. Das Board wird aus diesen Ordnern erzeugt und nie von Hand gepflegt. Deshalb kann es nicht veralten.

Das Protokoll ist das eigentliche Gedächtnis. Jeder erledigte Schritt bekommt sofort eine Zeile mit Datum, Uhrzeit, Projekt und Inhalt:

| 2026-06-24 14:30 | 📝 | bigcorp | Ursache der Webhook-Fehler im Task-STATUS festgehalten, nächster Schritt: Retry-Fix |

Darüber liegen die Skills: Befehle wie /briefing für den Morgen oder /debrief für ein Gespräch, aus dem Protokoll, Aufgaben und ein Mailentwurf werden. Alle liegen in einem einzigen Ordner, den Claude Code, Codex und Copilot CLI gleichermaßen finden. Dazu kommen Standing Orders, feste Regeln, die in jeder Sitzung gelten.

Warum nicht einfach eine CLAUDE.md

Eine CLAUDE.md ist ein einzelnes Anweisungsblatt. Für ein Repo reicht das. Wer mehrere Kunden, Rollen und Repos betreut, braucht drei Dinge, die ein Blatt nicht leistet.

  1. Getrennte Welten. Jeder Kunde bekommt seinen eigenen Kontext, und für Firmen mit eigenen Daten betreiben wir eigene, geschlossene Instanzen. So landet nichts aus dem einen Projekt in der Zusammenfassung des anderen.
  2. Ein Protokoll über Sitzungen hinweg. Board, Log und Aufgabenstatus überleben das Ende der Konversation.
  3. Updates ohne Datenverlust. Die gemeinsame Vorlage liegt auf main, die eigenen Daten auf einem privaten Branch user/{name}. Beide berühren getrennte Pfade, also bleibt ein git merge ohne Konflikt. Ein Push-Schutz verhindert, dass der private Branch je in einem öffentlichen Repo landet. Allgemeine Verbesserungen gehen über /bridge-promote zurück, als Pull Request mit Inhaltsprüfung.

Was sich seit Juni geändert hat

Drei Monate Alltag haben einiges bestätigt und einiges korrigiert.

Kontext wächst still. Was der Agent vor seiner ersten Antwort liest, wächst mit jeder neuen Regel und jedem neuen Skill, ohne dass es jemand bemerkt. Heute hat dieser Teil eine feste Obergrenze in Byte, und die Tests schlagen fehl, wenn sie überschritten wird. Alles andere ist ein Verzeichnis: eine Zeile pro Repo oder Kunde, der volle Eintrag kommt erst, wenn der Name fällt.

„Wo steht das?“ wurde die häufigste Frage. Dafür gibt es jetzt eine Tabelle, die Fragen in Alltagssprache der Datei zuordnet, die sie beantwortet. Eine Prüfung stellt sicher, dass jeder Verweis darin auflöst.

Ein Beispiel reichte nicht. Das erste Beispiel war eine Agentur mit zwei Kunden. Die Instanz mit der meisten Nutzung gehört aber einer Person mit mehreren Rollen: Beratung, Freelance, Haushalt, eigener Server. Diese Form liegt jetzt als zweites Beispiel bei.

Der erste Beitrag von außen ist da. Am 24. September wurde der erste Beitrag eines externen Entwicklers gemergt, eine Anbindung für GitLab-Issues. Offene Einstiegsaufgaben stehen auf GitHub.

Ehrlicher Stand

Im Juni stand hier „eine Instanz, keine externen Nutzer“. Heute arbeitet das BKS-Lab-Team jeden Tag auf eigenen Instanzen, und daneben laufen geschlossene Instanzen für andere Unternehmen. Eine breite Nutzerbasis ist das nicht, und wir behaupten auch keine.

Was erprobt ist, was eine Wette ist und was offen ist, führt das Projekt an einer Stelle: in der ROADMAP. Am gründlichsten getestet ist Claude Code. Codex und Copilot CLI laufen über AGENTS.md und denselben Skill-Ordner. Für Gemini CLI und Cursor fehlt uns eigene Erfahrung, dafür sind Einstiegsaufgaben offen. Der Nutzen der ersten Sitzung bleibt dünn, bis das Protokoll mit echter Arbeit gefüllt ist.

Zur Sicherheit gilt dieselbe Nüchternheit. Der Agent schlägt vor, der Mensch entscheidet. Alles, was nach außen geht oder etwas löscht, braucht eine Freigabe pro Aktion. Eine Mail verschickt der Agent nicht ohne ausdrückliches Ja. Secrets liegen nie im Repo, nur Verweise wie azure-keyvault:// oder keychain://. Das Repo selbst sendet nichts, keine Telemetrie, keine Analyse. Das sind Regeln, denen der Agent folgt, keine Sandbox des Betriebssystems.

Im Labor

Auf unserer Laborseite zeigen interaktive Stände, wie das im Betrieb aussieht: eine Brücke, von der aus alles läuft, Kontext, der von Sitzung zu Sitzung wächst, und Aufgaben, die über die Sitzung hinaus halten.

Warum wir zeigen, wie wir arbeiten

BKS open-bridge ist kein Nebenprodukt. Es ist das Repo, aus dem wir BKS-Lab betreiben, mit denselben Regeln, Befehlen und Freigaben, die unsere Agenten jeden Tag befolgen. Wer wissen will, wie ein Agent bei uns mit einer Kundenmail oder einem Deployment umgeht, muss uns das nicht glauben. Er kann die Regel nachlesen.

Wie ernst das gemeint ist, zeigt meine eigene Instanz. Seit dem 4. Juli stehen dort 4.072 Zeilen im Arbeitsprotokoll, 164 Aufgaben sind abgeschlossen, und das Repo hat seit dem 20. Juni 2.426 Commits. Allein am 24. September kamen 112 Protokollzeilen dazu. Kundenprojekte, Verwaltung, dieser Artikel: Alles läuft über dieselbe Bridge.

Was alle brauchen können, liegt offen. Was nur BKS-Lab betrifft, liegt in einem privaten Firmen-Overlay: gemeinsame Skills, Kundenkontexte, Board-Konfigurationen und Firmenregeln, derzeit 115 Dateien. Eine neue Kollegin klont BKS open-bridge, abonniert das Overlay mit einem Befehl und hat am ersten Tag eine Bridge, die unsere Kunden, Boards und Abläufe kennt. Eigene Anpassungen haben Vorrang, Änderungen der Firma kommen per Synchronisation nach.

Warum MIT

Wir hätten den Kern intern halten können. Aber wenn Markdown in Git die richtige Grundlage für Agentenkontext ist, dann gilt das für alle, die mit Agenten arbeiten. MIT gilt für Code und Inhalt gleichermaßen, damit es genau einen Weg der Wiederverwendung gibt. Eine getrennte Markenrichtlinie schützt nur Name und Logo, denn Lizenzen regeln Urheberrecht, keine Marken.

So fängt man an

Klonen muss man nichts von Hand. Auf der Website von BKS open-bridge steht ein fertiger Text zum Kopieren. Man fügt ihn in Claude Code, Codex oder Copilot CLI ein, und der Agent richtet die eigene Instanz ein: ein privates Repo als Ziel, BKS open-bridge nur als Quelle für Updates, den Push-Schutz. Vorher zeigt er seinen Plan und wartet auf ein Ja. Danach startet man eine neue Sitzung im neuen Ordner, und die Einrichtung fragt, wofür man die Bridge nutzen will.

Wer erst sehen will, wie sich das anfühlt, braucht gar keine Einrichtung. Im Repo liegt eine Beispiel-Agentur mit laufendem Board, zwei Tagen Protokoll und einem offenen Vorfall:

git clone https://github.com/bks-lab/open-bridge.git
cd open-bridge/examples/agency && claude    # oder: codex, copilot

Dort „good morning“ fragen, dann „where was I on the payment retry?“. Alles, was der Agent antwortet, steht in den Dateien daneben.

Wer die Einrichtung lieber selbst Schritt für Schritt macht, findet den Weg in der Installationsanleitung.

Es ist früh. Wer an einer rauen Kante hängen bleibt, hilft uns am meisten mit einem Issue.