Wer den ganzen Tag mit einem KI-Coding-Agenten arbeitet, kennt den Moment: Man öffnet eine neue Session — und fängt bei null an. Man erklärt erneut, wer man ist, welche Repos und Kunden gerade zur Hand sind, welche Konventionen wo gelten und was letzte Woche eigentlich entschieden wurde. Der typische Arbeitsstand ist ein nackter „Eigene-Dateien”-Ordner. Jede Konversation baut Kontext und Struktur von Grund auf neu auf.
So fühlt es sich konkret an:
- „Ich wechsle zwischen Kunden und lade den falschen Kontext.”
- „Ich habe keinen Nachweis, was ich letzte Woche entschieden habe.”
- „Mein Agent vergisst, welche Konventionen wo gelten.”
- „Jede Session erkläre ich neu, wer ich bin und woran ich arbeite.”
Wir bei BKS-Lab hatten genau dieses Problem — Tag für Tag, über mehrere parallele Kundenkontexte hinweg. Die Lösung, die sich bei uns durchgesetzt hat, ist nicht der nächste clevere Prompt. Es ist ein dauerhafter Ort, den der Agent bei jeder Session liest und beschreibt. Dieser Ort heißt open-bridge — gebaut, um BKS-Lab selbst zu betreiben, und jetzt unter MIT-Lizenz freigegeben.
Was open-bridge ist
open-bridge ist ein schlichtes Git-Repository aus Markdown- und YAML-Dateien, das ein KI-Coding-Agent zu Beginn jeder Session liest — unabhängig davon, welches Modell oder welches Frontend man verwendet. Das Substrat selbst betreibt nichts: keine Datenbank, kein Daemon, kein SaaS, kein gehosteter Dienst. Nichts zu hosten, keine zweite App zu pflegen. Es sind nur Dateien, die der Agent liest.
„Ein Agent kann eine Datei lesen, aber keinen API-Key halten."
Genau das ist der ganze Punkt. Was Sie heute hineinschreiben, liest Ihr Agent in sechs Monaten noch — ohne Migration, ohne Vendor-Lock-in.
Und weil das Substrat inspizierbarer Klartext ist, muss man keiner Blackbox vertrauen. Repo klonen, jede Datei mit cat ansehen, diffen, versionieren. Das „Gedächtnis” des Agenten sind einfach Dateien, die einem selbst gehören.
Die Analogie
Stellen Sie sich open-bridge als einen Ort vor, an dem sich der Agent erinnern kann — neben Ihrem Modell und Ihrem Werkzeug eine dritte, ortsfeste Schicht. Sie hängt nicht an der Konversation, die endet, sondern liegt im Repo und wird Session für Session dichter.
Zwei Eigenschaften, um die herum es gebaut ist
Das Projekt steht auf zwei benannten Ideen. Beide haben wir bei BKS-Lab geprägt; die einfache Bedeutung führt, der Begriff folgt.
Context Booster — die dritte Seite
Welches Modell und welches Frontend man auch nutzt: open-bridge legt eine unabhängige Kontextschicht daneben, die der Agent immer liest — eine „dritte Seite” neben Modell und Tool. Eine Ecosystem-Registry plus always-on geltende Standing Orders geben dem Agenten dauerhaftes, strukturiertes Wissen über die eigene Welt: wer man ist, welche Repos und Kunden es gibt, was man gestern gemacht hat. Der Agent hört auf zu fragen „GitHub oder Jira?”, lädt nicht mehr den falschen Kunden, und auf ein schlichtes „guten Morgen, Briefing” liefert er, was heute zählt. Das ist für uns der wichtigste Zweck von open-bridge.
Chaos Tamer — Struktur in unstrukturierte KI-Dialoge
Die meiste KI-Arbeit sieht aus wie dieser nackte Ordner: Jeder häuft seinen eigenen Wust an, jede neue Konversation beginnt von vorne. open-bridge bändigt das, indem es eine fertige Struktur mitliefert, statt sie erfinden zu lassen. Es tut drei Dinge: Es hält eine Struktur — ein Board, ein tägliches Log und ein STATUS pro Task. Es legt Wissen während der Arbeit ab — Entscheidungen, Funde und Status landen in Klartext, den der Agent später zurückliest. Und es hält die Arbeit davon ab abzudriften — zurück in den unsortierten Haufen. Aus unstrukturierten Sessions wird ein abgelegtes, dauerhaftes, kumulierendes Protokoll.
Wie es aufgebaut ist
Im Kern liegen drei semantische Cluster-Ordner und ein Arbeitsbereich:
deine-bridge/
├── identity/ WER bin ich, an WEN sende ich
├── infra/ WO läuft was, WIE erreiche ich es
├── workflow/ WAS passiert wann (Kontexte, Projekte)
└── work/
├── board.md generiertes Task-Board
├── log.md tägliches Arbeits-Log
├── tasks/ endliche Tasks
├── streams/ Dauerläufer (werden nie „done")
└── done/ abgeschlossen, monatlich archiviertEin Task-STATUS und eine Log-Zeile sind nichts weiter als Text, den der Agent liest und schreibt — und der in sechs Monaten noch im Diff steht:
# STATUS — bigcorp-migration
status: doing
context: bigcorp
last: Rechnungs-Pipeline auf neues Schema migriert; ein Test noch rot.
next: Den fehlschlagenden UBL-Validierungsfall fixen, dann PR öffnen.| 14:22 | Entscheidung | bigcorp | Schema auf v2 gepinnt — v3 bricht die alten Exporte. |Der Status-Lebenszyklus ist ein geschlossenes Enum: backlog → doing → review → done. Daneben sitzen die Skills — die modell-agnostischen Verben über dem Substrat, ein einziger skills/-Baum, der per Symlink in die Pfade von Claude Code, Codex, Copilot CLI und Cursor zeigt. Commands sind Skills mit /cmd-Trigger (/briefing, /debrief, /archive, /bridge-status, /bridge-onboard). Und Standing Orders sind always-on geltende Regeln — Code-Stil, Security-Baselines, Logging-Gewohnheiten —, die in jeden Dispatch injiziert werden.
Warum nicht einfach eine CLAUDE.md
Eine CLAUDE.md ist ein einzelnes, flaches Anweisungsblatt. open-bridge ist ein dauerhafter, strukturierter Arbeitsbereich und kann drei Dinge, die eine Dotfile nicht kann:
- Es trennt Kontext-Welten. Jeder Kunde, jedes Engagement bekommt seinen eigenen Arbeitsbereich — so lädt der Agent nicht die Fakten des falschen Kunden in die Zusammenfassung dieses Kunden.
- Es führt ein dauerhaftes Arbeitsprotokoll über Sessions hinweg — Board, Log und Task-STATUS überleben das Ende der Konversation.
- Es zieht geteilte Templates nach, ohne private Daten zu überschreiben — der CORE/USER-Split macht genau das.
Dieser Split sind zwei Branches, die unterschiedliche Pfade berühren. Die ausgelieferten Templates, Skills und Docs leben auf CORE (main); der eigene angesammelte Kontext — Tasks, Config, Credentials — lebt auf user/{name}. Weil sie sich nicht überschneiden, kollidieren Merges nie: Ein git merge main zieht Upstream-Verbesserungen herein, eigene Daten landen nie auf dem geteilten Branch, und Verbesserungen fließen über /promote zurück — der liest pro Datei das scope:-Feld und routet entsprechend (core → Upstream, org → eigenes Overlay, user → lokal).
Ehrlicher Stand
Der Teil, den ich am wenigsten überspringen möchte: Wo steht das Projekt wirklich.
Ehrlicher Stand
open-bridge wird von einem kleinen Team gepflegt und läuft auf genau einer selbst-gehosteten Instanz — bei BKS-Lab gebaut, um BKS-Lab zu betreiben, und dann geöffnet. N=1, noch keine externen Nutzer, frisch veröffentlicht. Dieser Artikel beschreibt die Methode und das Substrat, nicht Verbreitungszahlen.
Wir trennen das bewusst in drei Schichten. Erprobt (gebaut und selbst genutzt): das Drei-Cluster-Layout, das Work-System, der CORE/USER-Split, Personas, Standing Orders, die Skills-Schicht und das Scope-Routing laufen ab dem frischen Klon. GitHub-Task-Sync funktioniert für unseren eigenen Gebrauch — Jira ist ungetestet. Wette (falsifizierbar): dass Markdown plus YAML plus git das Substrat bleibt, das künftige Agent-Generationen nativ lesen, und dass eine schlanke MIT-OSS-Methode einen Vendor-Workflow-Builder schlägt für alle, die das Modell frei wechseln wollen. Offen (ungelöst): null externe Nutzer — jede Aussage über die Zielgruppe ist Hypothese, kein Markttest. Die als Default gedachte Workspace-Trennung ist im Prinzip vereinbart, aber noch nicht in open-bridge gebaut — lesen Sie sie nicht als ausgeliefertes Feature. Und der Wert der ersten Session ist dünn, bis die work/log.md über die Zeit mit echter Arbeit gefüllt ist.
Zur Sicherheit gehört dieselbe Nüchternheit: Der Agent schlägt vor, der Mensch entscheidet. Destruktive und ausgehende Aktionen sind pro Aktion gegated ([y]). Secrets leben nie im Repo — nur Referenz-URIs wie azure-keyvault://, 1password:// oder keychain://, und die CI bricht bei einem committeten Secret ab. Nichts telefoniert nach Hause: keine Telemetrie, keine Analytics. Das sind Konventionen, denen der Agent folgt — keine OS-Level-Sandbox.
Warum MIT, warum überhaupt öffnen
Wir hätten das intern halten können. Aber das Substrat ist die Wette: Wenn Markdown-in-git die richtige Grundlage ist, dann ist sie es für alle, nicht nur für uns. MIT war die bewusste Wahl — für Code und Inhalt gleichermaßen, damit es einen einzigen, unmissverständlichen Wiederverwendungs-Pfad gibt. Eine separate Markenrichtlinie schützt lediglich Name, Brand und Logo; Lizenzen decken Copyright ab, keine Marken. So bleibt die Wiederverwendung reibungsfrei, während die Marke für kommerzielle Angebote auf derselben Architektur geschützt bleibt.
So fangen Sie an
Kein Signup, keine Warteliste, nichts zu hosten:
git clone https://github.com/bks-lab/open-bridge.git
cd open-bridge
/bridge-onboard # innerhalb von Claude Code ausführen/bridge-onboard führt durch das geführte Onboarding und richtet alles ein — Ecosystem-Erkennung, Work-System-Config, ein eigener user/{name}-Branch. Die Cross-Tool-Discovery-Symlinks sind committed, daher laufen macOS, Linux und WSL out of the box; unter nativem Windows einmal bin/setup.ps1. Was sofort da ist: ein laufender, leerer Arbeitsbereich. Was eine Wette ist: der kumulierende Wert, der eine über die Zeit gefüllte work/log.md braucht. Ein komplettes Zwei-Kunden-Beispiel liegt in examples/agency/ zum Klonen und Lesen.
Am vollständigsten getestet ist open-bridge mit Claude Code (Slash-Commands und Hooks unter .claude/); Codex und Copilot CLI funktionieren über AGENTS.md plus den skills/-Symlink. Gemini CLI, Cursor und Windsurf folgen demselben Standard, sind aber ungetestet. Es ist frisch veröffentlicht — rechnen Sie mit rauen Kanten, und der nützlichste Beitrag gerade ist, ein Issue zu öffnen, wenn Sie eine finden.
open-bridge ausprobieren
MIT-lizenziert, ein git clone entfernt. Klonen, /bridge-onboard starten, fertig.
Doku + Konzepte: bks-lab.github.io/open-bridge
