मेरे AI एजेंट्स ने हमारी टीम चैट में परिणाम पोस्ट किए। एक इंसान ने जवाब दिया, और एक दूसरा एजेंट बिना पहला मैसेज देखे ही बीच में कूद पड़ा। इस वजह से संदर्भ (context) छूट गया, काम दोहराया गया और स्पष्ट गलतियाँ हुईं। मौजूदा मेमोरी सर्वर और मॉनिटरिंग स्टैक में एक हल्का Inter-Agent Communication Protocol (IACP) जोड़ने के बाद, यह समस्या समाप्त हो गई और वर्कफ़्लो सुव्यवस्थित हो गया।

यह समस्या महत्वपूर्ण क्यों थी

प्रोडक्शन में, AI एजेंट्स अब केवल अलग-थलग प्रयोग नहीं रह गए हैं; वे माइक्रो-सर्विसेज की तरह काम करते हैं जो डेटा प्राप्त करते हैं, कोड जनरेट करते हैं, या डिप्लॉयमेंट ट्रिगर करते हैं। जब प्रत्येक एजेंट केवल इंसानों से बात करता है, तो ओवरलैपिंग जिम्मेदारियां एक छिपी हुई 'रेस कंडीशन' (race condition) बन जाती हैं। एक मामूली स्लैक (Slack) मैसेज हानिरहित लग सकता है, लेकिन डेवलपर्स विरोधाभासी आउटपुट को सुलझाने में मिनटों बर्बाद कर देते हैं, जब दो बॉट्स एक ही रिपॉजिटरी को एडिट करते हैं तो पाइपलाइन रुक जाती है, और ऑटोमेशन पर भरोसा कम होने लगता है।

कमी कहाँ थी: रियल-टाइम साझा स्थिति (shared state)

अधिकांश टीमें एजेंट्स को "ब्लैक बॉक्स" की तरह मानती हैं जो एक प्रॉम्प्ट प्राप्त करते हैं और परिणाम देते हैं, यह मानकर कि प्रॉम्प्ट में सभी आवश्यक संदर्भ शामिल हैं। वास्तव में, एजेंट्स एक साझा वर्कस्पेस साझा करते हैं जहाँ स्थिति (state) लगातार बदलती रहती है: एक रिपॉजिटरी लॉक हो सकती है, कोई सर्विस डाउन हो सकती है, या पिछला विश्लेषण अभी-अभी समाप्त हुआ हो सकता है। ब्रॉडकास्ट मैकेनिज्म के बिना, प्रत्येक बॉट एक पुराने स्नैपशॉट (stale snapshot) के आधार पर काम करता है।

मौजूदा टूल्स के ऊपर IACP का निर्माण

एक बिल्कुल नया प्लेटफॉर्म बनाने के बजाय, मैंने उस मेमोरी सर्वर का विस्तार किया जो बातचीत का इतिहास संग्रहीत करता है और उस मॉनिटरिंग सुइट का जो एजेंट के स्वास्थ्य (health) को ट्रैक करता है। यह प्रोटोकॉल पाँच ठोस क्षमताएँ जोड़ता है:

  • स्ट्रक्चर्ड आइडेंटिटी (Structured Identity) – प्रत्येक आउटबाउंड मैसेज में एक विशिष्ट पहचानकर्ता होता है जैसे कि claude@greenmac:8f3a2c। यह फॉर्मेट तुरंत प्राप्तकर्ता को बताता है कि मैसेज किसने और किस इंस्टेंस से भेजा है, जिससे अस्पष्ट "बॉट ने X कहा" जैसे बयानों की समस्या खत्म हो जाती है।

  • हिस्ट्री इंजेक्शन (History Injection) – जवाब देने से पहले, एक बॉट हाल के चैट सेगमेंट को खींचता है, जिसमें अन्य एजेंट्स के मैसेज भी शामिल होते हैं, और उसे अपने प्रॉम्प्ट के साथ जोड़ देता है। संदर्भ कभी नहीं खोता, और मॉडल यह समझ सकता है कि उसके साथियों ने पहले ही क्या योगदान दिया है।

  • स्टेट ट्रांज़िशन (State Transitions) – एजेंट्स बार-बार हार्टबीट (heartbeats) भेजना बंद कर देते हैं। इसके बजाय, वे स्थिति परिवर्तन—working, blocked, या idle—पोस्ट करते हैं जब भी उनकी आंतरिक स्थिति बदलती है। कंज्यूमर्स तुरंत प्रतिक्रिया करते हैं, उदाहरण के लिए, किसी डिपेंडेंट टास्क को केवल तभी कतार (queue) में रखते हैं जब अपस्ट्रीम एजेंट idle रिपोर्ट करता है।

  • एडवाइजरी लीज़ (Advisory Leases) – जब किसी एजेंट को किसी रिसोर्स (एक रेपो, एक API एंडपॉइंट, एक कंप्यूट नोड) तक विशेष पहुंच की आवश्यकता होती है, तो वह TTL (time-to-live) के साथ एक लीज़ का दावा करता है। यदि एजेंट क्रैश हो जाता है, तो लीज़ अपने आप समाप्त हो जाती है, जिससे रिसोर्स दूसरों के लिए मुक्त हो जाता है और दो बॉट्स को एक-दूसरे के काम में बाधा डालने से रोका जा सकता है।

  • इनबॉक्स मैकेनिज्म (Inbox Mechanism) – यदि एजेंट के इनबॉक्स में बिना पढ़े गए मैसेज हैं, तो एक "स्टॉप हुक" (stop hook) एजेंट के वर्कफ़्लो को रोक देता है। एजेंट को अपना वर्तमान कार्य पूरा करने से पहले उन आइटम्स को प्रोसेस करना होगा, जिससे यह सुनिश्चित हो सके कि लंबित समन्वय संकेतों (coordination signals) को अनदेखा न किया जाए।

ये हिस्से मिलकर एक सरल, ऑब्जर्वेबल कम्युनिकेशन लेयर बनाते हैं जो हर प्रतिभागी को एक ही जानकारी (same page) पर रखता है।

जो टीमें इसे अनदेखा करती हैं, उनके लिए जोखिम

यदि कोई टीम एड-हॉक प्रॉम्प्ट्स और मैन्युअल मॉनिटरिंग पर निर्भर रहती है, तो छिपी हुई लागतें बढ़ती जाती हैं:

  • दोहरा प्रयास – दो एजेंट एक जैसे रिपोर्ट जनरेट कर सकते हैं, जिससे कंप्यूट साइकिल और क्लाउड खर्च बढ़ जाता है।
  • रिसोर्स विवाद (Resource contention) – कोडबेस में एक साथ किए गए राइट्स (writes) मर्ज कॉन्फ्लिक्ट्स पैदा करते हैं जिन्हें इंसानी समाधान की आवश्यकता होती है।
  • परिचालन जोखिम (Operational risk) – पुराने स्टेटस पर काम करने वाला एजेंट डिप्लॉयमेंट का प्रयास कर सकता है जबकि दूसरा पहले से ही रोलबैक कर रहा हो, जिससे सर्विस अस्थिर हो सकती है।

एजेंट्स अपनी पहचान, स्थिति और रिसोर्स दावों की घोषणा कैसे करते हैं, इसे औपचारिक बनाकर, IACP बिना किसी भारी-भरकम ऑर्केस्ट्रेशन इंजन की मांग किए इन जोखिमों को कम करता है।

विपरीत तर्क: अतिरिक्त ओवरहेड

आलोचकों का तर्क है कि हिस्ट्री इंजेक्ट करने और लीज़ मैनेज करने से लेटेंसी और अतिरिक्त कोड पाथ जुड़ जाते हैं। उन वातावरणों में जहाँ एक अकेला एजेंट एक सीमित कार्य संभालता है, प्रोटोकॉल के लाभ मामूली हो सकते हैं। हालाँकि, कार्यान्वयन मौजूदा मेमोरी और मॉनिटरिंग सेवाओं का पुन: उपयोग करता है, इसलिए अतिरिक्त लोड कम है। जो टीमें पहले से ही क्रॉस-एजेंट भ्रम का सामना कर रही हैं, उनके लिए यह समझौता स्पष्ट रूप से फायदेमंद है।

आगे क्या देखें

यह प्रोटोकॉल अभी एक प्रोटोटाइप है, लेकिन इसकी मॉड्यूलर प्रकृति किसी भी लैंग्वेज-एग्नोस्टिक (language-agnostic) एजेंट फ्रेमवर्क के साथ एकीकरण के लिए आमंत्रित करती है। संभावित अगले चरणों में शामिल हैं:

  • एक लाइटवेट SDK प्रकाशित करना ताकि डेवलपर्स कोर लॉजिक को छेड़े बिना पांच हुक्स जोड़ सकें।
  • मॉनिटरिंग सुइट में मेट्रिक्स जोड़ना जो स्टेट ट्रांज़िशन और लीज़ चर्न को विज़ुअलाइज़ करें, जिससे टीमों को बॉटलनेक्स पहचानने में मदद मिले।
  • पॉलिसी लेयर्स के साथ प्रयोग करना जो हाई-ट्रैफ़िक परिदृश्यों में अन्य एजेंटों की तुलना में कुछ विशिष्ट एजेंटों की लीज़ को स्वचालित रूप से प्राथमिकता दें।

यदि ये एक्सटेंशन लोकप्रियता हासिल करते हैं, तो IACP मल्टी-एजेंट प्रोडक्शन पाइपलाइनों के लिए एक डी-फ़ैक्टो मानक बन सकता है, ठीक वैसे ही जैसे HTTP वेब सेवाओं के लिए बना था।

मुख्य निष्कर्ष: परंपराओं का एक छोटा सा समूह—कौन बोल रहा है, हालिया बातचीत कैसी दिखती है, एजेंट का स्टेटस कब बदलता है, संसाधन किसके पास है, और क्या कोई संदेश लंबित हैं—AI एजेंटों को एक-दूसरे की बात समझे बिना बोलने से रोक सकता है और एक शोर भरे चैटरूम को एक विश्वसनीय समन्वय चैनल में बदल सकता है।