Agora: Git als gemeinsames Gedächtnis für KI-Agenten

Agora erprobt Git als gemeinsames Gedächtnis für autonome Forschungsagenten. Hypothesen, Ergebnisse, Verifikationen und Berichte werden dabei nicht nur in einem Chatverlauf gesammelt, sondern als Beiträge in einem append-only gerichteten azyklischen Graphen abgelegt. Jeder Beitrag ist ein reproduzierbarer Commit; seine Eltern zeigen, auf welchen früheren Arbeiten er aufbaut. Für Unternehmen ist daran weniger die Zahl der Agenten interessant als die Frage, ob sich parallele KI-Arbeit damit nachvollziehbar koordinieren lässt.

Die veröffentlichte Studie berichtet von einem fast zwölf Tage dauernden Versuch mit 13 Sprachmodell-Agenten, ohne feste Aufgabenverteilung und ohne zentralen Planer. Die Agenten veröffentlichten 1.703 Beiträge und verbesserten bei einem Gewichtstransferproblem den Evaluationswert von 3,39 auf 1,899 Bits pro Byte. Außerdem wurden 165 unabhängige Reproduktionen gemeldet, von denen laut Studie keine scheiterte. Diese Zahlen beschreiben genau diesen Versuch; sie belegen keine allgemeine Produktivitätssteigerung für beliebige Forschungs- oder Entwicklungsprozesse.

Warum Git als Agentengedächtnis interessant ist

Klassische Multi-Agent-Systeme teilen häufig eine Datenbank, einen Nachrichtenstrom oder einen verdichteten Kontext. Das kann schnell werden, erschwert aber die Frage, welcher Agent welche Annahme übernommen, geprüft oder verworfen hat. Agora setzt stattdessen auf eine bekannte Versionslogik: Ein Commit enthält den Beitrag, Elternkanten dokumentieren die Herkunft und ein abgeleiteter Index macht offene Forschungsfronten, vernachlässigte Zweige und Verifikationsstände sichtbar.

Daraus lässt sich ein praktischer Vorteil ableiten: Agenten können vorhandene Ergebnisse gezielt weiterführen oder reproduzieren, statt jede Sitzung bei null zu beginnen. Gleichzeitig bleibt die Entwicklung einer Idee entlang ihrer Vorgänger prüfbar. Der Ansatz eignet sich deshalb eher für lang laufende, hypothesengetriebene Arbeit als für kurze Standardautomationen, bei denen ein einfacher Workflow und eine normale Auditspur genügen.

Git allein macht Ergebnisse allerdings nicht unveränderlich. Repository-Administratoren können Historien umschreiben, Referenzen löschen oder Zugriffsregeln ändern. Ein Unternehmenseinsatz braucht daher geschützte Hauptreferenzen, signierte Beiträge, unveränderliche Backups, getrennte Rollen und eine Protokollierung administrativer Eingriffe. Der Commit-Hash macht Manipulationen erkennbar; die organisatorische Kontrolle verhindert sie.

Ein Commit-Vertrag für reproduzierbare Agentenarbeit

Bevor mehrere Agenten autonom arbeiten, sollte das Team festlegen, was ein gültiger Forschungsbeitrag enthalten muss. Sonst erzeugt das System zwar viel Aktivität, aber keinen wiederverwendbaren Wissensstand. Ein minimaler Commit-Vertrag schafft einheitliche Übergaben und ermöglicht automatische Qualitätsprüfungen.

• Beitragstyp: Hypothese, Experiment, Ergebnis, Reproduktion, Widerlegung oder Bericht.
• Ausgangslage: eindeutige Eltern-Commits sowie die konkrete Frage, auf die der Beitrag reagiert.
• Ausführung: Modell- und Toolversionen, Parameter, verwendete Daten, Code und reproduzierbarer Startbefehl.
• Ergebnis: vorab definierte Metrik, Rohartefakte und eine sprachlich getrennte Interpretation.
• Prüfstatus: ungeprüft, technisch reproduziert, fachlich bestätigt oder verworfen.
• Kostenbezug: Laufzeit, Rechenverbrauch, Wiederholungen und notwendige menschliche Prüfzeit.

Dieser Vertrag sollte maschinenlesbar sein. Ein Agent darf nur auf bestätigten Ergebnissen aufbauen, wenn der Prozess dies verlangt; explorative Zweige bleiben möglich, werden aber sichtbar markiert. Fehlgeschlagene Experimente gehören ebenfalls in den Graphen. Gerade negative Ergebnisse verhindern, dass andere Agenten dieselbe Sackgasse erneut teuer untersuchen.

Vier Stufen für einen kontrollierten Unternehmenspilot

1. Aufgabe eingrenzen: Eine intern überprüfbare Optimierungs- oder Analysefrage mit eindeutiger Metrik wählen. Produktivdaten, Kundenauswirkungen und irreversible Aktionen zunächst ausschließen.
2. Vergleich aufsetzen: Einen Agentenlauf mit gemeinsamem Git-Zustand gegen getrennte Läufe mit demselben Rechenbudget testen. Nicht die Zahl der Beiträge, sondern beste bestätigte Lösung, Duplikationsquote, Zeit bis zur Reproduktion und Kosten pro Fortschritt vergleichen.
3. Diversität steuern: Sichtbar machen, welche Zweige zu viel Aufmerksamkeit erhalten. Budgets für alternative Hypothesen reservieren und ein menschliches Eingriffskriterium definieren, falls die Agenten auf einen Ansatz konvergieren.
4. Betrieb entscheiden: Nur skalieren, wenn das gemeinsame Gedächtnis nachweisbar bessere oder günstigere bestätigte Ergebnisse liefert. Andernfalls die Agentenzahl reduzieren, den Commit-Vertrag schärfen oder beim einfacheren Einzelagenten-Prozess bleiben.

Die Diversitätskontrolle ist kein Nebenthema. Der Studienbericht erwähnt eine menschliche Intervention während des Laufs, um die Gemeinschaft aus einer Monokultur zu lösen. Daraus folgt kein allgemeines Versagen dezentraler Agenten, wohl aber eine klare Betriebsanforderung: Ein System ohne zentralen Planer braucht trotzdem beobachtbare Konvergenzsignale, Eingriffsrechte und ein dokumentiertes Verfahren für Kurskorrekturen.

Kosten, Risiken und Freigaben richtig trennen

Für die Wirtschaftlichkeit zählt die Entdeckungsleistung pro eingesetzter Ressource. Dazu gehören Modellaufrufe, Ausführungsumgebungen, Speicher, Reproduktionen und menschliche Kontrolle. Ein gemeinsamer Zustand kann doppelte Arbeit senken, aber auch zusätzliche Verifikation und Verwaltung erzeugen. Ein belastbarer Pilot misst beide Seiten und begrenzt gleichzeitig parallele Läufe, maximale Versuchsdauer und zulässige Toolrechte.

• Agenten erhalten nur die Daten, Repositories und Rechenressourcen, die ihre Rolle benötigt.
• Fremde Commits und eingebettete Inhalte gelten als untrusted und dürfen keine Berechtigungsänderungen auslösen.
• Reproduktionen laufen in isolierten Umgebungen mit fixierten Abhängigkeiten und kontrolliertem Netzwerkzugriff.
• Eine erfolgreiche Wiederholung bestätigt technische Reproduzierbarkeit, nicht automatisch fachliche Richtigkeit oder geschäftlichen Nutzen.
• Ergebnisse mit Sicherheits-, Kunden- oder Finanzwirkung benötigen eine unabhängige menschliche Freigabe.
• Abbruchgrenzen für Kosten, wiederholte Fehlschläge und stagnierende Metriken werden vor dem Start festgelegt.

Agora liefert damit ein interessantes Muster für nachvollziehbare kollektive Agentenarbeit, aber noch keinen pauschalen Business Case. Der richtige nächste Schritt ist kein großer autonomer Forschungsverbund. Es ist ein begrenzter Vergleich, der dieselbe Aufgabe mit und ohne gemeinsamen Git-Zustand bearbeitet. Erst wenn bestätigte Ergebnisse pro Euro oder Rechenstunde besser werden und die Auditspur den Prüfaufwand tatsächlich senkt, trägt die Architektur einen breiteren Einsatz.