mex-memory/mex: Teamwissen als Markdown im Repository, verteilt über Git
Team memory for engineers and their AI agents. Lives in your repo. Shared through Git.
Auf einen Blick
- Was ist das?
- MEX legt Architekturwissen, Entscheidungen und Übergaben als versionierte Dateien neben den Code und lässt Menschen und Coding-Agents darauf zugreifen. Der Ansatz ist bewusst dateibasiert und ohne Hosting-Dienst, was Stärken und Grenzen zugleich erklärt.
- Für wen ist es gedacht?
- MEX passt zu Teams, die ohnehin über Git zusammenarbeiten, ihre Kontextdateien reviewen wollen und Node.js ab Version 22.5 im Einsatz haben. Wer einen gehosteten Dienst mit zentraler Suche über viele Repositories oder einen fertigen MCP-Server erwartet, ist hier falsch.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: Wissen, das nur in einer Sitzung existiert
Das README beschreibt die Ausgangslage in drei Sätzen: Eine Ingenieurin kennt den Grund für eine Einschränkung, ein Kollege hat die Debugging-Historie, und ein Coding-Agent hat einen Randfall gefunden, den niemand sonst lesen wird. Der nächste Teammitglied setzt das Puzzle neu zusammen. Das ist kein Werkzeugproblem im engeren Sinn, sondern ein Ablageproblem: Sitzungsprotokolle von Agents sind flüchtig, Architekturentscheidungen leben in Köpfen oder in Chatverläufen, und Übergaben entstehen ad hoc.
MEX adressiert genau diese Lücke und richtet sich an Teams, in denen mehrere Personen mit Coding-Agents wie Claude Code, Codex oder Cursor arbeiten. Die Zielgruppe ist eng: Wer allein arbeitet, findet im README den Hinweis, dass die nächste Person, die dieses Wissen nutzt, man selbst in einer neuen Sitzung sein kann. Der Nutzen skaliert also mit der Teamgröße und mit der Häufigkeit von Übergaben. Für Einzelentwickler ohne Agenten ist der Aufwand schwer zu rechtfertigen.
Dateien im Repository statt Datenbank im Dienst
Die zentrale Designentscheidung lässt sich aus dem Repository-Aufbau ablesen: Kanonisches Wissen sind Markdown-Dateien im Projekt, die über gewöhnliche Git-Befehle wie commit, push und pull wandern. Das README nennt das explizit und listet auf, was nicht nötig ist: kein gehosteter MEX-Dienst, kein Docker, kein Proxy, kein MEX-Konto, kein vom Anbieter bereitgestellter Modellschlüssel.
Lokale Indizes, Entwürfe, Identitätsauswahl und der Hub bleiben pro Teammitglied getrennt. Dieses Modell hat eine klare Konsequenz: Es gibt keine zentrale Instanz, die Konflikte auflöst oder Aktualität garantiert. Zwei Personen können widersprechende Aussagen über dieselbe Architektur committen, und Git wird das nicht bemerken. Die Qualität hängt an Review-Prozessen, die das Team selbst etablieren muss. Dass das Projekt einen expliziten Review-Schritt für Wissensbeiträge vorsieht, ist folgerichtig, ersetzt aber keine Redaktionsregeln.
Wiki, Code Graph, Inbox und Relays
Die Wissensstruktur verteilt sich laut README auf mehrere Bereiche. Das Wiki hält Architektur, Entscheidungen, Konventionen und Muster fest und wird durch den Code Graph geerdet, also mit Verweisen auf tatsächlichen Code verknüpft. Der Code Graph wird über tree-sitter aufgebaut, das ist eines der Themen des Repositories. Die Inbox nimmt Vorschläge auf, die bestehendes Wiki-Wissen ergänzen oder korrigieren. Relays sind Übergaben mit Fortschritt, Entscheidungen, Blockern, Belegen und nächsten Schritten. Specs mit Anforderungen und Akzeptanzkriterien sowie Workstream-Datensätze bleiben laut README lesbar.
Bemerkenswert ist die Rolle des Hubs. Er ist eine lokale Oberfläche, in der Menschen Wissen durchsuchen, Vorschläge reviewen und Übergaben annehmen. Agents greifen dagegen über Projektanweisungen und die CLI zu. Diese Trennung ist plausibel: Menschen brauchen Kontext und Freigabe, Agents brauchen maschinenlesbare Abfragen. Die Release Notes zu 0.8.1 nennen außerdem einen Context-Graph, konfigurierbares Agent-Logging und einen Hub, der während des Aufbaus des Graphen weiter Anfragen bedienen kann.
Was ein Relay tatsächlich transportiert
Der Übergabe-Workflow ist der konkreteste Teil des Projekts, und das README beschreibt ihn als Ablauf in vier Schritten. Alex ändert die Behandlung von Webhook-Wiederholungen, Sam führt die Arbeit fort. Alex lässt zunächst Architektur, relevante Entscheidungen und Codebelege prüfen, aktualisiert dann die Wiki-Erklärung und bereitet für eine reviewpflichtige Schlussfolgerung einen Inbox-Vorschlag vor. Danach erstellt er über den Befehl $mex-relay einen Entwurf mit Änderungen, ausgeführten Tests, offenen Punkten und Anlaufstellen, prüft Entwurf und Veröffentlichungsvorschau im Hub und veröffentlicht explizit. Erst dann folgen Review, Commit und Push über Git. Sam pullt den Branch, aktualisiert bei Bedarf seine lokalen Indizes, öffnet den Hub, nimmt das Relay an und lässt seinen Agenten den Kontext lesen.
Wichtig ist die im README zweimal betonte Grenze: Ein Relay transportiert die Erklärung und den beobachteten Repository-Zustand, nicht den nicht committeten Code. Das Veröffentlichen schreibt Dateien in die eigene Arbeitskopie und benachrichtigt niemanden. Ohne Git-Transfer passiert nichts. Wer eine Benachrichtigung oder Zustellung erwartet, wird enttäuscht.
Installation und erste Schritte
Das Paket heißt mex-agent und wird über npm verteilt. Das README verlinkt die npm-Seite und die Versionshistorie, und die Badges im Repository nennen Node.js ab Version 22.5 sowie TypeScript 5.9. Das sind harte Voraussetzungen, die man vor dem Ausprobieren prüfen sollte. Ein Team, das noch auf einer älteren LTS-Version von Node.js läuft, muss zuerst aktualisieren.
Die konkreten Befehle sind im vorliegenden Material dünn dokumentiert. Der Text erwähnt ausdrücklich nur einen Befehl namentlich: $mex-relay, verwendet als Agent-Skill zur Erstellung eines Relay-Entwurfs. Die Abschnittsverweise des README enthalten einen Quick start, dessen Inhalt hier nicht vorliegt. Wer die Einrichtung plant, sollte diesen Abschnitt im Repository selbst nachlesen, statt sich auf Sekundärquellen zu verlassen. Ebenso verweist das README auf einen Abschnitt How mex works und eine Command map, die die vollständige Befehlsliste enthalten dürften. Aus dem Material lässt sich nicht belegen, welche Konfigurationsschlüssel existieren oder wo sie liegen.
Der MCP-Server ist nicht Teil des Pakets
Ein Detail, das bei der Auswahl leicht übersehen wird: Das Badge im README trägt die Aufschrift MCP: source only. Ein MCP-Server ist also im Quellcode vorhanden, wird aber offenbar nicht über das npm-Paket ausgeliefert. Wer MEX an einen MCP-fähigen Client anbinden will, muss mit dem Repository selbst arbeiten. Das erhöht den Einrichtungsaufwand und die Updatepflege erheblich gegenüber einer Installation aus der Registry.
Das ist eine Einschränkung, die man vor einer Evaluierung kennen sollte, denn sie verändert, wer das Werkzeug überhaupt sinnvoll betreiben kann. Teams ohne Bereitschaft, den Quellcode zu bauen und aktuell zu halten, sind hier falsch. Wer dagegen ohnehin eine eigene Build-Pipeline für interne Werkzeuge betreibt, hat kein zusätzliches Problem.
Wann MEX das falsche Werkzeug ist
Die dateibasierte Architektur hat einen Preis, der sich nicht wegdiskutieren lässt. Es gibt keine serverseitige Suche über mehrere Repositories, keine zentrale Rechteverwaltung und keine Garantie, dass zwei Checkouts denselben Wissensstand haben. Wer in einer Organisation mit vielen Repositories ein einheitliches Nachschlagewerk braucht, wird mit MEX nicht glücklich, weil jedes Repository sein eigenes Gedächtnis führt und die Verknüpfung zwischen ihnen Aufgabe der Nutzer bleibt.
Ein zweiter Grenzfall ist die Aktualität. Das Wiki wird nicht automatisch korrigiert, wenn sich der Code ändert. Der Code Graph verknüpft Wissen mit Code, aber ob eine Erklärung nach einem Refactoring noch stimmt, entscheidet der Review. Ein Team, das keine Kapazität für diese Pflege hat, produziert mit der Zeit veraltete Dokumentation, die schlimmer ist als keine. Und wer schnelle, einmalige Prototypen baut, bei denen Übergaben selten sind, investiert hier in Struktur ohne Gegenwert.
Alternative: Agents, die den Code selbst lesen
Die naheliegende Alternative ist der Verzicht auf ein separates Gedächtnis. Coding-Agents können ein Repository direkt durchsuchen, Dateien lesen und aus dem aktuellen Code ableiten, wie etwas funktioniert. Der Unterschied liegt im Ansatz: Ohne MEX ist der Code die einzige Wahrheitsquelle, und alles, was nicht im Code steht, muss in jeder Sitzung neu erschlossen werden. Das funktioniert gut, solange die Antworten tatsächlich im Code stehen.
MEX setzt dagegen auf ein zweites Artefakt neben dem Code, das Begründungen und Entscheidungen festhält, die der Code selbst nicht trägt. Das ist der eigentliche Unterschied und gleichzeitig das Risiko: Zwei Quellen können auseinanderlaufen. Wer nur den Code braucht, sollte beim Code bleiben. Wer regelmäßig erklären muss, warum etwas so und nicht anders gebaut ist, bekommt hier einen Ort dafür, der versioniert und reviewbar ist.
Pflegeaufwand, Lizenz und Versionsstand
MEX steht unter der MIT-Lizenz. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange Lizenz- und Urheberrechtshinweis erhalten bleiben. Es enthält keine Copyleft-Klausel, die den eigenen Code des Nutzers erfasst. Das ist eine Einordnung, keine Rechtsberatung; wer die Lizenz in einem Produkt einsetzt, sollte den Lizenztext im Repository selbst prüfen.
Der Pflegeaufwand liegt weniger im Werkzeug als im Inhalt. Jedes Teammitglied hält eigene lokale Indizes, Entwürfe und Identitätsauswahl, die nicht über Git geteilt werden. Nach einem Branch-Wechsel müssen Indizes möglicherweise aktualisiert werden, wie der Ablauf im README für Sam zeigt. Die Release-Kadenz ist aus den Angaben ablesbar: 0.7.3 am 26. August, 0.8.0 am 2. September, 0.8.1 am 9. September 2026. Drei Releases in zwei Wochen bedeuten schnelle Bewegung, aber auch, dass sich Details zwischen Versionen ändern können. Die Release Notes zu 0.8.1 nennen unter anderem sicherere Erdung und die bereits erwähnte Hub-Verfügbarkeit während des Graph-Aufbaus, was auf laufende Korrekturen hindeutet. Wer auf Stabilität angewiesen ist, sollte die Release Notes vor jedem Update lesen und die Node-Anforderung ab 22.5 in der CI prüfen.
Redaktionelles Fazit
MEX passt zu Teams, die ohnehin über Git zusammenarbeiten, ihre Kontextdateien reviewen wollen und Node.js ab Version 22.5 im Einsatz haben. Wer einen gehosteten Dienst mit zentraler Suche über viele Repositories oder einen fertigen MCP-Server erwartet, ist hier falsch. Vor der Einführung sollte man klären, ob das Team bereit ist, generierte Markdown-Dateien wie Code zu reviewen, und ob die Node-Version in der CI verfügbar ist. Der erste konkrete Schritt ist ein Testlauf von mex init in einem einzelnen Repository und ein Blick in den erzeugten Projektordner, bevor irgendetwas committet wird.
Community-Notizen