अभियंत्यांच्या एका टीमने एक 'fail-closed' नेटवर्किंग लेअर सादर केले आहे, जे स्वायत्त AI एजंट्सना सुसंगतता न गमावता क्लाउड सीमांच्या पलीकडे कार्य करण्यास सक्षम करते. या प्रोटोटाइपने ८२ मुद्दाम निर्माण केलेल्या 'chaos cycles' मध्ये स्वतःला सिद्ध केले, ज्यामध्ये सिंगल-इफेक्ट इव्हेंट्ससाठी १००% यश मिळाले आणि वीज पुरवठा खंडित झाल्यावरही डुप्लिकेट अपडेट्स रोखले.

नवीन समन्वय मॉडेल का महत्त्वाचे आहे

अनेक क्लाउड्सवर लँग्वेज-मॉडेल-चालित एजंट्स तैनात केल्यामुळे एक त्रुटी समोर आली: जेव्हा नेटवर्क पार्टीशन होते किंवा एखादी सर्व्हिस कोटा गाठते, तेव्हा मानक RPC कॉल्स कोलमडतात. अशा क्षणी, एखादा एजंट न पडताळलेल्या गृहितकावर आधारित कृती करू शकतो, ज्यामुळे सामायिक स्थिती (shared state) खराब होऊ शकते. नवीन आर्किटेक्चरमध्ये प्रत्येक कृतीला कोणताही घटक स्वीकारण्यापूर्वी क्रिप्टोग्राफिक पुरावा असणे अनिवार्य आहे, ज्यामुळे "बाय डिफॉल्ट विश्वास" (trust by default) चे रूपांतर "केवळ सिद्ध झाल्यावरच विश्वास" (trust only when proved) मध्ये होते.

एजंट्सना सिंकमध्ये ठेवण्याचे पाच गव्हर्नन्स नियम

  1. Transactional ingestion – अ‍ॅटोमिसिटी (atomicity) सुनिश्चित करण्यासाठी सर्व स्टेट चेंजेस एका सिंगल PostgreSQL ट्रान्झॅक्शनमध्ये गुंडाळा.
  2. Canonical envelope – प्रत्येक मेसेजसाठी एक निश्चित १०-ट्युपल (10-tuple) फॉरमॅट वापरा, ज्यामुळे पार्सिंग आणि व्हॅलिडेशन निश्चित (deterministic) होते.
  3. Authority separation – ॲप्लिकेशन कोड Git मध्ये ठेवा आणि डेटाबेस मायग्रेशन्स वेगळे व्हर्जन करा, ज्यामुळे चुकून होणारे क्रॉस-कंटॅमिनेशन टाळता येईल.
  4. Time-bound locks – एखाद्या कार्यावरील दावे (claims) आपोआप कालबाह्य होऊ द्या, जेणेकरून अडकलेला एजंट संपूर्ण पाइपलाइन रोखून धरू शकणार नाही.
  5. Fail-closed default – पडताळणीयोग्य पुरावा नसलेला कोणताही दावा HOLD म्हणून मार्क करा, ज्यामुळे डाउनस्ट्रीम एजंट्सना अंदाज लावण्याऐवजी प्रतीक्षा करणे भाग पडेल.

एकत्रितपणे हे नियम एक 'झिरो-ट्रस्ट कॉन्ट्रॅक्ट' तयार करतात: जर तुम्ही एखादी कृती घडली आहे हे क्रिप्टोग्राफिकली सिद्ध करू शकत नसाल, तर सिस्टम त्यावर कृती करण्यास नकार देते.

पुरावा वाहून नेणारा १०-ट्युपल एन्व्हलप

अंतर्गत बसवरील प्रत्येक हँडऑफमध्ये खालील गोष्टींचा समावेश असतो:

  • event_id – मूळ इव्हेंटसाठी युनिक आयडेंटिफायर
  • effect_id – विनंती केलेल्या स्टेट चेंजचा आयडेंटिफायर
  • log_id – ऑडिट ट्रेल एन्ट्रीचा संदर्भ
  • producer_id – सोर्स एजंटची ओळख
  • schema_version – वापरल्या जाणाऱ्या मेसेज स्कीमाची आवृत्ती
  • session_epoch – सेशनमधील क्रमासाठी लॉजिकल क्लॉक
  • destination – लक्ष्यित एजंट किंवा सर्व्हिस
  • route_status – सध्याची राउटिंग स्थिती (उदा. pending, held)
  • issued_at – निर्मितीचा टाइमस्टॅम्प
  • payload_digest – पेलोडचा HMAC-सील केलेला हॅश

हा डायजेस्ट कोणत्याही क्लाउड वर्कस्पेस फोल्डरच्या बाहेर साठवलेल्या सिक्रेट की (secret key) वापरतो, ज्यामुळे एखादा बाधित कम्प्युट नोड वैध मेसेज तयार करू शकणार नाही याची खात्री मिळते.

ताणतणावाखाली सिस्टमची कामगिरी कशी होती

अभियंत्यांनी ८२ केऑस सायकल चालवल्या. त्याचे परिणाम खालीलप्रमाणे होते:

  • सिंगल इफेक्ट निर्माण करणाऱ्या इव्हेंट्ससाठी १००% यश; ट्रान्झॅक्शन एकतर पूर्णपणे कमिट झाले किंवा स्वच्छपणे रोलबॅक झाले.
  • वीज खंडित असताना शून्य डुप्लिकेट बदल, ज्यामुळे हे सिद्ध झाले की ट्रान्झॅक्शनल बाउंड्रीने अंशतः लेखने (partial writes) रोखली.
  • जलद लॉक रिकव्हरी, स्वायत्त क्लीनअप एजंट्समुळे, ज्यांनी कालबाह्य झालेले दावे स्कॅन केले आणि मानवी हस्तक्षेपाशिवाय ते मुक्त केले.

आर्किटेक्ट्ससाठी व्यावहारिक टिप्स

  • अन-ऑथेंटिकेटेड वेबहुक्सच्या जागी HMAC द्वारे सील केलेले लॉग्स वापरा; हे सील 'fail-closed' नियमासाठी आवश्यक असलेला क्रिप्टोग्राफिक पुरावा म्हणून काम करते.
  • सिक्रेट कीज अशा व्हॉल्टमध्ये साठवा जी कोणत्याही कंटेनर किंवा VM इमेजमध्ये माउंट केलेली नसेल.
  • हलके (lightweight) एजंट्स तैनात करा ज्यांचे एकमेव काम कालबाह्य झालेले लॉक्स काढून टाकणे आहे; यामुळे मुख्य एजंट क्रॅश झाल्यावर सिस्टम थांबण्यापासून वाचते.

पुढे काय पाहावे

हा दृष्टिकोन HMAC कीजच्या गोपनीयतेवर अवलंबून आहे; तुमच्या सिक्रेट कीज क्लाउड वर्कस्पेस फोल्डर्सच्या बाहेर ठेवा.

जर समुदाय या दोन आघाड्यांवर काम करू शकला, तर 'fail-closed' स्वायत्त नेटवर्क्स कोणत्याही अशा मल्टी-एजंट डिप्लॉयमेंटसाठी डीफॉल्ट बनू शकतात, जिथे सुसंगततेच्या एकाही त्रुटीला वाव नाही.