AWS एजेंटिक रिसोर्स डिस्कवरी को एजेंट रजिस्ट्री के लिए फेडरेशन लेयर के रूप में समर्थन देता है

Amazon Web Services ने एजेंटिक रिसोर्स डिस्कवरी विनिर्देश का समर्थन किया है, और 24 अगस्त 2026 को एक विस्तृत विवरण प्रकाशित किया कि यह ओपन मानक AWS Agent Registry के साथ कैसे काम करने के लिए बनाया गया है, जो AI एजेंट, टूल और स्किल्स के लिए उसका प्रबंधित कैटलॉग है और इस वर्ष की शुरुआत में प्रीव्यू में आया था।

AWS पोस्ट ARD को उस समस्या का उत्तर प्रस्तुत करता है जिसे AWS के अपने उत्पाद ने अनसुलझा छोड़ दिया था। AWS Agent Registry, Amazon Bedrock AgentCore के माध्यम से उपलब्ध, एक संगठन को एजेंट, MCP सर्वर, टूल, एजेंट स्किल्स और कस्टम रिसोर्सेज के लिए एक केंद्रीकृत, खोज योग्य कैटलॉग प्रदान करता है, लेकिन केवल अपने स्वयं के AWS वातावरण के भीतर। अधिकांश उद्यम कई क्लाउड, ऑन‑प्रेमाइसेस इन्फ्रास्ट्रक्चर और SaaS प्लेटफ़ॉर्म पर एजेंट चलाते हैं, जिनमें प्रत्येक का अपना रजिस्ट्री और मेटाडेटा फ़ॉर्मेट होता है, और आज इन वातावरणों को जोड़ना प्रत्येक रजिस्ट्री के बीच कस्टम कनेक्टर बनाने का मतलब है।

ARD साझा‑फ़ॉर्मेट विकल्प प्रस्तावित करता है: यदि प्रत्येक रजिस्ट्री संसाधनों का वर्णन एक ही तरीके से करती है और एक सामान्य प्रोटोकॉल के माध्यम से खोज को उजागर करती है, तो प्रकाशक अपने संसाधनों का विवरण एक बार देते हैं और उपभोक्ता उन्हें हर जगह खोज सकते हैं।

AWS Agent Registry मॉडल के भीतर

रजिस्ट्री, वर्तमान में Amazon Bedrock AgentCore के माध्यम से प्रीव्यू में, दो अवधारणाओं के आसपास निर्मित है: रजिस्ट्रीज़, जो प्रशासक द्वारा अपने स्वयं के प्राधिकरण और अनुमोदन सेटिंग्स के साथ बनाई गई कैटलॉग हैं, और रिकॉर्ड्स, जो प्रत्येक संसाधन का मेटाडेटा प्रविष्टि हैं। प्रकाशन कार्यप्रवाह प्रशासक → प्रकाशक → क्यूरेटर → उपभोक्ता तक चलता है, और किसी भी रिकॉर्ड के खोज योग्य बनने से पहले एक अनुमोदन गेट होता है। पहुँच को AWS Identity and Access Management क्रेडेंशियल्स या कॉरपोरेट पहचान प्रदाता से JSON Web Tokens के माध्यम से नियंत्रित किया जाता है, और रजिस्ट्री स्वयं एक रिमोट MCP एंडपॉइंट के रूप में उजागर की जाती है, इसलिए कोई भी MCP‑संगत क्लाइंट इसे सीधे खोज सकता है।

यह गवर्नेंस लेयर वह हिस्सा है जिसे AWS सावधानी से बनाए रखना चाहता है। पोस्ट में, AWS ARD को एक इंटरऑपरेबिलिटी लेयर के रूप में वर्णित करता है जो प्रवर्तन बिंदु के बाहर स्थित है: वह संगठन जो कैटलॉग प्रकाशित करता है, यह नियंत्रित करता है कि उसमें क्या है, कौन देख सकता है, और कब पहुँच रद्द की जाए, जबकि Agent Registry के मौजूदा अनुमोदन और पहुँच नियंत्रण वहीं रहते हैं जहाँ नीति वास्तव में लागू होती है। भाषा जानबूझकर स्पष्ट है: ARD चीज़ों को खोजने को संभालता है, उत्पादन में भरोसा करने को नहीं।

ARD विनिर्देश वास्तव में किन चीज़ों का मानकीकरण करता है

ARD कोई AWS प्रोजेक्ट नहीं है। यह विनिर्देश 17 जून 2026 को एक कार्यसमूह द्वारा घोषित किया गया था, जिसके प्रतिभागियों में Google, Microsoft, Hugging Face, और GoDaddy शामिल हैं, तथा Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow, और Snowflake लॉन्च में सहयोगी हैं। यह Apache 2.0 लाइसेंस के तहत जारी किया गया है और agenticresourcediscovery.org पर प्रकाशित है, साथ ही GitHub पर रेफ़रेंस इम्प्लीमेंटेशन उपलब्ध हैं। AWS ने विकास के दौरान प्रतिक्रिया दी, लेकिन विनिर्देश का लेखन नहीं किया।

Google की घोषणा के अनुसार, आर्किटेक्चर दो मूलभूत तत्वों पर आधारित है। एक कैटलॉग वह फ़ाइल है जिसे एक संगठन अपने स्वयं के डोमेन के तहत प्रकाशित करता है (एक well‑known पाथ पर ai‑catalog.json) जिसमें उसके उपलब्ध एजेंट, MCP सर्वर, A2A एजेंट, OpenAPI टूल या नेस्टेड कैटलॉग का विवरण होता है, और डोमेन स्वामित्व प्रकाशक पहचान के लिए क्रिप्टोग्राफ़िक आधार के रूप में कार्य करता है। रजिस्ट्रीज़ उन कैटलॉग्स पर खोज इंजन के रूप में कार्य करती हैं: वे क्रॉल, इंडेक्स और साधारण भाषा खोज अनुरोधों का उत्तर देती हैं, और मिलान के साथ वह सत्यापनीय ट्रस्ट मेटाडेटा लौटाती हैं जिसकी क्लाइंट को प्रकाशक की पहचान की पुष्टि करने के लिए आवश्यकता होती है।

ARD की सीमा खोज है, निष्पादन नहीं। एक क्लाइंट जो ARD के माध्यम से संसाधन पाता है, उसे उस संसाधन द्वारा मूल रूप से समर्थित तंत्र (MCP, API, एजेंट फ्रेमवर्क) के माध्यम से बुलाता है। विनिर्देश की साइट स्पष्ट रूप से कहती है कि ARD कोई रन‑टाइम नहीं है, न ही MCP या A2A प्रोटोकॉल का प्रतिस्थापन, और न ही एक केंद्रीय कैटलॉग; डिज़ाइन कई खोज सेवाओं को मानता है, प्रत्येक अपनी ट्रस्ट और रैंकिंग नीति लागू करती है। AWS की तुलना DNS से की गई है: स्थानीय रजिस्ट्रीज़ साझा प्रोटोकॉल के माध्यम से फेडरेट करती हैं बिना द्विपक्षीय समझौते या स्वामित्व कनेक्टर के, जैसे नाम समाधान नेटवर्क्स में काम करता है।

अलग-अलग हिस्से कैसे जुड़ते हैं

Agent Registry ग्राहकों के लिए, यह प्रस्ताव माइग्रेशन के बिना फेडरेशन है। एक संगठन जिसका एजेंटिक इन्फ्रास्ट्रक्चर क्लाउड, ऑन‑प्रेमाइसेस सिस्टम और SaaS टूल्स में फैला हुआ है, वह सभी को ARD के फ़ॉर्मेट में उजागर कर सकता है और विभिन्न वातावरणों में खोज योग्य बना सकता है जबकि स्थानीय नियंत्रण बनाए रखता है, और वह अपने स्वयं के डोमेन पर एक कैटलॉग प्रकाशित कर सकता है जिससे कोई भी ARD‑संगत क्लाइंट खोज कर सके, जिससे ऐसे क्रॉस‑ऑर्गेनाइज़ेशनल मार्ग खुलते हैं जो एक‑वेंडर रजिस्ट्री नहीं पहुंच सकती।

AWS भी उत्पाद के साथ आगे बढ़ रहा है जबकि अन्य अभी निर्माण चरण में हैं। Google का अपना Agent Registry, जो Gemini Enterprise Agent Platform का हिस्सा है, आने वाले महीनों में नेटिव ARD समर्थन जोड़ने वाला है; GitHub और Hugging Face विनिर्देश के पीछे कार्यसमूह के प्रतिभागी हैं। तीनों क्लाउड्स में पैटर्न समान है: अंदर एक प्रबंधित, गवर्न्ड रजिस्ट्री, बाहर एक ओपन फेडरेशन प्रोटोकॉल।

ध्यान देने योग्य बात यह है कि AWS पोस्ट में वर्णित एकीकरण दिशात्मक है, शिप्ड नहीं। AWS यह बताता है कि वह ARD को Agent Registry ग्राहकों के लिए क्या सक्षम करने की अपेक्षा रखता है, बजाय डिलीवरी तिथि की घोषणा के, और रजिस्ट्री स्वयं प्रीव्यू में बनी रहती है। 24 अगस्त 2026 की घोषणा दिशा में सहमति स्थापित करती है: सबसे बड़े क्लाउड प्रदाता ने उस खुले विनिर्देश का नाम बताया है जिसके साथ वह फ़ेडरेशन करना चाहता है, और Google तथा Microsoft भी उसी दिशा में बढ़ रहे हैं।