ఎవరూ బాధ్యత వహించకుండా ఒక పెద్ద ప్రాజెక్ట్‌ను ప్లాన్ చేస్తే ఏమవుతుంది? చాలా సాఫ్ట్‌వేర్ స్టాక్‌లు ఒకే ఒక ఆర్కెస్ట్రేటర్ (orchestrator) ఉంటుందని భావిస్తాయి. ఒకే ప్రాసెస్ స్టేట్‌ను కలిగి ఉంటుంది, జాబ్‌లను క్యూ చేస్తుంది మరియు పనులను పంపిణీ చేస్తుంది. ఆ కోఆర్డినేటర్ రీస్టార్ట్ అయితే, మొత్తం వర్క్‌ఫ్లో అస్తవ్యస్తమవుతుంది. ఒక కొత్త ప్రాజెక్ట్ ఈ ఊహను పూర్తిగా మార్చేస్తోంది. ఏ ఒక్క నోడ్ కూడా ఏ సమయంలోనూ పూర్తి ప్లాన్‌ను తన వద్ద ఉంచుకోకుండానే, "జపాన్‌కు రెండు వారాల పర్యటనను ప్లాన్ చేయండి" వంటి లక్ష్యాన్ని ఒక AI ఏజెంట్ల సమూహం (swarm) ఎలా ఒక పూర్తి టాస్క్ ట్రీగా విభజించగలదో ఇది చూపిస్తుంది.

నాయకత్వం లేని వ్యవస్థను (Leaderless System) ఎందుకు నిర్మించాలి?

సెంట్రలైజ్డ్ ప్లానర్‌లను అర్థం చేసుకోవడం సులభం. మీరు సర్వర్‌కు ఒక రిక్వెస్ట్ పంపిస్తారు, అది పనిని విభజిస్తుంది మరియు వర్కర్లు తిరిగి రిపోర్ట్ చేస్తారు. సమస్య ఏమిటంటే, సర్వర్ ఒక మేధోపరమైన (cognitive) మరియు భౌతికమైన (physical) అడ్డంకిగా (bottleneck) మారుతుంది. సత్యం (truth) అంతా దాని వద్దే ఉంటుంది.

డిస్ట్రిబ్యూటెడ్ సెటప్‌లో, సత్యం అనేది నెట్‌వర్క్ 'గసిప్' (gossip) ద్వారా అందరూ కలిసి అర్థం చేసుకునే ఒక ఉమ్మడి చిత్రంగా మారుతుంది. ఈ నిర్దిష్ట Python ఇంప్లిమెంటేషన్ రెండు విభిన్న భావనలను అనుసంధానిస్తుంది. మొదటిది ఇటరేటివ్ రిఫైన్‌మెంట్ లూప్ (iterative refinement loop): ఒక ఏజెంట్ ప్రతిపాదనను రాస్తుంది, మరొకటి దానికి స్కోరు ఇస్తుంది మరియు మూడవది దానిని మెరుగుపరుస్తుంది. రెండవది libp2p పై నిర్మించబడిన పీర్-టు-పీర్ నెట్‌వర్కింగ్ లేయర్, ఇది రిజిస్ట్రీ లేదా లోడ్ బ్యాలెన్సర్ లేకుండా ఏజెంట్లు ఒకరినొకరు స్వయంచాలకంగా కనుగొనేలా చేస్తుంది. దీని ఫలితంగా, ఎవరూ కండక్టర్ పాత్ర పోషించకుండానే పీయర్స్ (peers) ప్రత్యక్షమవుతూ, ప్రతిపాదిస్తూ, ఓటు వేస్తూ మరియు అమలు చేస్తూ ఉండే ఒక క్లస్టర్ ఏర్పడుతుంది.

నాలుగు పాత్రలు

ఈ వ్యవస్థ ప్రతి పాల్గొనేవారికి నాలుగు వ్యక్తిత్వాలలో ఒక దానిని కేటాయిస్తుంది. మీకు నాలుగు భౌతిక యంత్రాలు అవసరం లేదు. అవి ఒకే ల్యాప్‌టాప్‌లో ఉండవచ్చు లేదా హోమ్ నెట్‌వర్క్‌లో విస్తరించి ఉండవచ్చు. ఆ పాత్రలు:

  • Decomposer. ఈ ఏజెంట్ అత్యున్నత స్థాయి లక్ష్యాన్ని అందుకుని, దానిని ఉప-లక్ష్యాలుగా (subgoals) విభజించాలని ప్రతిపాదిస్తుంది. వ్యవస్థలో బహుళ decomposers సమాంతరంగా (parallel) నడుస్తాయి కాబట్టి, ఒకే జపాన్ పర్యటన కోసం మీకు మూడు వేర్వేరు పద్ధతులు రావచ్చు. ఒకటి భౌగోళికంగా: టోక్యో, క్యోటో, ఒసాకా అని విభజించవచ్చు. మరొకటి కార్యకలాపాల ద్వారా: రవాణా, వసతి, భోజనం, పర్యటన అని విభజించవచ్చు. మూడవది రోజువారీ క్రమంలో విభజించవచ్చు. నెట్‌వర్క్ వాటన్నింటినీ పరిగణనలోకి తీసుకుంటుంది.

  • Scorer. ఈ ఏజెంట్లు ఎడిటోరియల్ బోర్డులా పనిచేస్తాయి. అవి ప్రతిపాదించిన విభజనను పరిశీలించి రేటింగ్ ఇస్తాయి. ఉప-లక్ష్యాలు తగినంత స్పష్టంగా ఉన్నాయా, ఒకదానితో ఒకటి కలిసిపోకుండా ఉన్నాయా మరియు సమగ్రంగా ఉన్నాయా అనేది స్కోరు తెలియజేస్తుంది. అంతకంటే ముఖ్యంగా, ఒక ప్రతిపాదనను అంగీకరించడానికి అది సరిపోతుందో లేదో scorer నిర్ణయిస్తుంది. దాని ఆమోదం లేకపోతే, ఆ విభజన అసంపూర్తిగానే మిగిలిపోతుంది.

  • Executor. ట్రీ (tree) అమలు చేయడానికి వీలుగా చిన్న చిన్న లీఫ్ నోడ్స్ (leaf nodes) స్థాయికి చేరుకున్నప్పుడు, executors వాటిని దక్కించుకోవడానికి పోటీ పడతారు. అవి సెంట్రల్ క్యూ నుండి అనుమతి కోసం వేచి ఉండవు. బదులుగా, ఒక పనిని ఎవరు చేయాలి అనేది తేల్చడానికి అవి timestamp protocolను ఉపయోగిస్తాయి. విజేత ఒక లోకల్ LLM కాల్ ద్వారా ఆ పనిని పూర్తి చేసి ఫలితాన్ని బ్రాడ్‌కాస్ట్ చేస్తుంది.

  • Observer. ఇది ప్రతి నెట్‌వర్క్‌కు అవసరమైన ఒక నిశ్శబ్ద పరిశీలకుడు. ఇది గసిప్‌ను నిశ్శబ్దంగా వింటూ, ఆ సంభాషణల నుండి ప్లాన్ ట్రీని పునర్నిర్మిస్తుంది మరియు చదవగలిగే స్నాప్‌షాట్‌ను ప్రింట్ చేస్తుంది. ఇది ఎప్పుడూ మాట్లాడదు కాబట్టి, ఒక ముఖ్యమైన విషయాన్ని నిరూపిస్తుంది: ఆలస్యంగా చేరిన వారు కూడా ఇతరులు మాట్లాడుకోవడం వినడం ద్వారా మొత్తం ప్లాన్‌ను అర్థం చేసుకోవచ్చు.

సత్యానికి మూలంగా గసిప్ (Gossip)

libp2p లేయర్ డిస్కవరీ మరియు మెసేజింగ్‌ను నిర్వహిస్తుంది. ఏజెంట్లు ప్రోటోకాల్ యొక్క బిల్ట్-ఇన్ పీర్ డిస్కవరీ ద్వారా ఒకరినొకరు కనుగొంటారు, ఆపై ఒక ఉమ్మడి టాపిక్‌పై సందేశాలను బ్రాడ్‌కాస్ట్ చేస్తారు. ఇక్కడ రికార్డు కోసం ఎటువంటి డేటాబేస్ లేదా కానానికల్ ప్లాన్‌ను ఉంచే Redis cache ఉండదు.

ప్రతి పీర్ తన వద్ద ప్లాన్ ట్రీ యొక్క స్వంత కాపీని ఉంచుకుంటుంది మరియు తనకు వినిపించే గసిప్ ఆధారంగా దానిని అప్‌డేట్ చేస్తుంది. ఒక decomposer ప్రతిపాదనను బ్రాడ్‌కాస్ట్ చేసినప్పుడు, మిగిలిన ప్రతి నోడ్ దానిని అందుకుని, ఫార్మాట్‌ను ధృవీకరించి, దాని శాఖను (branch) తన లోకల్ ట్రీకి జోడిస్తుంది. Scorers ఓట్లు వేసినప్పుడు, ఆ గణన కూడా అదే విధంగా వ్యాపిస్తుంది. ఒకే పని కోసం ఇద్దరు executors పరస్పర విరుద్ధమైన క్లెయిమ్‌లను చేస్తే, timestamp protocol ఆ సంఘర్షణను పరిష్కరిస్తుంది. నెట్‌వర్క్ ముందుగా వచ్చిన క్లెయిమ్‌ను అంగీకరించి, ఆలస్యంగా వచ్చిన దానిని పక్కన పెడుతుంది.

కాలక్రమేణా, ఆ ట్రీ అసలు లక్ష్యం నుండి అంగీకరించబడిన ఉప-లక్ష్యాల పొరల ద్వారా చిన్న చిన్న పనుల స్థాయికి చేరుకుంటుంది. ఈ ప్రక్రియ బ్లాక్‌చైన్ (blockchain) యొక్క ఏకాభిప్రాయ ప్రక్రియను పోలి ఉంటుంది, అయితే ఇక్కడ పేలోడ్ అనేది నాణేల లెడ్జర్ కాకుండా, ప్రయాణ ప్రణాళిక లేదా సాఫ్ట్‌వేర్ స్పెసిఫికేషన్ (software spec) అవుతుంది.

ఓటింగ్ మరియు అమలు కోసం పోటీ

ప్రజాస్వామ్యం ఖరీదైనది, మరియు ఈ వ్యవస్థ లేటెన్సీ (latency) రూపంలో ఆ ధరను చెల్లిస్తుంది. తగినంత మంది scorers అంగీకరిస్తేనే ఒక విభజన గెలుస్తుంది. మీరు క్లస్టర్‌ను ఎలా కాన్ఫిగర్ చేస్తారనే దానిపై ఆధారపడి, ఆ పరిమితి సాధారణ మెజారిటీ లేదా కఠినమైన కోరం (quorum) కావచ్చు. Decomposers ప్రతిపాదనలు చేయడం ఆపరు, కాబట్టి నెట్‌వర్క్ తరచుగా ఒకేసారి అనేక పోటీ ట్రీలను అంచనా వేస్తుంది. చివరికి ఒకటి అవసరమైన ఓట్లను పొంది, దాని ఉప-లక్ష్యాలు డ్రాఫ్ట్ నుండి అంగీకరించబడినవిగా మారుతాయి.

Executors add another layer of coordination. Because tasks are public on the gossip channel, multiple executors might try to grab the same attractive leaf node. The timestamp protocol acts as a tiebreaker. Each claim carries a monotonic timestamp, and the network honors the earliest one. The loser simply moves on to the next available task. This is crude, but it avoids the need for a centralized scheduler locking rows in a database.

Resilience by Design

The architecture earns its keep when things break. If a decomposer crashes after proposing half the subgoals, the surviving decomposers continue offering splits. The plan does not stall waiting for a respawn. If a scorer drops off the network, the remaining voters can still reach quorum as long as you sized the cluster appropriately.

The real payoff is late joins. A new agent that boots up halfway through does not need a snapshot or a