Agent Plugins 1.0 एक खुला, वेंडर-तटस्थ स्टैंडर्ड है, जो किसी AI एजेंट की क्षमताओं (स्किल्स, MCP सर्वर, कमांड और नियम) को एक ही इंस्टॉल किए जा सकने वाले प्लगइन में पैक करता है, ताकि आप उसे एक बार बनाएँ और हर टूल के लिए दोबारा बनाने के बजाय अलग-अलग टूल्स में चलाएँ। अगस्त 2026 में GitHub ने VS Code, Copilot CLI, Copilot ऐप और उसके SDK में, सभी Copilot प्लानों पर, इस स्टैंडर्ड के पूर्ण समर्थन की घोषणा की। किसी व्यवसाय मालिक के लिए इसका सीधा मतलब है: अपनी टीम के लिए AI टूल्स को कस्टमाइज़ करने में आप जो समय और पैसा लगाते हैं, वह अब किसी एक प्लेटफ़ॉर्म का बंधक नहीं रहता।

यह असल में कौन-सी समस्या हल करता है?

पिछले दो वर्षों में AI टूल्स एक चैट बॉक्स से आगे बढ़कर ऐसे एजेंट बन गए हैं जो आपकी फ़ाइलें पढ़ते हैं, आपके सिस्टम को कॉल करते हैं और वास्तविक कदम पूरे करते हैं। इन एजेंटों को अपनी कंपनी के अनुसार कस्टमाइज़ करने के लिए आपको उन्हें तीन चीज़ें देनी होती हैं: लिखित निर्देश जो बताएँ कि आपका व्यवसाय कैसे चलता है, MCP सर्वरों के ज़रिए आपके आंतरिक सिस्टम से जुड़ाव, और ऐसे नियम जो उन्हें अपने अधिकार से आगे जाने से रोकें।

समस्या यह थी कि हर टूल यह सब अपने ही फ़ॉर्मेट में माँगता था। आपकी टीम एक टूल के लिए कस्टमाइज़ेशन लिखती है, फिर एक साल बाद कंपनी किसी तेज़ या सस्ते विकल्प पर जाने का फ़ैसला करती है और पाती है कि सारा काम पोर्टेबल नहीं है और उसे दोबारा लिखना पड़ेगा। यह सिर्फ़ एक तकनीकी परेशानी नहीं है; यह एक वास्तविक लागत है जो हर वेंडर बदलने पर दोहराई जाती है, और यही वजह है कि कई कंपनियाँ मेहनत बेकार जाने के डर से गंभीर कस्टमाइज़ेशन टाल देती हैं।

व्यवहार में एक प्लगइन में क्या होता है?

इस स्टैंडर्ड के तहत एक पैकेज की बनावट सरल और स्पष्ट रूप से परिभाषित है। इसमें शामिल हैं:

  • एक plugin.json मैनिफ़ेस्ट, जिसमें प्लगइन का नाम और वर्शन नंबर होता है, और यही अपडेट करना और ट्रैक करना संभव बनाता है।
  • एक स्किल्स फ़ोल्डर, जिसमें वे लिखित निर्देश होते हैं जो एजेंट को बताते हैं कि आपकी कंपनी का कोई दोहराया जाने वाला काम ठीक उसी तरह कैसे करना है जैसा आप चाहते हैं।
  • एक mcp.json फ़ाइल, जो उन MCP सर्वरों को परिभाषित करती है जो एजेंट को आपके असली सिस्टम से जोड़ते हैं: इन्वेंटरी, ग्राहक डेटाबेस, बिलिंग।
  • टूल-विशेष एक्सटेंशन, जिन्हें एक अलग नेमस्पेस में रखा जाता है, ताकि कोई वेंडर अपनी कोई विशेष सुविधा जोड़े तब भी साझा हिस्से पोर्टेबल बने रहें।

साझा हिस्से को वेंडर-विशेष हिस्से से अलग रखना इस डिज़ाइन की सबसे समझदारी भरी बात है: यह किसी भी प्रदाता को अपनी सुविधाओं के दम पर अलग दिखने से नहीं रोकता, और अगर आप बाद में अपना इरादा बदलें तो आपको सब कुछ खोने पर मजबूर नहीं करता।

सिर्फ़ डेवलपर ही नहीं, व्यवसाय मालिक को भी इसकी परवाह क्यों करनी चाहिए?

असली फ़र्क गवर्नेंस में है। यह स्टैंडर्ड एक ओपन लाइसेंस के तहत सार्वजनिक रूप से विकसित किया जाता है और इसकी निगरानी एक तकनीकी संचालन समिति करती है, जिसमें Amazon, Microsoft, OpenAI, Cursor और Vercel के प्रतिनिधि शामिल हैं। जब आपस में प्रतिस्पर्धा करने वाली कंपनियाँ एक ही फ़ॉर्मेट पर सहमत होती हैं, तो यह संकेत है कि यह फ़ॉर्मेट किसी एक प्रोडक्ट चक्र से ज़्यादा टिकेगा, और यह किसी एक पक्ष की अपने ग्राहकों को बाँधे रखने की कोशिश नहीं है।

यह इसलिए मायने रखता है क्योंकि आज AI अपनाने का सबसे बड़ा जोखिम तकनीकी नहीं, बल्कि अनुबंध से जुड़ा है। आज आप जिस प्रदाता को चुनते हैं, वह कीमतें बढ़ा सकता है, कोई ऐसी सेवा बंद कर सकता है जिस पर आप निर्भर हैं, या उसकी गुणवत्ता बदल सकती है। एक ओपन स्टैंडर्ड इन जोखिमों को खत्म नहीं करता, लेकिन यह बाहर निकलने की आपकी लागत घटा देता है, और कम निकास लागत ही आपके हाथ में मोलभाव का सबसे मज़बूत पत्ता है।

सऊदी अरब के व्यवसायों के लिए इसका क्या मतलब है?

किंगडम में 2026 को कृत्रिम बुद्धिमत्ता का वर्ष घोषित किए जाने के साथ, कई कंपनियाँ वर्षों के डेमो के बाद गंभीर प्रयोग के दौर में पहुँच गई हैं। हम बार-बार यह पैटर्न देखते हैं कि कोई कंपनी अपनी टीम के लिए सब्सक्रिप्शन खरीदती है, फिर कुछ भी कस्टमाइज़ नहीं करती, और आखिर में उसके पास एक सामान्य असिस्टेंट रह जाता है जो दुनिया के बारे में सब कुछ जानता है लेकिन उसके अपने सिस्टम के बारे में कुछ नहीं। असली मूल्य कस्टमाइज़ेशन से आता है, सब्सक्रिप्शन से नहीं।

एक पोर्टेबल स्टैंडर्ड के आ जाने से कस्टमाइज़ करने का फ़ैसला कहीं कम जोखिम भरा हो गया है। कोई कंपनी एक आंतरिक प्लगइन लिख सकती है जो उसकी अनुमोदन प्रक्रिया समझाए, एजेंट को अपने बिलिंग या ऑर्डर मैनेजमेंट सिस्टम से जोड़ सकती है और उसे पूरी टीम में बाँट सकती है, इस भरोसे के साथ कि अगर वह अगले साल किसी दूसरे टूल पर चली जाए तब भी यह निवेश बेकार नहीं जाएगा।

लेकिन एक ज़रूरी बात ध्यान रखें: किसी पैकेज के पोर्टेबल होने का मतलब यह नहीं कि आपके डेटा तक पहुँच जायज़ हो जाती है। जो भी प्लगइन किसी एजेंट को आपके आंतरिक सिस्टम से जोड़ता है, वह व्यक्तिगत डेटा संरक्षण कानून (PDPL) के अधीन ही रहता है, और आपको सटीक रूप से तय करना होगा कि एजेंट क्या पढ़ सकता है और क्या नहीं, और इसे दस्तावेज़ में दर्ज करना होगा।

इसी हफ़्ते शुरू करने के व्यावहारिक कदम

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

निष्कर्ष यह है कि उद्योग आपस में होड़ करते फ़ॉर्मेटों की अव्यवस्था से एक साझा फ़ॉर्मेट की ओर बढ़ रहा है, और यही वह दौर है जिसमें AI कस्टमाइज़ेशन में निवेश जुआ न रहकर एक सोचा-समझा फ़ैसला बन जाता है। Origami में हम ये प्लगइन और अपने क्लाइंट्स के असली सिस्टम से इनके कनेक्शन बनाते हैं, और शुरुआत से ही ऐसा डिज़ाइन करते हैं कि स्वामित्व और लचीलापन वेंडर के पास नहीं, बल्कि क्लाइंट के पास रहे।

स्रोत

  • Agent Plugins 1.0 के समर्थन पर GitHub की आधिकारिक घोषणा: github.blog
  • स्टैंडर्ड की आधिकारिक वेबसाइट और उसकी तकनीकी संचालन समिति: agent-plugins.org
  • 1.0.0 विनिर्देश का पाठ: agent-plugins-spec