Was passiert, wenn man ein großes Projekt plant, ohne dass jemand die Verantwortung trägt? Die meisten Software-Stacks setzen einen einzelnen Orchestrator voraus. Ein Prozess hält den Zustand, stellt Warteschlangen bereit und verteilt Aufgaben. Wenn dieser Koordinator neu startet, gerät der gesamte Workflow ins Stocken. Ein neues Projekt stellt diese Annahme völlig auf den Kopf. Es zeigt, wie ein Schwarm von KI-Agenten ein Ziel wie „Plane eine zweiwöchige Reise nach Japan“ in einen vollständigen Aufgabenbaum zerlegen kann, ohne dass zu irgendeinem Zeitpunkt ein einzelner Knoten den vollständigen Plan hält.

Warum ein führungsloses System bauen?

Zentralisierte Planer sind leicht nachvollziehbar. Man sendet eine Anfrage an einen Server, dieser teilt die Arbeit auf, und die Worker melden sich zurück. Das Problem ist, dass der Server zu einem kognitiven und physischen Flaschenhals wird. Er besitzt die Wahrheit.

In einem verteilten Setup wird die Wahrheit zu einem gemeinsamen Bild, auf das sich das Netzwerk durch Gossip-Protokolle einigt. Diese spezifische Python-Implementierung verknüpft zwei unterschiedliche Konzepte. Das erste ist eine iterative Verfeinerungsschleife: Ein Agent erstellt einen Vorschlag, ein anderer bewertet ihn und ein dritter poliert ihn. Das zweite ist eine Peer-to-Peer-Netzwerkschicht, die auf libp2p basiert und es den Agenten ermöglicht, sich automatisch ohne Registry oder Load Balancer zu finden. Das Ergebnis ist ein Cluster, in dem Peers erscheinen, Vorschläge machen, abstimmen und ausführen, ohne dass jemand als Dirigent fungiert.

Die vier Rollen

Das System weist jedem Teilnehmer eine von vier Persönlichkeiten zu. Sie benötigen keine vier physischen Maschinen. Sie können auf einem Laptop koexistieren oder über ein Heimnetzwerk verteilt sein. Die Rollen sind:

  • Decomposer. Dieser Agent erhält das übergeordnete Ziel und schlägt eine Aufteilung in Teilziele vor. Da das System mehrere Decomposer parallel ausführt, erhalten Sie möglicherweise drei verschiedene Rezepte für dieselbe Japanreise. Einer könnte die Reise geografisch aufteilen: Tokio, Kyoto, Osaka. Ein anderer könnte nach Aktivitäten trennen: Transport, Unterkunft, Verpflegung, Besichtigungen. Ein dritter könnte nach Tagen sequenzieren. Das Netzwerk berücksichtigt alle Vorschläge.

  • Scorer. Diese Agenten fungieren als Redaktionsbeirat. Sie prüfen eine vorgeschlagene Aufteilung und bewerten sie. Ein Score spiegelt wider, ob die Teilziele konkret genug, nicht überlappend und kollektiv erschöpfend sind. Wichtiger noch: Ein Scorer entscheidet, ob ein Vorschlag gut genug ist, um akzeptiert zu werden. Ohne seinen Segen bleibt eine Aufteilung im Schwebezustand.

  • Executor. Sobald der Baum Blätter erreicht, die klein genug für eine Ausführung sind, versuchen die Executor, diese zu beanspruchen. Sie warten nicht auf die Erlaubnis einer zentralen Warteschlange. Stattdessen nutzen sie ein Zeitstempel-Protokoll, um zu klären, wer den Zuschlag für eine Aufgabe erhält. Der Gewinner führt den Job über einen lokalen LLM-Aufruf aus und überträgt das Ergebnis.

  • Observer. Dies ist der stille Beobachter, den jedes Netzwerk braucht. Er hört leise dem Gossip zu, rekonstruiert den Planbaum aus dem Geplapper und gibt einen lesbaren Snapshot aus. Da er nie spricht, beweist er einen wichtigen Punkt: Jeder, der später beitritt, kann den gesamten Plan allein durch Zuhören verstehen.

Gossip als Quelle der Wahrheit

Die libp2p-Schicht übernimmt die Entdeckung und die Nachrichtenübermittlung. Agenten finden sich über die integrierte Peer-Discovery des Protokolls und senden dann Nachrichten an ein gemeinsames Topic. Es gibt keine Datenbank als Referenz, keinen Redis-Cache, der den kanonischen Plan hält.

Jeder Peer behält seine eigene Kopie des Planbaums und aktualisiert sie basierend auf dem Gossip, den er hört. Wenn ein Decomposer einen Vorschlag überträgt, erhält jeder andere Knoten diesen, validiert das Format und fügt den Zweig seinem lokalen Baum hinzu. Wenn Scorer ihre Stimmen abgeben, verbreitet sich die Auszählung auf die gleiche Weise. Wenn zwei Executor widersprüchliche Ansprüche auf dieselbe Aufgabe erheben, löst das Zeitstempel-Protokoll die Kollision auf. Das Netzwerk entscheidet sich für den früheren Anspruch und verwirft den späteren.

Mit der Zeit wächst der Baum vom ursprünglichen Ziel durch Schichten akzeptierter Teilziele nach unten, bis er kleinteilige Aufgaben erreicht. Der Prozess ähnelt der Konsensfindung einer Blockchain, nur dass die Nutzlast ein Reiseplan oder eine Software-Spezifikation ist und kein Kassenbuch für Münzen.

Abstimmung und das Rennen zur Ausführung

Demokratie ist teuer, und dieses System zahlt den Preis in Form von Latenz. Eine Aufteilung gewinnt nur, wenn genügend Scorer zustimmen. Diese Schwelle könnte eine einfache Mehrheit oder ein strengeres Quorum sein, je nachdem, wie Sie den Cluster konfigurieren. Die Decomposer hören nicht auf, Vorschläge zu machen, sodass das Netzwerk oft mehrere konkurrierende Bäume gleichzeitig auswertet. Schließlich erreicht einer die erforderlichen Stimmen, und seine Teilziele werden vom Entwurf zum akzeptierten Plan.

Executors fügen eine weitere Ebene der Koordination hinzu. Da Aufgaben im Gossip-Channel öffentlich sind, versuchen möglicherweise mehrere Executors, denselben attraktiven Leaf-Node zu beanspruchen. Das Zeitstempel-Protokoll fungiert dabei als Tiebreaker. Jeder Anspruch trägt einen monotonen Zeitstempel, und das Netzwerk akzeptiert den frühesten. Der Verlierer geht einfach zum nächsten verfügbaren Task über. Das ist zwar eine einfache Lösung, vermeidet aber die Notwendigkeit eines zentralisierten Schedulers, der Zeilen in einer Datenbank sperrt.

Resilienz durch Design

Die Architektur bewährt sich, wenn Fehler auftreten. Wenn ein Decomposer abstürzt, nachdem er die Hälfte der Teilziele vorgeschlagen hat, bieten die verbleibenden Decomposer weiterhin Splits an. Der Plan stockt nicht, während man auf einen Neustart wartet. Wenn ein Scorer aus dem Netzwerk ausfällt, können die verbleibenden Voter immer noch ein Quorum erreichen, sofern der Cluster angemessen dimensioniert wurde.

Der eigentliche Vorteil sind Late Joins. Ein neuer Agent, der mitten im Prozess hochfährt, benötigt keinen Snapshot oder einen