जेव्हा तुम्ही कोणाकडेही जबाबदारी नसताना एखादा मोठा प्रकल्प आखता, तेव्हा काय होते? बहुतेक सॉफ्टवेअर स्टॅक्स एका सिंगल ऑर्केस्ट्रेटरवर (orchestrator) अवलंबून असतात. एक प्रक्रिया (process) स्थिती (state) राखून ठेवते, कामांच्या रांगा (queues) व्यवस्थापित करते आणि कामे वाटप करते. जर तो समन्वयक (coordinator) रीस्टार्ट झाला, तर संपूर्ण कार्यप्रवाह (workflow) विस्कळीत होतो. एक नवीन प्रकल्प या गृहितकाला पूर्णपणे उलटवून लावतो. तो दाखवून देतो की AI एजंट्सचा एक समूह "जपानची दोन आठवड्यांची सहल आखणे" यांसारख्या ध्येयाचे कोणत्याही एका नोडकडे पूर्ण योजना नसतानाही, पूर्ण टास्क ट्रीमध्ये (task tree) विभाजन कसे करू शकतो.

नेता नसलेली प्रणाली (Leaderless System) का बनवावी?

केंद्रीकृत प्लॅनर्स (Centralized planners) समजून घेणे सोपे असते. तुम्ही सर्व्हरला विनंती पाठवता, तो काम विभागतो आणि वर्कर्स परत अहवाल देतात. समस्या अशी आहे की सर्व्हर संज्ञानात्मक (cognitive) आणि भौतिक अडथळा (bottleneck) बनतो. तोच सर्व सत्याचा मालक असतो.

डिस्ट्रिब्युटेड सेटअपमध्ये, सत्य हे गॉसिपद्वारे (gossip) नेटवर्कमध्ये एक सामायिक चित्र बनते. ही विशिष्ट Python अंमलबजावणी दोन भिन्न संकल्पना एकत्र आणते. पहिली म्हणजे 'इटरेटिव्ह रिफाइनमेंट लूप' (iterative refinement loop): एक एजंट प्रस्ताव लिहितो, दुसरा त्याला गुण देतो आणि तिसरा त्यात सुधारणा करतो. दुसरी म्हणजे libp2p वर आधारित 'पीअर-टू-पीअर नेटवर्किंग लेयर', ज्यामुळे एजंट्स कोणत्याही रजिस्ट्री किंवा लोड बॅलन्सरशिवाय एकमेकांना आपोआप शोधू शकतात. याचा परिणाम असा होतो की, जिथे कोणीही ऑर्केस्ट्रा कंडक्टर म्हणून काम न करता पीअर्स (peers) येतात, प्रस्ताव मांडतात, मतदान करतात आणि अंमलबजावणी करतात.

चार भूमिका (The Four Roles)

ही प्रणाली प्रत्येक सहभागीला चारपैकी एक व्यक्तिमत्व नियुक्त करते. तुम्हाला चार भौतिक मशीनची गरज नाही. ते एका लॅपटॉपवर एकत्र असू शकतात किंवा होम नेटवर्कमध्ये पसरलेले असू शकतात. भूमिका खालीलप्रमाणे आहेत:

  • Decomposer. हा एजंट मुख्य ध्येय स्वीकारतो आणि त्याचे उप-ध्येयांमध्ये (subgoals) विभाजन करण्याचा प्रस्ताव देतो. प्रणाली समांतरपणे अनेक डीकंपोजर्स चालवत असल्याने, तुम्हाला जपानच्या सहलीसाठी तीन वेगवेगळ्या पद्धती मिळू शकतात. एक भौगोलिक विभागणी करू शकतो: टोकियो, क्योटो, ओसाका. दुसरा उपक्रमांनुसार विभागणी करू शकतो: प्रवास, निवास, भोजन, पर्यटन. तिसरा दिवसांनुसार क्रम लावू शकतो. नेटवर्क या सर्वांचा विचार करते.

  • Scorer. हे एजंट्स संपादकीय मंडळाप्रमाणे (editorial board) काम करतात. ते प्रस्तावित विभागणीची तपासणी करतात आणि तिला रेटिंग देतात. स्कोअर हा उप-ध्येय पुरेसे ठोस, एकमेकांशी न जुळणारे आणि एकत्रितपणे सर्वसमावेशक आहेत की नाही हे दर्शवतो. महत्त्वाचे म्हणजे, एखादा प्रस्ताव स्वीकारण्याइतपत चांगला आहे की नाही हे स्कोअरर ठरवतो. त्याच्या परवानगीशिवाय, विभागणी अनिश्चित (limbo) राहते.

  • Executor. एकदा का ट्रीमधील लीफ नोड्स (leaf nodes) कृती करण्यासाठी पुरेसे लहान झाले की, एक्झिक्युटर्स त्यावर ताबा मिळवण्यासाठी स्पर्धा करतात. ते मध्यवर्ती रांगेच्या (central queue) परवानगीची वाट पाहत नाहीत. त्याऐवजी, कामावर कोणाचा हक्क असेल हे ठरवण्यासाठी ते 'टाइमस्टॅम्प प्रोटोकॉल' (timestamp protocol) वापरतात. विजेता स्थानिक LLM कॉलद्वारे काम पूर्ण करतो आणि निकाल प्रसारित करतो.

  • Observer. हे प्रत्येक नेटवर्कला आवश्यक असलेले 'वॉलफ्लॉवर' (wallflower) आहे. ते गॉसिप शांतपणे ऐकते, त्या संवादातून प्लॅन ट्री पुन्हा तयार करते आणि वाचण्यायोग्य स्नॅपशॉट प्रिंट करते. ते कधीही बोलत नसल्यामुळे, एक महत्त्वाचा मुद्दा सिद्ध होतो: जो कोणी उशिरा सामील होईल, तो केवळ ऐकून संपूर्ण योजना समजून घेऊ शकतो.

सत्याचा स्रोत म्हणून गॉसिप (Gossip as the Source of Truth)

libp2p लेयर शोध (discovery) आणि मेसेजिंग हाताळते. एजंट्स प्रोटोकॉलच्या अंगभूत पीअर डिस्कव्हरीद्वारे एकमेकांना शोधतात आणि नंतर एका सामायिक विषयावर (shared topic) संदेश प्रसारित करतात. येथे कोणताही अधिकृत डेटाबेस किंवा अधिकृत योजना साठवणारा Redis कॅशे नाही.

प्रत्येक पीअर प्लॅन ट्रीची स्वतःची प्रत ठेवतो आणि त्याला ऐकलेल्या गॉसिपच्या आधारे अपडेट करतो. जेव्हा एखादा डीकंपोजर प्रस्ताव प्रसारित करतो, तेव्हा इतर प्रत्येक नोड तो प्राप्त करतो, फॉरमॅटची पडताळणी करतो आणि तो भाग आपल्या स्थानिक ट्रीमध्ये जोडतो. जेव्हा स्कोअरर्स मतदान करतात, तेव्हा ती मते देखील त्याच पद्धतीने पसरतात. जर दोन एक्झिक्युटर्सने एकाच कामासाठी परस्परविरोधी दावे केले, तर टाइमस्टॅम्प प्रोटोकॉल तो संघर्ष सोडवतो. नेटवर्क आधीच्या दाव्यावर शिक्कामोर्तब करते आणि उशिरा आलेला दावा बाद करते.

कालांतराने, मूळ ध्येयापासून स्वीकारलेल्या उप-ध्येयांच्या थरांद्वारे ट्री खालीलप्रमाणे वाढत जाते, जोपर्यंत ते लहान कामांपर्यंत पोहोचत नाही. ही प्रक्रिया ब्लॉकचेनप्रमाणे एकमत (consensus) मिळवण्यासारखी आहे, फक्त येथे पेलोड (payload) हा नाण्यांच्या लेजरऐवजी प्रवास वेळापत्रक किंवा सॉफ्टवेअर स्पेसिफिकेशन असतो.

मतदान आणि अंमलबजावणीची स्पर्धा (Voting and the Race to Execute)

लोकशाही महागडी असते आणि ही प्रणाली त्यासाठी लॅटन्सीच्या (latency) स्वरूपात किंमत मोजते. विभागणी तेव्हाच यशस्वी होते जेव्हा पुरेसे स्कोअरर्स सहमत होतात. तुम्ही क्लस्टर कसे कॉन्फिगर करता यावर अवलंबून, ही मर्यादा साधी बहुमताची किंवा अधिक कडक कोरमची (quorum) असू शकते. डीकंपोजर्स प्रस्ताव मांडणे थांबवत नाहीत, त्यामुळे नेटवर्क अनेकदा एकाच वेळी अनेक स्पर्धात्मक ट्रीजचे मूल्यमापन करते. अखेरीस, एक ट्री आवश्यक मते मिळवते आणि त्याची उप-ध्येये मसुद्यातून (draft) स्वीकारलेल्या (accepted) स्थितीत येतात.

एक्झिक्युटर्स समन्वयाचा आणखी एक स्तर जोडतात. गॉसिप चॅनेलवर टास्क सार्वजनिक असल्यामुळे, अनेक एक्झिक्युटर्स एकाच आकर्षक लीफ नोडवर ताबा मिळवण्याचा प्रयत्न करू शकतात. टाइमस्टॅम्प प्रोटोकॉल येथे टायब्रेकर म्हणून काम करतो. प्रत्येक क्लेमसोबत एक मोनोटोनिक टाइमस्टॅम्प असतो आणि नेटवर्क सर्वात आधीच्या क्लेमचा मान राखते. पराभूत झालेला एक्झिक्युटर साध्या पद्धतीने पुढच्या उपलब्ध टास्ककडे वळतो. ही पद्धत प्राथमिक असली तरी, यामुळे डेटाबेसमध्ये रो (rows) लॉक करण्यासाठी लागणाऱ्या केंद्रीकृत शेड्युलरची गरज भासत नाही.

रचनेतील लवचिकता

जेव्हा काही बिघाड होतात, तेव्हा या आर्किटेक्चरची खरी उपयुक्तता सिद्ध होते. जर एखादा डिकंपोजर अर्धे सबगोल्स प्रस्तावित केल्यानंतर क्रॅश झाला, तर उरलेले डिकंपोजर्स स्प्लिट्स ऑफर करणे सुरूच ठेवतात. रिस्पॉनची (respawn) वाट पाहत प्लॅन थांबत नाही. जर एखादा स्कोअरर नेटवर्कमधून बाहेर पडला, तरीही तुम्ही क्लस्टरचा आकार योग्य ठेवला असेल तर उर्वरित व्होटर्स कोरम (quorum) गाठू शकतात.

याचा खरा फायदा 'लेट जॉइन्स'मध्ये आहे. अर्धवट प्रक्रियेदरम्यान सुरू होणाऱ्या नवीन एजंटला स्नॅपशॉट किंवा एका