FAVA Trails: Git-natives gemeinsames Gedächtnis für KI-Agenten (MCP)

Für wen es sich eignet

FAVA Trails (Federated Agents Versioned Audit Trail) ist ein Git-natives Gedächtnissystem, das KI-Agenten über MCP bereitgestellt wird: Gedanken, Entscheidungen und Beobachtungen der Agenten werden als Markdown-Dateien mit YAML-Frontmatter in ein Git-Datenrepository geschrieben, das du selbst kontrollierst — nicht in eine Blackbox auf fremden Servern. „Entwürfe“ und „für alle Agenten sichtbare Beobachtungen“ bilden zwei Ebenen mit einer Beförderungsschwelle dazwischen; Agenten sehen normalerweise nur die Gedächtniswerkzeuge selbst und fassen keine Versionsverwaltungsbefehle an — die Versionsverwaltung erledigt die Engine im Repository, und die gesamte Historie bleibt in den Commits nachvollziehbar.

• Passt gut: Teams oder Einzelpersonen, die das Arbeitsgedächtnis mehrerer Agenten teilen und anhäufen wollen — etwa um Ergebnisse technischer Untersuchungen oder Entscheidungskontext über Sitzungen hinweg als wiederverwendbare Beobachtungen zu speichern; Nutzer, die ein versioniertes, nachvollziehbares Gedächtnis wollen, dessen Dateien sich jederzeit direkt ansehen lassen; wer bereits Git nutzt und kein Problem damit hat, ein zusätzliches Datenrepository zu pflegen.
• Voraussetzungen: pip muss lokal installieren können; in der Konfiguration muss der Pfad des Datenrepositorys als FAVA_TRAILS_DATA_REPO angegeben werden; wer einen Entwurf zu einer für alle Agenten sichtbaren Beobachtung befördern will, muss einen OpenRouter-API-Key konfigurieren.
• Gut abwägen: Wer kein Datenrepository pflegen oder keinen OpenRouter-Key beantragen will, sollte gut überlegen, ob dieses Werkzeug passt — der zentrale Pfad des agentenübergreifenden Gemeinschaftsgedächtnisses hängt an beidem zugleich.
• Unbekannt: Die Belege sagen nicht, welche konkreten MCP-Clients unterstützt werden, welche Anforderungen an Betriebssystem und Python-Version bestehen und ob die Storage-Engine Jujutsu (JJ) separat installiert werden muss.

Der erste Versuch in 3 Minuten

Es gibt genau einen empfohlenen Hauptweg: die Engine von PyPI installieren und in die Serverkonfiguration des MCP-Clients eintragen. Zwei Voraussetzungen: Lege zuerst fest, wo das Datenrepository liegen soll, denn FAVA_TRAILS_DATA_REPO in der Konfiguration zeigt dorthin; und für den Schritt der Beförderung brauchst du einen OpenRouter-API-Key.

Schritt eins, diesen zustandslosen MCP-Server unter Apache-2.0-Lizenz installieren:

pip install fava-trails

Schritt zwei, das offizielle Registrierungs-Snippet in die Client-Konfiguration aufnehmen und den Repository-Pfad durch deinen tatsächlichen Speicherort ersetzen:

"fava-trails": {
  "command": "fava-trails-server",
  "env": {
    "FAVA_TRAILS_DATA_REPO": "/path/to/fava-trails-data",
    "OPENROUTER_API_KEY": "sk-or-v1-..."
  }
}

Schritt drei, den Agenten die kleinste denkbare Schreiboperation einmal ausführen lassen: mit save_thought eine Beobachtung als Entwurf speichern.

save_thought(trail_name="myorg/eng/my-project", content="My finding about X", source_type="observation")

Erfolgssignal: Unter dem Verzeichnis drafts/ des Datenrepositorys taucht der Entwurf auf. Die Art des Vorgangs richtig einordnen: Dieser Schritt ist eine lokale Schreiboperation, die Datei landet in deinem eigenen Repository — kein reiner Lesezugriff; eine offizielle Möglichkeit, Entwürfe zu löschen oder zurückzunehmen, ist nicht dokumentiert, schreibe beim ersten Versuch also nur harmlose Inhalte. Engine-seitig läuft Jujutsu (JJ) als Storage-Engine im Colocate-Modus parallel zu Git; das Repository bleibt ein normales Git-Repository, und du musst in diesem Schritt keinen Versionsverwaltungsbefehl anfassen. Beachte zudem die Grenzen des OpenRouter-API-Keys: Er taucht in dieser offiziellen Konfigurationsvorlage bereits auf, und die offizielle Tabelle stellt klar, dass er für propose_truth erforderlich ist und die LLM-Prüfungen des Trust Gates über OpenRouter speist; beim ersten Versuch genügt der Entwurfsschritt — eine Beförderung muss nicht gleich mitkommen.

Anwendungsfälle

Fall eins: das Ergebnis einer Untersuchung als Projektwissen ablegen. Szenario: Ein Agent hat gerade eine Untersuchung abgeschlossen, und das Ergebnis ist in späteren Sitzungen wiederverwendbar. Vorgehen: save_thought mit trail_name, content und source_type aufrufen — der offizielle Beispielaufruf oben funktioniert unverändert. Erwartetes Ergebnis: Im Verzeichnis drafts/ entsteht eine Entwurfsdatei, der Inhalt landet ausschließlich in deinem Repository, andere Agenten sehen ihn noch nicht, niemand wird beeinträchtigt; der Entwurf ist eine gewöhnliche Datei und lässt sich im Repository direkt öffnen.

Fall zwei: einen bestätigten Entwurf zur geteilten Beobachtung befördern und per Suche prüfen. Szenario: Eine Beobachtung ist verifiziert und soll künftig jeder Agent wiederfinden. Vorgehen: zuerst prüfen, dass der OpenRouter-API-Key gültig ist, dann mit propose_truth(trail_name="myorg/eng/my-project", thought_id=thought_id) den Entwurf nach observations/ befördern und anschließend mit recall(trail_name="myorg/eng/my-project", query="X") abrufen. Erwartetes Ergebnis: recall findet den beförderten Gedanken, und andere Agenten am selben Datenrepository finden ihn mit derselben Abfrage. Prüfpunkt: Das Ergebnis der Beförderung ist für alle Agenten sichtbar, ein offizielles Zurücknehmen ist nicht dokumentiert — stelle vor der Ausführung sicher, dass der Inhalt zum Teilen geeignet ist; das Übertragen der Änderung zu einem Remote ist ein eigener, separater Schritt und erfordert zusätzlich den Aufruf des sync-Werkzeugs oder jj git push.

Grenzen der Nutzung

• Lese- und Schreibeigenschaften: save_thought legt einen Entwurf im Datenrepository an, und propose_truth befördert ihn nach observations/, sichtbar für alle Agenten — beides sind Schreibvorgänge; recall findet beförderte Gedanken. Schreibvorgänge passieren in deinem eigenen Repository, und die Beförderung landet zunächst lokal; das Übertragen zu einem Remote muss separat über das sync-MCP-Werkzeug oder jj git push erfolgen, und ob du synchronisierst, entscheidest du. Einen offiziellen Weg zum Rückgängigmachen oder Löschen gibt es nicht — behandle Schreibvorgänge nicht als jederzeit rückholbar.
• Zugangsdaten und Konfiguration: FAVA_TRAILS_DATA_REPO gibt den Ort des Datenrepositorys an, und OPENROUTER_API_KEY dient der LLM-Prüfung bei der Beförderung; beide stehen im env-Abschnitt der offiziellen Konfigurationsvorlage, und die offizielle Dokumentation sagt ausdrücklich, dass letzterer für propose_truth erforderlich ist. Ob save_thought und recall ohne diesen Key funktionieren, sagen die Belege nicht.
• Laufzeitumgebung und Datenhaltung: Die Storage-Engine ist Jujutsu (JJ), im Colocate-Modus parallel zu Git; das Repository bleibt ein normales Git-Repository, GitHub und CI/CD sehen reguläre Commits. Alle Inhalte liegen als Markdown-Dateien mit YAML-Frontmatter in dem Repository, das du kontrollierst.
• Unbestätigt: Kapazitätskontingente, Skalierungsgrenzen über mehrere Repositorys hinweg sowie Details zu Privatsphäre und Datenhaltung fehlen in den Belegen; ebenso wenig sind die Bewertungskriterien des Trust Gates und der Umgang mit Fehlern beschrieben, und auch die Frage, ob jj separat installiert werden muss und welche Clients und Python-Versionen unterstützt werden, bleibt offen. Lies „keine Dokumentation gesehen“ nicht als „kein Risiko“ — bewerte alles, was du schreibst, so, als bliebe es dauerhaft in deinem Repository.