Wat gebeurt er als je een groot project plant zonder dat er iemand de leiding heeft? De meeste softwarestacks gaan uit van een enkele orchestrator. Eén p

Wat gebeurt er als je een groot project plant zonder dat er iemand de leiding heeft? De meeste softwarestacks gaan uit van een enkele orchestrator. Eén proces beheert de status, zet taken in een wachtrij en verdeelt de taken. Als die coördinator opnieuw opstart, wankelt de hele workflow. Een nieuw project draait die aanname volledig om. Het laat zien hoe een zwerm AI-agenten een doel zoals "plan een tweeweekse reis naar Japan" kan opdelen in een volledige taakboom, zonder dat één enkele node op enig moment het volledige plan in bezit heeft.

Waarom een leiderloos systeem bouwen?

Gecentraliseerde planners zijn eenvoudig te begrijpen. Je stuurt een verzoek naar een server, deze verdeelt het werk en de werkers rapporteren terug. Het probleem is dat de server een cognitieve en fysieke bottleneck wordt. Het bezit de waarheid.

In een gedistribueerde opzet verandert de waarheid in een gedeeld beeld waar het netwerk op convergeert via gossip. Deze specifieke Python-implementatie koppelt twee verschillende concepten aan elkaar. Het eerste is een iteratieve verfijningslus: één agent schrijft een voorstel, een ander beoordeelt het en een derde polijst het. Het tweede is een peer-to-peer netwerklaag gebouwd op libp2p, waardoor agenten elkaar automatisch kunnen ontdekken zonder een register of een load balancer. Het resultaat is een cluster waarin peers verschijnen, voorstellen doen, stemmen en uitvoeren zonder dat iemand de dirigent speelt.

De vier rollen

Het systeem wijst aan elke deelnemer een van de vier persoonlijkheden toe. Je hebt geen vier fysieke machines nodig. Ze kunnen samen bestaan op één laptop of verspreid zijn over een thuisnetwerk. De rollen zijn:

• Decomposer. Deze agent ontvangt het hoofddoel en stelt een onderverdeling in subdoelen voor. Omdat het systeem meerdere decomposers parallel laat draaien, kun je drie verschillende recepten krijgen voor dezelfde Japan-reis. De ene zou de reis kunnen onderverdelen op basis van geografie: Tokyo, Kyoto, Osaka. Een andere zou kunnen splitsen op basis van activiteit: transport, accommodatie, dineren, sightseeing. Een derde zou de volgorde per dag kunnen bepalen. Het netwerk overweegt ze allemaal.

• Scorer. Deze agenten fungeren als de redactieraad. Ze inspecteren een voorgestelde onderverdeling en beoordelen deze. Een score weerspiegelt of de subdoelen concreet genoeg zijn, elkaar niet overlappen en gezamenlijk allesomvattend zijn. Belangrijker nog: een scorer beslist of een voorstel goed genoeg is om te accepteren. Zonder zijn zegen blijft een onderverdeling in limbo.

• Executor. Zodra de boom leaf nodes bereikt die klein genoeg zijn om uit te voeren, racen executors om deze op te eisen. Ze wachten niet op toestemming van een centrale wachtrij. In plaats daarvan gebruiken ze een timestamp-protocol om te bepalen wie de taak krijgt. De winnaar voert de taak uit via een lokale LLM-aanroep en verzendt het resultaat via een broadcast.

• Observer. Dit is de stille toeschouwer die elk netwerk nodig heeft. Het luistert stilzwijgend naar de gossip, reconstrueert de planboom uit het geklets en print een leesbaar overzicht. Omdat het nooit spreekt, bewijst het een belangrijk punt: iedereen die later aansluit, kan het volledige plan achterhalen door simpelweg mee te luisteren.

Gossip als de bron van waarheid

De libp2p-laag regelt de ontdekking en berichtgeving. Agenten vinden elkaar via de ingebouwde peer discovery van het protocol en verzenden vervolgens berichten naar een gedeeld onderwerp. Er is geen officiële database, geen Redis-cache die het canonieke plan bijhoudt.

Elke peer houdt een eigen kopie van de planboom bij en werkt deze bij op basis van de gossip die hij hoort. Wanneer een decomposer een voorstel broadcast, ontvangt elke andere node dit, valideert het formaat en voegt de tak toe aan de lokale boom. Wanneer scorers stemmen uitbrengen, verspreidt de telling zich op dezelfde manier. Als twee executors tegenstrijdige claims voor dezelfde taak publiceren, lost het timestamp-protocol de botsing op. Het netwerk beslist op basis van de eerdere claim en verwerpt de latere.

Na verloop van tijd groeit de boom naar beneden vanuit het oorspronkelijke doel, door lagen van geaccepteerde subdoelen, totdat deze hapklare taken bereikt. Het proces lijkt op een blockchain die consensus bereikt, behalve dat de payload een reisroute of een software-specificatie is in plaats van een grootboek van munten.

Stemmen en de race naar uitvoering

Democratie is duur, en dit systeem betaalt de prijs in latentie. Een onderverdeling wint alleen als genoeg scorers het ermee eens zijn. Die drempel kan een gewone meerderheid zijn of een strikter quorum, afhankelijk van hoe je de cluster configureert. De decomposers stoppen niet met voorstellen, waardoor het netwerk vaak meerdere concurrerende bomen tegelijk evalueert. Uiteindelijk haalt er één de vereiste stemmen en gaan de subdoelen van concept naar geaccepteerd.

Executors voegen een extra laag coördinatie toe. Omdat taken openbaar zijn op het gossip-kanaal, kunnen meerdere executors proberen hetzelfde aantrekkelijke leaf node te grijpen. Het timestamp-protocol fungeert als tiebreaker. Elke claim bevat een monotoon timestamp, en het netwerk erkent de vroegste. De verliezer gaat simpelweg door naar de volgende beschikbare taak. Dit is een ruwe methode, maar het voorkomt de noodzaak voor een centrale scheduler die rijen in een database vergrendelt.

Veerkracht door ontwerp

De architectuur bewijst zijn waarde wanneer er iets misgaat. Als een decomposer crasht nadat hij de helft van de subdoelen heeft voorgesteld, blijven de overgebleven decomposers splits aanbieden. Het plan loopt niet vast in afwachting van een respawn. Als een scorer uit het netwerk valt, kunnen de resterende stemmers nog steeds een quorum bereiken, mits de cluster op de juiste manier is gedimensioneerd.

De echte winst zit in late joins. Een nieuwe agent die halverwege opstart, heeft geen snapshot of een