कल दोपहर, हमारी टीम के एक इंजीनियर ने Anthropic को SaaStr मंच पर अपने आंतरिक GTM स्टैक के बारे में बताते देखा, उस स्लाइड का स्क्रीनशॉट लिया, और Zero से एक ही सवाल पूछा: इनमें से कौन से हमारे पास नहीं हैं? छह घंटे और उन्नीस मिनट बाद, हर Zero ग्राहक के लिए Snowflake प्रोडक्शन में लाइव था। यह लगभग 180वाँ इंटीग्रेशन था जो हमने एक साल में शिप किया, और तेज़ी से, अगला लिखने वाला व्यक्ति कोई इंजीनियर है ही नहीं। यहाँ है वह फ्रेमवर्क, और उसके ऊपर बना आंतरिक स्किल, जो यह संभव बनाता है।
एजेंट प्लेटफ़ॉर्म के बारे में वह बात जो कोई आपको नहीं बताता
एक LLM जार में बंद एक दिमाग है। अपने आप में, यह आपके डेटा वेयरहाउस के बारे में एक कविता लिख सकता है, पर असल में उसे खोल नहीं सकता। जो चीज़ एक चैटबॉट को एजेंट में बदलती है, वह चीज़ जिसके लिए आपकी टीम असल में भुगतान करती है, वह यह है कि क्या एजेंट उन उपकरणों तक पहुँच सकता है जिन्हें आप पहले से उपयोग करते हैं और उनमें काम कर सकता है।
हम उस पहुँच को connector layer कहते हैं। Zero बनाने के एक साल बाद, हमारा मानना है कि यह एक एजेंट प्रोडक्ट में अकेला सबसे महत्वपूर्ण इन्फ्रास्ट्रक्चर हिस्सा है। तो हमने अपना खुद का बनाया। इससे भी अहम, हमने इसके इर्द-गिर्द एक वर्कफ़्लो बनाया जो टीम के किसी भी व्यक्ति को एक बनाने देता है।
MCP क्यों नहीं। Zapier क्यों नहीं।
हमसे शुरू में दोनों के बारे में पूछा गया। दोनों जो हैं उसके लिए अच्छे हैं। दोनों में से कोई वह नहीं जिसकी हमें ज़रूरत थी।
MCP एक प्रोटोकॉल है, प्रोडक्ट नहीं। उन टूल लेखकों के लिए शानदार जो चाहते हैं कि उनकी सेवा किसी भी LLM द्वारा पहुँच योग्य हो। पर MCP सर्वर, जैसे आज तैनात होते हैं, मॉडल को उपकरणों की एक सूची सौंप देते हैं और भरोसा करते हैं कि वह उन्हें सुरक्षित रूप से कॉल करेगा। न कोई प्रति-संगठन क्रेडेंशियल वॉल्ट है, न इस पर कोई फ़ायरवॉल कि कौन से एंडपॉइंट छुए जा सकते हैं, न कोई ऑडिट लॉग जो किसी कॉल को उस इंसान से जोड़े जिसने उसे अधिकृत किया। एक ऐसे प्रोडक्ट के लिए जहाँ एक एजेंट ग्राहक के प्रोडक्शन Stripe को छू सकता है और दूसरा उनके CEO के Gmail में ईमेल का ड्राफ्ट लिख सकता है, "मॉडल पर भरोसा करो" कोई सुरक्षा मॉडल नहीं है।
Zapier-शैली के इंटीग्रेशन प्लेटफ़ॉर्म एक अलग समस्या हल करते हैं: वे डिटरमिनिस्टिक ट्रिगर को डिटरमिनिस्टिक क्रियाओं से जोड़ते हैं। एजेंट उस तरह काम नहीं करते। एक एजेंट सोचते-सोचते बीच में तय करता है कि अगला कदम Snowflake को क्वेरी करना और फिर एक Linear टिकट लिखना है। उसे अभी एक क्रेडेंशियल, एक स्कोप्ड HTTP क्लाइंट, और एक ऑडिट ट्रेल चाहिए, किसी पहले से बनी रेसिपी के रूप में नहीं।
तो हमने वह नीरस चीज़ बनाई: इंटीग्रेशन की एक रजिस्ट्री जहाँ हर प्रविष्टि auth मेटाडेटा ढोती है, इस बात की एक एनवायरनमेंट मैपिंग कि कौन से सीक्रेट सैंडबॉक्स में इंजेक्ट किए जाते हैं, अनुमत होस्ट का एक फ़ायरवॉल, और OAuth या टोकन की विचित्रताओं के लिए एक छोटा हैंडलर। यह इन्फ्रास्ट्रक्चर है।
पर इन्फ्रास्ट्रक्चर कहानी का दिलचस्प हिस्सा नहीं है। दिलचस्प हिस्सा वह है जो उसके ऊपर हुआ।
वह स्किल जिसने सबको कनेक्टर लेखक बना दिया
लगभग दिन में दो बार एक नया SaaS हमारे इंटीग्रेशन बैकलॉग में आता है। कुछ ग्राहक अनुरोधों से आते हैं। कुछ किसी साथी के यह नोटिस करने से कि Zero वह नहीं कर सकता जो उन्हें चाहिए। कुछ किसी BD बातचीत से जहाँ किसी संभावित ग्राहक के स्टैक में कोई ऐसा उपकरण होता है जिससे हम अभी तक नहीं मिले।
अगर इनमें से हर एक को किसी इंजीनियर की कतार से गुज़रना पड़ता, तो हम हफ़्ते में एक शिप करते। हम दिन में एक शिप करते हैं।
इसकी वजह आंतरिक टूलिंग का एक टुकड़ा है जिसे हम connector-authoring skill कहते हैं। यह एक Zero स्किल है, वही आकार जो हम ग्राहकों को शिप करते हैं, पर हमारे अपने कोडबेस की ओर अंदर की तरफ़ मोड़ा हुआ। जब टीम का कोई भी व्यक्ति कहता है "मैं Notion कनेक्टर जोड़ना चाहता हूँ," Zero उसे इससे गुज़ारता है:
- यूज़र परिदृश्य से शुरू करें। यूज़र असल में इस उपकरण से क्या करना चाहता है? "एक डेटाबेस क्वेरी करना," "एक पेज बनाना," "पूरे वर्कस्पेस में खोजना।" स्किल एक भी फ़ाइल छूने से पहले एक ठोस यूज़र स्टोरी पर ज़ोर देता है। एक कनेक्टर का लक्ष्य किसी एजेंट क्षमता को सक्षम करना है, न कि किसी API को पूरी तरह लपेटना।
- auth आकार पहचानें। OAuth, API टोकन, या दोनों। स्किल जानता है कि हर आकार में क्या शामिल है: OAuth के लिए, सहमति UI और रीडायरेक्ट प्लंबिंग; API टोकन के लिए, प्रति-संगठन सीक्रेट इंजेक्शन और यूज़र को टोकन कहाँ से मिलता है। लेखक वह आकार चुनता है जो उपकरण से मेल खाता है; नीचे की हर चीज़ वहीं से निकलती है।
- एंडपॉइंट को परिदृश्य से मैप करें। "पूरे REST API को लपेटो" नहीं। बस वे मुट्ठीभर एंडपॉइंट जो यूज़र स्टोरी को संतुष्ट करते हैं। तीन अच्छी तरह चुने गए एंडपॉइंट वाला कनेक्टर चालीस वाले से बेहतर है जिन तक एजेंट कभी नहीं पहुँचता।
- बारह फ़ाइलों का स्कैफ़ोल्ड बनाएँ। रजिस्ट्री प्रविष्टि, हैंडलर, फ़ायरवॉल पैटर्न, प्लेटफ़ॉर्म आइकन, env-मैपिंग प्लंबिंग, एजेंट-सामना करने वाला स्किल जो Zero को सिखाता है कि कनेक्टर को कैसे उपयोग करना है। स्किल स्कैफ़ोल्ड लिखता है; लेखक मंशा लिखता है।
- दो PR खोलें। एक कनेक्टर फ्रेमवर्क को, एक स्किल लाइब्रेरी को। दोनों की समीक्षा एक इंजीनियर करता है, पर समीक्षा शुद्धता के बारे में है, न कि लेखक को यह सिखाने के बारे में कि फ्रेमवर्क कैसे काम करता है।
जिसके लिए पहले संस्थागत ज्ञान चाहिए था (कौन सा auth आकार, कौन से एंडपॉइंट, कौन सी बारह फ़ाइलें किन दो रिपॉज़िटरी में, फ़ायरवॉल पैटर्न एक डायनेमिक सबडोमेन के साथ कैसे जुड़ता है) अब स्किल खुद ढोता है। लेखक यूज़र समानुभूति लाता है। स्किल स्कैफ़ोल्डिंग लाता है।
इसी तरह एक डिज़ाइनर, एक BD लीड, या एक PM एक कनेक्टर शिप कर देता है। वे जानते हैं कि यूज़र क्या चाहता है। स्किल बाकी सब जानता है।
केस स्टडी: Snowflake, कल
कल Anthropic ने SaaStr मंच पर अपने आंतरिक GTM स्टैक के बारे में बताया: सिस्टम ऑफ़ रिकॉर्ड के रूप में Salesforce, एनरिचमेंट के लिए Clay, रूटिंग के लिए LeanData, कॉल के लिए Gong, टिकटों के लिए Jira, सपोर्ट के लिए Intercom (Fin), अनुबंधों के लिए Ironclad, डेटा वेयरहाउस के रूप में Snowflake। [टॉक का लिंक]
हमारे एक इंजीनियर ने उस स्लाइड का स्क्रीनशॉट लिया और उसे एक ही सवाल के साथ Zero में डाला: "इनमें से किसके लिए हमारे पास कनेक्टर नहीं है?"
यहाँ है वह असली समयरेखा जो उसके बाद चली। सभी समय PDT में।
16:59. स्क्रीनशॉट आता है। Zero इसकी तुलना कनेक्टर कैटलॉग से करता है: 10 में से 7 पहले से मौजूद हैं (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack)। तीन गायब हैं (Clay, LeanData, Snowflake), और Snowflake को सबसे मूल्यवान के रूप में चिह्नित किया गया, क्योंकि एक डेटा वेयरहाउस GTM स्टैक की नींव है। जवाब 17:00 पर आता है।
17:01. अनुवर्ती: "इनमें से कौन से api-token कनेक्टर के रूप में किए जा सकते हैं?" Zero auth दस्तावेज़ खींचता है: Clay के पास एक पर्सनल API key है, Snowflake ने हाल ही में Programmatic Access Tokens शिप किए, LeanData केवल-OAuth और Salesforce से बँधा है। 17:02 पर फैसला: पहले Snowflake (सबसे ऊँचा मूल्य, सबसे साफ़ auth), फिर Clay।
17:04. इंजीनियर कहता है "आगे बढ़ो।" connector-authoring skill इसे उठाता है। 17:07 तक इसने Clay को बाहर कर दिया है (एकमात्र सार्वजनिक सतह प्रति-टेबल webhooks है, बनाने को कोई असली कनेक्टर नहीं) और Snowflake का आकार पुष्ट कर लिया है: SNOWFLAKE_PAT सीक्रेट + SNOWFLAKE_ACCOUNT वेरिएबल, Snowflake REST API और SQL API v2 के विरुद्ध bearer auth, Zendesk पर आधारित डायनेमिक-सबडोमेन फ़ायरवॉल पैटर्न।
17:35. दोनों PR उसी मिनट में खुले:
vm0-skills#176: एजेंट-सामना करने वाला स्किल। Snowflake SQL कैसे लिखें, नतीजे कैसे फ़ॉर्मेट करें, क्षणिक त्रुटियों पर फिर से कैसे प्रयास करें।vm0#13356: कनेक्टर खुद। रजिस्ट्री प्रविष्टि, PAT हैंडलर, फ़ायरवॉल जनरेटर, प्लेटफ़ॉर्म आइकन, env-मैपिंग प्लंबिंग।
18:22. स्किल PR मर्ज हुआ।
18:42. कनेक्टर PR मर्ज हुआ।
18:52. रिलीज़ PR अपने आप खुलता है।
23:18. web@v12.369.0 और बाकी रिलीज़ ट्रेन प्रोडक्शन में तैनात होती है। Snowflake हर संगठन के लिए लाइव है।
छह घंटे और उन्नीस मिनट "Anthropic के स्टैक के स्क्रीनशॉट" से "Zero आपके वेयरहाउस को क्वेरी कर सकता है" तक। एक इंजीनियर। एक बातचीत। किसी "कनेक्टर टीम" को शून्य हैंड-ऑफ़।
यहाँ का थ्रूपुट इसलिए नहीं है कि इंजीनियर तेज़ है। यह इसलिए है कि connector-authoring skill ने वे हिस्से ढोए जिनके लिए पहले संस्थागत ज्ञान चाहिए था: कौन सा auth आकार चुनना है, कौन से एंडपॉइंट यूज़र परिदृश्य से मैप होते हैं, कौन सी बारह फ़ाइलें किन दो रिपॉज़िटरी में आनी चाहिए, फ़ायरवॉल पैटर्न एक डायनेमिक सबडोमेन के साथ कैसे जुड़ता है। लेखक ने मंशा लिखी। स्किल ने स्कैफ़ोल्डिंग लिखी। बाकी प्रोडक्शन ने किया।
यही वह है जो फ्रेमवर्क हमें देता है। सिर्फ़ गति नहीं (हालाँकि गति असली है), बल्कि काम कौन ले सकता है। Snowflake का लेखक संयोग से एक इंजीनियर था। उसका होना ज़रूरी नहीं था।
api-token एक प्रथम-श्रेणी नागरिक क्यों है
एक फ़ुटनोट जिसे बाहर निकालना ज़रूरी है, क्योंकि यह एक जानबूझकर किया गया डिज़ाइन विकल्प है जिसने लोगों को चौंकाया।
ज़्यादातर एजेंट प्लेटफ़ॉर्म OAuth को एकमात्र सच्चा Auth मानते हैं और api-token को पुराने उपकरणों के लिए एक फ़ॉलबैक। हम उल्टा करते हैं। API टोकन हमारे कनेक्टर मॉडल में एक प्रथम-श्रेणी नागरिक हैं, उसी सहमति UI, उसी प्रति-संगठन वॉल्टिंग, उसी ऑडिट ट्रेल, उसी फ़ायरवॉल प्रवर्तन के साथ।
इसके दो कारण हैं।
पहला यह कि api-token auth का पहली-बार-उपयोग तक का समय छोटा होता है। Snowflake ने हाल ही में ठीक इसी कारण Programmatic Access Tokens शिप किए: लंबे समय तक चलने वाले, स्कोप करने योग्य, रद्द करने योग्य क्रेडेंशियल जिनके लिए OAuth नाच की ज़रूरत नहीं। PAT वाला एक यूज़र एक मिनट से कम में Zero में उत्पादक हो सकता है। एक OAuth फ़्लो, चाहे साफ़ ही क्यों न हो, ज़्यादा समय लेता है और यूज़र से ज़्यादा माँगता है।
दूसरा यह कि OAuth हमेशा उपलब्ध नहीं होता। कुछ एंटरप्राइज़ उपकरण बस एक शिप ही नहीं करते, या एक ऐसा शिप करते हैं जो किसी एंटरप्राइज़ SKU के पीछे बंद है। api-token को एक समकक्ष (फ़ॉलबैक नहीं) मानने का मतलब है कि हम उन उपकरणों को ठीक से सहारा दे सकते हैं, बजाय उन्हें किसी "जल्द आ रहा है" के कब्रिस्तान में छोड़ने के।
कल जो Snowflake कनेक्टर शिप हुआ वह api-token है। ग्राहक ईमेल थ्रेड्स शिप करने वाला Gmail कनेक्टर OAuth है। दोनों उसी फ्रेमवर्क, उसी स्किल, उसी समीक्षा से गुज़रते हैं। लेखक वह आकार चुनता है जो उपकरण से मेल खाता है, और फ्रेमवर्क दोनों में से किसी को भी बनाना सस्ता बना देता है।
लगभग 180 इंटीग्रेशन असल में क्या खोलते हैं
संख्या खुद बात नहीं है। बात यह है कि इस घनत्व पर, एजेंट एक ऐसा उपकरण नहीं रह जाता जिसे आप बुलाते हैं और एक ऐसा वातावरण बनने लगता है जिसमें आप रहते हैं।
जब Zero के पास आपके CRM और आपके डेटा वेयरहाउस और आपके सपोर्ट इनबॉक्स और आपके डिज़ाइन उपकरण और आपके repo के कनेक्टर होते हैं, तो यह वे चीज़ें कर सकता है जो कोई एकल-इंटीग्रेशन एजेंट नहीं कर सकता। यह एक Snowflake क्वेरी खींच सकता है, उसे खुले Linear टिकटों से क्रॉस-रेफ़रेंस कर सकता है, और उस Slack चैनल में एक सारांश पोस्ट कर सकता है जहाँ customer-success टीम रहती है। यह एक Gong कॉल पढ़ सकता है, वह फ़ीचर ढूँढ सकता है जिसके बारे में संभावित ग्राहक ने पूछा, जाँच सकता है कि वह रोडमैप में है या नहीं, और अनुवर्ती ईमेल का ड्राफ्ट लिख सकता है, सब एक ही चाल में।
हर नया कनेक्टर मूल्य रैखिक रूप से नहीं जोड़ता। यह मूल्य संयोजनात्मक रूप से जोड़ता है। 180वाँ कनेक्टर पहले से ज़्यादा मूल्यवान है, क्योंकि यह उन 179 के साथ जुड़ता है जो इससे पहले आए।
यही फ्रेमवर्क के पीछे का दाँव है। और स्किल के पीछे का दाँव यह है कि चक्रवृद्धि की गति इस पर निर्भर करती है कि आपकी टीम के कितने लोगों को ढेर में जोड़ने की अनुमति है।
आगे क्या
हम connector-authoring skill को ग्राहकों के लिए खोलने पर काम कर रहे हैं। अगर आप अपनी टीम के लिए Zero चला रहे हैं और कोई आंतरिक उपकरण है जिससे आपको एक इंटीग्रेशन चाहिए (आपका बिलिंग सिस्टम, आपका वेयरहाउस, आपका कस्टम आंतरिक एडमिन पैनल), तो वही वर्कफ़्लो जिसने कल Snowflake शिप किया, वही वर्कफ़्लो होगा जिसका उपयोग आप अपना शिप करने के लिए करेंगे। वही स्कैफ़ोल्डिंग, वही auth मॉडल, वही फ़ायरवॉल, वही ऑडिट ट्रेल। अलग लेखक।
अगर यह आपके लिए दिलचस्प है, हमें बात करके खुशी होगी।
