सोमवार, सुबह 9:12 बजे। Gmail में एक आशाजनक लीड आती है। Marketing कंपनी पर रिसर्च करती है। Operations जाँचती है कि यह ICP से मेल खाती है या नहीं। Sales एक जवाब का मसौदा तैयार करती है। एक मैनेजर उस एंगल की समीक्षा करता है और मज़बूत साक्ष्य माँगता है।
यहीं पर AI टीम सहयोग टूटता है: काम आगे बढ़ता है, लेकिन उसके पीछे की सोच शायद ही कभी पूरी तरह साथ जाती है।
हर व्यक्ति संदेशों, दस्तावेज़ों, पुराने उदाहरणों और स्मृति से असाइनमेंट का एक हिस्सा फिर से जोड़ता है। अंतिम ईमेल अच्छा हो सकता है। लेकिन उसे तैयार करने की प्रक्रिया अभी भी चार लोगों और पाँच टूल्स में बिखरी हुई है। जब अगली लीड आती है, तो अधिकांश काम फिर से शुरू होता है।
टीम सॉफ़्टवेयर ने दो दशक उन जगहों को बेहतर बनाने में लगाए हैं जहाँ लोग समन्वय करते हैं। असली कठिन समस्या मीटिंग या Slack थ्रेड खत्म होने के बाद शुरू होती है: क्या काम उस संदर्भ, मानकों और अधिकार को साथ ले जा सकता है जिसने निर्णय को आकार दिया?
यही Zero के पीछे का नज़रिया है। AI टीम सहयोग इस बात पर निर्भर करता है कि हैंडऑफ में कितना इरादा बचा रहता है।
हर सार्थक असाइनमेंट में चार चीज़ें होती हैं:
- संदर्भ (Context): टीम को ग्राहक, बाज़ार, प्रोजेक्ट और सीमाओं के बारे में क्या पता है।
- तरीका (Method): काम कैसे किया जाना चाहिए और कौन से स्रोत या टूल्स इस्तेमाल होने चाहिए।
- मानक (Standard): एक अच्छा डिलीवरेबल कैसा दिखता है और क्या अस्वीकार किया जाना चाहिए।
- अधिकार (Authority): कौन किन सिस्टम तक पहुँच सकता है, कौन से कार्य कर सकता है, और परिणाम को कौन मंज़ूरी दे सकता है।
अधिकांश हैंडऑफ घर्षण इनमें से किसी एक के छूट जाने से होता है। Zero टीमों को इन चारों को काम के साथ जोड़े रखने में मदद करता है, चाहे वह लोगों, टूल्स या समय के बीच कहीं भी जाए।
1. एक साझा शुरुआती बिंदु पुनः-स्पष्टीकरण के पहले दौर को हटा देता है
सहयोग अक्सर पुनर्निर्माण से शुरू होता है।
एक टीममेट एक टास्क खोलता है, नवीनतम रणनीति दस्तावेज़ खोजता है, ग्राहक परिभाषा के दो संस्करण पाता है, किसी सहकर्मी से एक प्रॉम्प्ट कॉपी करता है, और पूछता है कि कौन सा टेम्पलेट वर्तमान है। अभी तक कुछ भी execute नहीं हुआ। टीम एक साझा शुरुआती बिंदु तक पहुँचने के लिए ही एक समन्वय कर चुकी है।
Zero में, एक टीम बार-बार होने वाले कामों के लिए Shared Agents बना सकती है और उन्हें उस काम के लिए ज़रूरी संदर्भ, निर्देश और कनेक्टर दे सकती है। एक पुन: उपयोग योग्य Workflow टीम की सहमत प्रक्रिया को संभाल सकता है। अगला व्यक्ति एक खाली चैट बॉक्स की बजाय उसी ऑपरेटिंग संदर्भ से शुरू करता है।
यह सबसे ज़्यादा मायने रखता है जब ज्ञान असमान रूप से वितरित हो। अनुभवी ऑपरेटर पहले से जानता है कि कौन से स्रोत विश्वसनीय हैं, कौन से ग्राहक सेगमेंट को बाहर करना है, और अंतिम रिपोर्ट कैसे संरचित होनी चाहिए। एक बार जब ये विकल्प स्पष्ट कर दिए जाते हैं, तो एक नया टीममेट पहले दिन से ही टीम की वर्तमान पद्धति के साथ शुरू कर सकता है।
साझा संदर्भ का मतलब यह नहीं है कि हर व्यक्ति को एक ही जेनेरिक असिस्टेंट मिले। इसका मतलब है कि टीम के पास एक साझा आधार है जो अलग-अलग लोगों और भूमिकाओं को सपोर्ट कर सके।
एक सार्वजनिक Zero एजेंट और भूमिका-विशिष्ट एजेंट टीम को एक साझा शुरुआती बिंदु देते हैं, बिना हर काम को एक जेनेरिक असिस्टेंट में समेटे।
2. AI टीम सहयोग के लिए टूल्स में साझा execution ज़रूरी है
एक सामान्य AI हैंडऑफ एक और हैंडऑफ बनाता है। असिस्टेंट एक जवाब देता है, फिर कोई व्यक्ति उस जवाब को Gmail, GitHub, Notion, स्प्रेडशीट या ब्राउज़र में ले जाता है। संदर्भ फिर से कॉपी होता है। रास्ते में छोटे-छोटे निर्णय गायब हो जाते हैं।
Zero एक क्लाउड कंप्यूटर में चलता है जिसके पास ब्राउज़र, फ़ाइलें, टर्मिनल और अधिकृत कनेक्टर तक पहुँच होती है। यह किसी कंपनी पर रिसर्च कर सकता है, स्रोतों की तुलना कर सकता है, फ़ाइलें रूपांतरित कर सकता है, ईमेल का मसौदा तैयार कर सकता है, pull request बना सकता है, शीट अपडेट कर सकता है, या रिपोर्ट प्रकाशित कर सकता है — सब एक जुड़े हुए काम के रूप में।
सहयोग का मूल्य इस बात से आता है कि वह काम कहाँ पहुँचता है। Zero परिणाम सीधे उन सिस्टम में दे सकता है जो टीम पहले से साझा करती है: एक GitHub pull request, एक Notion पेज, एक साझा Google Sheet, एक Slack थ्रेड, या एक प्रकाशित रिपोर्ट।
वह साझा वर्कस्पेस Zero के अंदर कोई नई जगह नहीं है जो आपकी टीम को बनानी पड़े। यह पहले से ही उन SaaS उत्पादों में मौजूद है जो आपकी कंपनी हर दिन इस्तेमाल करती है। क्लाउड ब्राउज़र Zero को उनके वेब इंटरफ़ेस के ज़रिए काम करने देता है। 2,000 से अधिक कनेक्टर और APIs उसे उन्हीं सिस्टम तक संरचित पहुँच देते हैं। सैंडबॉक्स काम पूरा होने तक फ़ाइलों और मध्यवर्ती स्थिति को एक साथ रखता है।
मिलकर, ये क्षमताएँ Zero को रिसर्च से लेकर कार्रवाई तक एक टास्क ले जाने देती हैं, बिना किसी व्यक्ति से टूल्स के बीच आउटपुट कॉपी करवाए। सहयोग की व्यावहारिक इकाई एक ऐसा डिलीवरेबल बन जाती है जो उस सिस्टम में होती है जिसे टीम पहले से साझा करती है। Engineers pull request की समीक्षा कर सकते हैं, stakeholders Notion पेज पर टिप्पणी कर सकते हैं, operators साझा Sheet से काम कर सकते हैं, और टीम Slack में अगला कदम तय कर सकती है। हर समीक्षा, संपादन और निर्णय साझा artifact से जुड़ा रहता है, न कि किसी और हैंडऑफ के ज़रिए कॉपी होता है।
इससे हैंडऑफ पाने वाले व्यक्ति की भूमिका बदल जाती है। वे execution path को फिर से बनाने में कम समय लगाते हैं और यह आँकने में ज़्यादा कि आउटपुट उपयोगी, सटीक और आगे बढ़ने के लिए तैयार है या नहीं।
Zero के 2,000+ कनेक्टर उस SaaS स्टैक को सहयोग की सतह में बदल देते हैं जिसे टीम पहले से साझा करती है।
3. जटिल काम के लिए उच्च-गुणवत्ता डेटा और एक execution harness चाहिए
कोई जटिल टास्क शायद ही इसलिए विफल होता है क्योंकि प्रॉम्प्ट बहुत छोटा था। यह इसलिए विफल होता है क्योंकि इनपुट कमज़ोर थे या execution बीच में टूट गई। किसी बाज़ार में प्रवेश का निर्णय वर्तमान कंपनी डेटा, सर्च डिमांड, प्रतिस्पर्धी गतिविधि, hiring संकेतों, ग्राहक इतिहास और आंतरिक उत्पाद उपयोग पर निर्भर हो सकता है। कोई एक टीममेट या सिस्टम पूरी तस्वीर नहीं रखता। अगर अलग-अलग लोग उन तथ्यों के अलग-अलग संस्करणों से काम कर रहे हैं, तो ज़्यादा संदेश alignment नहीं बनाएँगे।
Zero केवल उस डेटा पर निर्भर नहीं करता जो टीम के SaaS स्टैक में पहले से मौजूद हो। इसमें वेब रिसर्च, कंपनी और लोगों के डेटा, सोशल गतिविधि, सर्च और SEO, वित्तीय बाज़ार, मानचित्र, मौसम और अन्य विशेषज्ञ स्रोतों के लिए उच्च-गुणवत्ता डेटा APIs शामिल हैं। Zero उन स्रोतों को टास्क के अंदर query कर सकता है, उन्हें टीम के CRM, inbox, दस्तावेज़ों, कोड और फ़ाइलों के डेटा के साथ जोड़ सकता है, परस्पर विरोधी परिणामों की तुलना कर सकता है, और स्रोत को दावे से जोड़े रख सकता है। परिणाम वह साक्ष्य होता है जिसे टीम इस्तेमाल कर सकती है, न कि लिंक्स की एक सूची जिसे कोई अभी भी रिसर्च करे।
अच्छे डेटा तक पहुँच उत्पाद समस्या का केवल आधा हिस्सा है। एक मॉडल एक सर्च के बाद एक प्रशंसनीय बाज़ार रिपोर्ट तैयार कर सकता है। एक जटिल-टास्क उत्पाद को कई बाज़ारों की जाँच करनी होती है, working files बनाए रखनी होती हैं, किसी अनिश्चित दावे पर वापस जाना होता है, query विफल होने पर recover करना होता है, verification सौंपनी होती है, और एक ऐसी रिपोर्ट देनी होती है जिसे कोई दूसरा व्यक्ति audit कर सके। इसके लिए मॉडल के चारों ओर एक engineering harness चाहिए: एक isolated क्लाउड कंप्यूटर, ब्राउज़र, टर्मिनल, फ़ाइल सिस्टम, कनेक्टर, permission controls, long-running state, parallel agent threads, और artifacts को टीम के टूल्स में deliver करने का एक विश्वसनीय तरीका।
4. सटीक फ़ीडबैक लूप लोगों और एजेंट्स को aligned रखते हैं
फ़ीडबैक तभी मदद करता है जब अगले व्यक्ति या एजेंट को पता हो कि क्या गलत है और क्या बदलना चाहिए। "इसे बेहतर बनाओ" व्याख्या का एक और दौर पैदा करता है। "50 से कम कर्मचारियों वाली कंपनियों को बाहर करें और हर तथ्यात्मक दावे का हवाला दें" प्राप्तकर्ता को कुछ ऐसा देता है जिस पर वे कार्रवाई कर सकते हैं। यह मानव-से-AI और मानव-से-मानव सहयोग दोनों पर समान रूप से लागू होता है: फ़ीडबैक तब मूल्य खो देता है जब वह उस काम से अलग हो जाता है जिसका वह संदर्भ देता है।
Zero का Quote action एक सुधार को समीक्षाधीन सटीक वाक्य, दावे या सिफारिश से जोड़ता है। एक समीक्षक "Acme के 240 कर्मचारी हैं" को quote कर सकता है और Zero से स्रोत सत्यापित करने के लिए कह सकता है, या एक साथ कई अंशों को चिह्नित कर सकता है। अगले turn में हर टिप्पणी अपने object के साथ बरकरार रहती है।
Quote फ़ीडबैक को समीक्षाधीन सटीक अंश से जोड़ता है, ताकि अगला निर्देश अपना object साथ लेकर चले।
सटीक फ़ीडबैक को सही योगदानकर्ता तक भी पहुँचना चाहिए। Zero की Agent-to-Agent क्षमता, यानी A2A के साथ, एक रिसर्च थ्रेड दावे को सत्यापित कर सकती है, एक analyst संख्याओं को चुनौती दे सकता है, और एक writing थ्रेड narrative को संशोधित कर सकती है। वे समानांतर में काम कर सकते हैं और परिणाम को coordinating chat में वापस कर सकते हैं।
एक थ्रेड mention समस्या और उसके संदर्भ को दूसरे एजेंट chat में भेजता है, जहाँ काम स्वतंत्र रूप से जारी रह सकता है और वापस रिपोर्ट कर सकता है।
Quote और A2A मिलकर एक स्पष्ट लूप बनाते हैं: समस्या पहचानें, संदर्भ के साथ route करें, सुधार वापस लाएँ, और परिणाम की समीक्षा करें। लोग टिप्पणियाँ दोहराने में कम समय लगाते हैं, जबकि एजेंट्स को ऐसे निर्देश मिलते हैं जिन पर वे कार्रवाई कर सकते हैं।
अगर बार-बार का फ़ीडबैक एक बेहतर तरीका उजागर करता है, तो कोई व्यक्ति Workflow को अपडेट करना चुन सकता है। यह कदम जानबूझकर है। फ़ीडबैक पहले वर्तमान सहयोग को बेहतर बनाता है; यह पुन: उपयोग योग्य तभी बनता है जब टीम तय करे कि इसे भविष्य के काम को आकार देना चाहिए।
5. Workflows सहमति को executable टीम क्षमता में बदलते हैं
टीमें पहले से ही दस्तावेज़ों में प्रक्रियाएँ संग्रहीत करती हैं। समस्या तब सामने आती है जब प्रक्रिया को चलाना हो।
एक दस्तावेज़ कह सकता है, "अकाउंट पर रिसर्च करें, CRM जाँचें, हाल के hiring संकेत देखें, और एक व्यक्तिगत जवाब का मसौदा तैयार करें।" ऑपरेटर को फिर भी हर वाक्य को कार्यों में अनुवाद करना होता है, सही टूल्स चुनने होते हैं, और अंतिम आउटपुट जोड़ना होता है।
Zero में एक Workflow एक trigger-free, पुन: उपयोग योग्य तरीका है किसी काम को करने का। यह जाँचने के स्रोत, अनुसरण करने का क्रम, पालन करने की सीमाएँ, और डिलीवरेबल का आकार परिभाषित कर सकता है। एक टीममेट इसे माँग पर चला सकता है। एक अन्य Shared Agent अपनी भूमिका के अनुकूल एक प्रति का उपयोग कर सकता है।
इससे Workflow एक saved prompt से ज़्यादा बन जाता है। यह एक executable सहमति है कि टीम एक बार-बार होने वाला काम कैसे करना चाहती है।
एक व्यक्ति साप्ताहिक प्रतिस्पर्धी स्कैन को तब तक परिष्कृत कर सकता है जब तक वह कंपनी के मानक पर खरा न उतरे। अगले व्यक्ति को कोई रिकॉर्डिंग देखने, पुराने थ्रेड को समझने, या प्रक्रिया के "असली" संस्करण के लिए पूछने की ज़रूरत नहीं है। वे सहमत तरीका चला सकते हैं, परिणाम की समीक्षा कर सकते हैं, और जब व्यवसाय बदले तो इसे बेहतर बना सकते हैं।
compounding प्रभाव पुन: उपयोग से आता है। हर सत्यापित Workflow बढ़ाता है कि टीम बिना तरीका फिर से बनाए क्या कर सकती है।
एक Workflow एक सहमत तरीके को काम करने के पुन: उपयोग योग्य तरीके में बदल देता है, ताकि अगला टीममेट किसी दस्तावेज़ में निर्देशों से ज़्यादा के साथ शुरू करे।
6. साझा तरीके व्यक्तिगत अधिकार के साथ सह-अस्तित्व में रह सकते हैं
टीम सहयोग तब जोखिम भरा हो जाता है जब किसी प्रक्रिया को साझा करने का मतलब credentials साझा करना या व्यक्तिगत जवाबदेही हटाना भी हो।
Zero पुन: उपयोग योग्य तरीके को उसे शुरू करने वाली शर्तों से अलग करता है। एक Workflow प्रक्रिया रखता है। एक Automation एक trigger, एक Workflow और एक Agent को जोड़ता है, फिर उस व्यक्ति की पहचान, permissions और connected services के भीतर चलता है जिसने इसे बनाया।
यह अंतर एक व्यावहारिक governance समस्या हल करता है। एक sales टीम एक ही account-research Workflow साझा कर सकती है जबकि हर rep अपने Gmail access का उपयोग करता है। एक finance lead किसी Agent को एक सिस्टम पढ़ने की अनुमति दे सकता है बिना किसी sensitive write action को authorize किए। एक admin team workspace controls का उपयोग करके तय कर सकता है कि कौन से connectors और actions उपलब्ध हैं, जबकि व्यक्तिगत टीम सदस्य उन automations के लिए ज़िम्मेदार रहते हैं जो वे बनाते हैं।
टीम को सभी को एक अकाउंट में समेटे बिना consistency मिलती है। तरीका साझा है। अधिकार attributable रहता है।
7. Automations काम को बिना सबकी उपस्थिति के जारी रखने देते हैं
कई सहयोग की आदतें वास्तव में synchronization की आदतें हैं। कोई status request पोस्ट करता है। तीन लोग updates इकट्ठा करते हैं। चौथा व्यक्ति रिपोर्ट बनाता है। सभी एक ही पल उपलब्ध होने का इंतज़ार करते हैं।
एक Automation एक साझा Workflow को एक trigger देता है। यह किसी schedule पर या किसी event के होने पर शुरू हो सकता है, फिर चुने हुए Agent से काम पूरा करने के लिए कह सकता है। एक morning brief standup से पहले calendar, product, support और engineering संकेत इकट्ठा कर सकता है। एक नया ग्राहक ईमेल एक रिसर्च और drafting flow शुरू कर सकता है। एक साप्ताहिक प्रतिस्पर्धी समीक्षा टीम channel में स्रोतों के साथ पहुँच सकती है।
मूल्य बचाए गए समय से बड़ा है। काम तब भी आगे बढ़ सकता है जब टीम मीटिंग में हो, सो रही हो, या कहीं और focused हो। लोग updates के लिए एक और request की बजाय एक ठोस artifact के इर्द-गिर्द फिर से जुड़ते हैं।
Asynchronous सहयोग तब काम करता है जब आउटपुट इतना predictable हो कि उस पर भरोसा किया जा सके और उसकी जाँच की जा सके। इसीलिए साझा Workflow, मानव समीक्षा मानक और permission model मायने रखते हैं। एक अस्पष्ट प्रक्रिया को automate करने से केवल अस्पष्ट काम ज़्यादा बार होता है।
एक Automation एक Workflow से schedule या event trigger जोड़ता है, ताकि बार-बार होने वाला काम किसी के prompt करने का इंतज़ार किए बिना शुरू हो सके।
एक लीड, एक सहयोग लूप
सोमवार की सुबह आई उस लीड पर वापस आते हैं।
टीम के Shared Agent के पास पहले से ICP, approved positioning और रिसर्च नियम हैं। एक rep lead-qualification Workflow चलाता है। Zero inbound ईमेल पढ़ता है, ब्राउज़र और connected sources के ज़रिए कंपनी पर रिसर्च करता है, आवश्यक मानदंड जाँचता है, और एक reply draft के साथ एक account brief बनाता है।
Sales lead इसकी समीक्षा करती है और एक कमज़ोर assumption पाती है। वह Zero से unsupported employee estimates को बाहर करने, हर qualification दावे के लिए स्रोत cite करने, और prospect के वर्तमान उत्पाद से जुड़े use case के साथ शुरू करने के लिए कहती है। Zero brief को फिर से करता है और draft अपडेट करता है।
टीम तय करती है कि ये बदलाव भविष्य की लीड्स पर भी लागू होने चाहिए, इसलिए Workflow संपादित किया जाता है। एक अन्य rep अब बेहतर संस्करण चला सकता है। हर rep नए inbound emails के लिए अपने credentials और permissions का उपयोग करके एक personal Automation बना सकता है।
ईमेल draft उपयोगी है। बड़ा लाभ यह है कि हैंडऑफ ने अगली लीड को संभालने की टीम की दोहराने योग्य क्षमता को बेहतर बनाया।
यह पारंपरिक automation से ज़्यादा है
स्पष्ट आपत्ति यह है कि कंपनियाँ वर्षों से automated workflows का उपयोग कर रही हैं। यह सच है, और stable, rules-based automation कई प्रक्रियाओं के लिए सही जवाब बना रहता है।
Collaborative काम अक्सर कम settled होता है। Inputs अव्यवस्थित होते हैं। रिसर्च शुरू होने के बाद रास्ता बदल जाता है। गुणवत्ता उस judgment पर निर्भर करती है जिसे लोगों ने कभी लिखा नहीं। एक मैनेजर एक कमज़ोर account brief देखते ही पहचान सकता है लेकिन पहला draft देखने से पहले पूरा मानक व्यक्त करने में संघर्ष कर सकता है।
Zero टीम को natural language में काम शुरू करने, एक असली डिलीवरेबल की जाँच करने, और समीक्षा के ज़रिए तरीके को ज़्यादा स्पष्ट बनाने देता है। एक बार जब प्रक्रिया पर्याप्त रूप से stable हो जाती है, तो टीम इसे Workflow के रूप में सुरक्षित कर सकती है और तय कर सकती है कि इसे Automation के ज़रिए चलाना चाहिए या नहीं।
कुछ सीमाएँ हैं। Zero ownership, समीक्षा, या कठिन बातचीत की ज़रूरत को नहीं हटाता। Creative direction, strategic tradeoffs, और sensitive approvals अभी भी लोगों के पास रहते हैं। यह भी दावा नहीं करना चाहिए कि यह हर interaction से कंपनी को अपने आप सीखता है। आज, durable learning का कदम जानबूझकर है: एक व्यक्ति Workflow को save या edit करता है।
ये सीमाएँ design का हिस्सा हैं। अच्छे टीम सहयोग के लिए स्पष्ट मानवीय judgment और स्पष्ट machine ज़िम्मेदारी चाहिए।
AI टीम सहयोग की नई इकाई एक executable standard है
Messages लोगों को बात करने में मदद करते हैं। Documents लोगों को याद रखने में मदद करते हैं। Tasks लोगों को ज़िम्मेदारी track करने में मदद करते हैं। Zero एक ऐसी इकाई जोड़ता है जो टीमों के पास नहीं थी: एक standard जो काम कर सके।
इससे बदलता है कि टीम collaboration software का मूल्यांकन कैसे करे। पूछें:
- क्या अगला व्यक्ति संदर्भ inherit करता है, या उसे फिर से बनाता है?
- क्या सिस्टम आवश्यक टूल्स में तरीका carry out कर सकता है?
- क्या मानवीय फ़ीडबैक एक स्पष्ट, समीक्षा योग्य standard बन सकता है?
- क्या तरीके को किसी और की पहचान साझा किए बिना पुन: उपयोग किया जा सकता है?
- क्या काम तब भी जारी रह सकता है जब इसे आगे बढ़ाने के लिए कोई मौजूद न हो?
अगर जवाब हाँ है, तो सहयोग compound होना शुरू होता है। एक पूरा हुआ काम केवल एक artifact नहीं छोड़ता। यह टीम को वह काम फिर से करने के लिए बेहतर तैयार छोड़ता है।
एक बार-बार होने वाले हैंडऑफ से शुरू करें: एक साप्ताहिक brief, एक inbound lead, एक support escalation, या एक release report। इसे एक स्पष्ट डिलीवरेबल, एक नामित समीक्षक, और उन सिस्टम तक पहुँच दें जिनकी इसे ज़रूरत है। इसे एक बार Zero के साथ चलाएँ। काम की समीक्षा करें। जो तरीका बचे उसे save करें।
लक्ष्य सरल है: हर बार जब काम किसी हैंडऑफ को पार करे, तो कम इरादा खोना चाहिए।
