माझ्या AI एजंट्सनी आमच्या टीम चॅटमध्ये निकाल पोस्ट केले. एका माणसाने उत्तर दिले आणि दुसरा एजंट पहिल्या मेसेजची माहिती नसतानाच मध्येच शिरला. या गोंधळामुळे संदर्भाचा अभाव, कामाची पुनरावृत्ती आणि थेट चुका झाल्या. विद्यमान मेमरी सर्व्हर आणि मॉनिटरिंग स्टॅकमध्ये एक हलका Inter-Agent Communication Protocol (IACP) जोडल्यानंतर, ही गोंधळाची स्थिती थांबली आणि वर्कफ्लो अधिक सुटसुटीत झाला.

ही समस्या का महत्त्वाची होती

प्रोडक्शनमध्ये, AI एजंट्स आता केवळ विलग प्रयोग राहिलेले नाहीत; ते डेटा मिळवणे, कोड तयार करणे किंवा डिप्लॉयमेंट ट्रिगर करणे यांसारखी कामे करणाऱ्या मायक्रो-सर्विसेसप्रमाणे (micro-services) काम करतात. जेव्हा प्रत्येक एजंट फक्त मानवांशी संवाद साधतो, तेव्हा जबाबदाऱ्यांची ओव्हरलॅपिंग ही एक छुपी 'रेस कंडिशन' (race condition) बनते. स्लॅकचा (Slack) एक साधा मेसेज निरुपद्रवी वाटू शकतो, परंतु डेव्हलपर्सना परस्परविरोधी आउटपुट्स समजून घेण्यास वेळ वाया जातो, दोन बॉट्स एकाच रिपॉझिटरीमध्ये बदल करण्याचा प्रयत्न केल्यास पाइपलाइन थांबते आणि ऑटोमेशनवरील विश्वास कमी होतो.

हरवलेली दुवा: रिअल-टाइम शेअरड स्टेट (real-time shared state)

बहुतेक टीम्स एजंट्सना 'ब्लॅक बॉक्स' मानतात, जे फक्त प्रॉम्प्ट स्वीकारतात आणि निकाल देतात, असे गृहीत धरतात की प्रॉम्प्टमध्ये सर्व आवश्यक संदर्भ असतो. वास्तविकतेत, एजंट्स एका अशा वर्कस्पेसमध्ये काम करतात जिथे स्थिती (state) सतत बदलत असते: एखादे रिपॉझिटरी लॉक असू शकते, एखादी सर्व्हिस डाऊन असू शकते किंवा एखादे विश्लेषण नुकतेच पूर्ण झाले असू शकते. ब्रॉडकास्ट मेकॅनिझमशिवाय, प्रत्येक बॉट जुन्या किंवा कालबाह्य माहितीच्या (stale snapshot) आधारे काम करतो.

विद्यमान टूल्सवर आधारित IACP ची उभारणी

एक नवीन प्लॅटफॉर्म तयार करण्याऐवजी, मी संभाषणाचा इतिहास साठवणारा मेमरी सर्व्हर आणि एजंटच्या आरोग्याचा मागोवा घेणारी मॉनिटरिंग सुईट (monitoring suite) विस्तारित केली. हा प्रोटोकॉल पाच ठोस क्षमता जोडतो:

  • स्ट्रक्चर्ड आयडेंटिटी (Structured Identity) – प्रत्येक आउटबाउंड मेसेजमध्ये claude@greenmac:8f3a2c सारखा एक युनिक आयडेंटिफायर असतो. या फॉरमॅटमुळे मेसेज कोणी आणि कोणत्या इन्स्टन्सवरून पाठवला आहे हे त्वरित समजते, ज्यामुळे 'बॉट असे म्हणतोय' यांसारख्या संदिग्ध विधानांची गरज उरत नाही.

  • हिस्ट्री इंजेक्शन (History Injection) – उत्तर देण्यापूर्वी, बॉट इतर एजंट्सचे मेसेजसह अलीकडील चॅटचा भाग घेतो आणि तो आपल्या प्रॉम्प्टमध्ये जोडतो. यामुळे संदर्भ कधीही हरवत नाही आणि मॉडेलला त्याच्या सहकाऱ्यांनी आधी काय योगदान दिले आहे यावर विचार करता येते.

  • स्टेट ट्रान्झिशन्स (State Transitions) – एजंट्स वारंवार हार्टबीट्स (heartbeats) पाठवणे थांबवतात. त्याऐवजी, जेव्हा त्यांची अंतर्गत स्थिती बदलते तेव्हा ते स्थिती बदल दर्शवतात—working, blocked, किंवा idle. यामुळे वापरकर्ते त्वरित प्रतिसाद देऊ शकतात, उदाहरणार्थ, अपस्ट्रीम एजंट idle असल्याचे कळवल्यानंतरच एखादे अवलंबून असलेले कार्य रांगेत (queue) ठेवले जाते.

  • अॅडव्हायझरी लीजेस (Advisory Leases) – जेव्हा एखाद्या एजंटला एखाद्या रिसोर्सचा (उदा. रिपो, API एंडपॉइंट, कॉम्प्युट नोड) अनन्य अधिकार हवा असतो, तेव्हा तो TTL (time-to-live) सह लीज क्लेम करतो. जर एजंट क्रॅश झाला, तर लीज आपोआप संपते, ज्यामुळे तो रिसोर्स इतरांसाठी मोकळा होतो आणि दोन बॉट्स एकमेकांच्या कामात अडथळा आणत नाहीत.

  • इनबॉक्स मेकॅनिझम (Inbox Mechanism) – जर इनबॉक्समध्ये न वाचलेले मेसेज असतील, तर एक 'स्टॉप हुक' (stop hook) एजंटचा वर्कफ्लो थांबवतो. एजंटला आपले सध्याचे कार्य पूर्ण करण्यापूर्वी ते मेसेज प्रोसेस करावे लागतात, ज्यामुळे प्रलंबित समन्वय संकेत (coordination signals) दुर्लक्षित होणार नाहीत याची खात्री होते.

हे सर्व घटक मिळून एक साधा, ऑब्झर्व्हेबल कम्युनिकेशन लेयर तयार करतात जो प्रत्येक सहभागीला एकाच माहितीवर अपडेट ठेवतो.

ज्या टीम्स याकडे दुर्लक्ष करतात त्यांच्यासाठी धोके

जर एखादी टीम केवळ तात्पुरते प्रॉम्प्ट्स आणि मॅन्युअल मॉनिटरिंगवर अवलंबून राहिली, तर छुपे खर्च वाढत जातात:

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

एजंट्स आपली ओळख, स्थिती आणि रिसोर्स क्लेम्स कसे जाहीर करतात याचे प्रमाणीकरण करून, IACP कोणत्याही जड ऑर्केस्ट्रेशन इंजिनची गरज न पडता हे धोके कमी करते.

काउंटर-पॉइंट: वाढलेला ओव्हरहेड

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

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

हा प्रोटोकॉल सध्या प्रोटोटाइप स्वरूपात आहे, परंतु त्याचे मॉड्युलर स्वरूप कोणत्याही लँग्वेज-अॅग्नोस्टिक (language-agnostic) एजंट फ्रेमवर्कसोबत इंटिग्रेशनसाठी खुले आहे. संभाव्य पुढील पावले खालीलप्रमाणे असू शकतात:

  • एक हलके SDK प्रकाशित करणे, जेणेकरून डेव्हलपर्स मूळ लॉजिकमध्ये कोणताही बदल न करता पाच हुक्स जोडू शकतील.
  • मॉनिटरिंग सूटमध्ये असे मेट्रिक्स जोडणे जे स्टेट ट्रान्झिशन्स (state transitions) आणि लीज चर्न (lease churn) दृश्यमान करतील, ज्यामुळे टीम्सना अडथळे (bottlenecks) शोधण्यास मदत होईल.
  • पॉलिसी लेयर्ससोबत (policy layers) प्रयोग करणे, जे हाय-ट्रॅफिक परिस्थितीत इतर एजंट्सच्या तुलनेत काही विशिष्ट एजंट्सच्या लीजेसना (leases) आपोआप प्राधान्य देतील.

जर या विस्तारणांना (extensions) लोकप्रियता मिळाली, तर IACP हे वेब सर्व्हिसेससाठी HTTP प्रमाणेच मल्टी-एजंट प्रोडक्शन पाइपलाइनसाठी एक 'डी-फॅक्टो' मानक बनू शकते.

निष्कर्ष: नियमांचा एक छोटा संच—कोण बोलत आहे, अलीकडील संभाषण कसे आहे, एजंटची स्थिती कधी बदलते, कोणाकडे रिसोर्स आहे आणि काही मेसेज प्रलंबित आहेत का—यामुळे AI एजंट्समधील संवादातील गोंधळ थांबवता येईल आणि एका गोंगाटपूर्ण चॅटरुमचे रूपांतर एका विश्वासार्ह समन्वय चॅनेलमध्ये करता येईल.