एक प्रोजेक्ट पर इंसान और एजेंट: चैट ऐप वाला मॉडल क्यों नहीं चलता

हम चाहते हैं कि Orkas वह आधार बने जिस पर कोई AI-नेटिव कंपनी चलती है। यह लक्ष्य सीधे एक सवाल पर ले आता है: एक ही प्रोजेक्ट पर कई लोग और कई एजेंट मिलकर कैसे काम करें?

इसका जवाब उस टीमवर्क से काफ़ी अलग दिखता है जिसके हम आदी हैं। ऐसा क्यों है, यह समझने के लिए पहले यह देखना मददगार है कि इंसानी सहयोग का ढाँचा कहाँ से आया। (Orkas में यह कदम-दर-कदम कैसे काम करता है, यह जानने के लिए साझा प्रोजेक्ट: Orkas में लोग और AI एजेंट मिलकर कैसे काम करते हैं देखें। यह लेख उसके पीछे की सोच के बारे में है।)

इंसानी सहयोग दो इंसानी सीमाओं के इर्द-गिर्द बना

पहली, लोगों की बैंडविड्थ और याददाश्त सीमित होती है। हम एक बार में एक हद तक ही जानकारी ले पाते हैं, और एक हद तक ही याद रख पाते हैं। इसलिए टीमों को लगातार बात करनी पड़ती है: अपडेट साझा करना, लक्ष्यों पर एकमत होना, प्रगति पर तालमेल बिठाना। साप्ताहिक मीटिंग, स्टैंड-अप, दैनिक और साप्ताहिक रिपोर्ट, “ज़रा सिंक कर लें?”, “एक बार अलाइन कर लेते हैं”: यह सब इसी सीमा की भरपाई के लिए है।

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

एजेंटों के जुड़ने पर क्या बदलता है

लोगों और एजेंटों वाली टीम में सहयोग का इंसानी पहलू अब भी मायने रखता है। लेकिन एजेंटों के साथ काम करना लोगों के साथ काम करने से बहुत अलग है। एजेंटों की तीन साफ़ खूबियाँ हैं और तीन साफ़ कमज़ोरियाँ।

तीन खूबियाँ

ऊँची बैंडविड्थ और दमदार अमल। यह खासकर उन कामों पर लागू होता है जिनके लक्ष्य साफ़ और मापने लायक हों। और एजेंट जो काम पूरे कर पाते हैं, वे तेज़ी से लंबे, कठिन और जटिल होते जा रहे हैं। अपने कोडिंग एजेंट के बारे में बताते हुए Meta ने GPU कर्नेल ऑप्टिमाइज़ेशन के एक काम का ज़िक्र किया है, जिसमें एजेंट ने 24 घंटे तक काम किया और 1,000 से ज़्यादा टूल कॉल किए (Meta)। अक्तूबर 2026 में Linus Torvalds ने Linux कर्नेल की एक पैच सीरीज़ पोस्ट की, जिसका कोड, टेस्ट प्रोग्राम और कमिट मैसेज का पहला ड्राफ़्ट Claude Code ने लिखा था; माप उन्होंने अपनी मशीन पर खुद लिए (LWN)।

दुनिया भर का ज्ञान और टूल, अलग-अलग विधाओं में शुरू से आखिर तक। प्री-ट्रेनिंग दुनिया भर का ज्ञान पहले ही मॉडल में भर चुकी है। सही टूल मिलें, तो एक एजेंट किसी एक काम को अलग-अलग विधाओं से गुज़ारते हुए शुरू से आखिर तक ले जा सकता है: PRD लिखना → डिज़ाइन → डेवलपमेंट → टेस्टिंग → रिलीज़। यही काम लोग करें, तो प्रोडक्ट, डिज़ाइन, इंजीनियरिंग और QA को साथ मिलकर काम करना पड़ता है, और हर हैंडऑफ़ पर तालमेल का एक और दौर चलता है।

इंसानी कमज़ोरियाँ कम, और पहले भरोसा बनाने की ज़रूरत नहीं। एजेंट थकता नहीं, उसका कोई बुरा दिन नहीं होता, और बुनियादी सवाल पूछने में उसे झिझक नहीं होती। नया एजेंट प्रोजेक्ट का संदर्भ मिलते ही काम शुरू कर सकता है। न काम में रमने का कोई दौर, न पहले रिश्ता बनाने की ज़रूरत।

तीन कमज़ोरियाँ

उसे साफ़ संदर्भ चाहिए। गलत संदर्भ उसे भटका देता है। हम खुद इससे टकरा चुके हैं: हमारे एनालिटिक्स डैशबोर्ड के एक फ़ील्ड में लिखा था कि डेटा “जोड़ा नहीं जा सकता”, जबकि असल में जोड़ा जा सकता था; उस फ़ील्ड की गणना ही गलत थी। दो अलग-अलग एजेंटों ने वह पंक्ति पढ़ी और दोनों ने यूज़र जर्नी का पूरा विश्लेषण छोड़ दिया। कोई इंसान वह निष्कर्ष देखता, तो पूछता: “क्या यह अब भी सही है?” एजेंट आम तौर पर उसे जस का तस मान लेता है।

लंबी अवधि में असली कारण पहचानने में वह कमज़ोर है। जब कई कारक एक साथ नतीजे पर असर डालते हैं, तो वह आसानी से गलत कारक को दोष दे देता है, और लोगों को उसे सुधारना पड़ता है। कुछ समय तक हमारी साइट के कुछ नए पेज Google में इंडेक्स नहीं हो रहे थे। एक एजेंट ने निष्कर्ष निकाला कि “साइट की अथॉरिटी काफ़ी नहीं है, इसलिए Google उस पर क्रॉल बजट खर्च नहीं करेगा”, और सुझाव दिया कि पहले बैकलिंक बनाए जाएँ। हमने इस पर सवाल उठाया और जाँच की: साइट के ज़्यादातर पेज पहले से इंडेक्स थे। जो थोड़े-से पेज इंडेक्स नहीं हुए थे, उनका मामला ज़्यादा ऐसा लग रहा था कि उनके विषय साइट के मूल विषय से बहुत दूर थे। क्रॉल बजट का इससे कोई लेना-देना नहीं था, और बैकलिंक बनाना गलत कदम होता।

बदलते माहौल के मुताबिक ढलने में वह कमज़ोर है, खासकर तब जब वह बदलाव उसके प्री-ट्रेनिंग डेटा में न हो। हाल ही में नए सिरे से डिज़ाइन हुई साइट, अभी-अभी बदला किसी प्लेटफ़ॉर्म का नियम, पिछले महीने लॉन्च हुआ कोई प्रोडक्ट: इंसान भाँप लेता है कि “कुछ बदल गया है” और अपना तरीका बदल लेता है। एजेंट अक्सर अपनी पहले से मौजूद जानकारी के भरोसे चलता रहता है और वही चीज़ बार-बार आज़माता रहता है।

चैट ऐप क्यों ठीक नहीं बैठते

चैट ऐप इस हिसाब से बने थे कि लोग लोगों के साथ काम करें: संदेश एक के बाद एक ऊपर सरकते जाते हैं, @मेंशन और रीड रिसीट से सबको पता रहता है कि क्या चल रहा है, और जानकारी अलग-अलग चैनलों में बिखरी रहती है। यह डिज़ाइन ठीक ऊपर बताई गई उन्हीं दो सीमाओं की भरपाई करता है। लोगों की बैंडविड्थ कम और याददाश्त छोटी होती है, इसलिए हम बार-बार पोस्ट करते हैं और बार-बार तालमेल बिठाते हैं।

एजेंटों के लिए यह ढाँचा ही गलत है:

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

इसलिए लोगों और एजेंटों के बीच सहयोग को नए सिरे से डिज़ाइन करना होगा। और जैसे-जैसे एजेंट ज़्यादा सक्षम होते जाएँगे, हमारे सहयोग का तरीका भी बदलता रहेगा। Orkas में हम इसे अभी सुलझा ही रहे हैं।

Orkas का तरीका: जो नहीं बदला, उसे बनाए रखना; जो बदला, उसे नए सिरे से डिज़ाइन करना

हमारा तरीका है सहयोग के उन हिस्सों को बनाए रखना जो नहीं बदले, और जो बदल गए हैं उन्हें नए सिरे से डिज़ाइन करना। नीचे Orkas का एक साझा प्रोजेक्ट है; चारों विचार हाइलाइट किए गए चार हिस्सों से मेल खाते हैं।

1. काम सौंपना, आगे बढ़ाना और जाँचना: “करना है” सूची

यह एजेंटों से बहुत पहले से मौजूद था, और हमें इसकी अब भी ज़रूरत है। फ़िलहाल हमारे प्रोजेक्ट के हर काम का एक इंसानी मालिक होता है, और अंतिम नतीजे की ज़िम्मेदारी एक व्यक्ति की होती है।

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

2. लक्ष्य, पृष्ठभूमि और संदर्भ साझा करना: “लक्ष्य और नियम”, “मेमोरी”

यहाँ लोग और एजेंट एक ही संदर्भ साझा करते हैं, ताकि अहम तथ्यों पर सब एकमत रहें।

किसी प्रोजेक्ट के “लक्ष्य और नियम” और “मेमोरी” इस प्रोजेक्ट की हर बातचीत में साझा रहते हैं, और एजेंट हर बार उनका पालन करते हैं। उदाहरण के लिए, “लक्ष्य और नियम” में किसी मीट्रिक की परिभाषा लिखें, जैसे “मासिक रिटेंशन = वे नए उपयोगकर्ता जो अगले महीने वापस आते हैं”, और अहम फ़ैसले प्रोजेक्ट मेमोरी में दर्ज करें। जब कोई नया सदस्य और उसके एजेंट जुड़ते हैं, तो पहले ही दिन वे ठीक वही चीज़ पढ़ते हैं।

3. हैंडऑफ़ फ़ाइलों से, प्रक्रिया अलग

प्रोजेक्ट की लाइब्रेरी सदस्यों के बीच सिंक होती है, और किसी करने योग्य मद के साथ कोई भी फ़ाइल अटैचमेंट के रूप में जोड़ी जा सकती है। काम फ़ाइलों के रूप में सौंपा जाता है, चैट हिस्ट्री के रूप में नहीं।

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

4. निजी एजेंट टीम के साथ साझा करें

सदस्य अपने निजी एजेंट बाकी टीम के इस्तेमाल के लिए साझा कर सकते हैं। इन एजेंटों में उनके मालिक का अनुभव और गुणवत्ता की उसकी परख होती है। इन्हें साझा करने से सबका काम तेज़ होता है, और इस्तेमाल के दौरान लोगों को जो समस्याएँ मिलती हैं, उन्हें स्व-विकास के ज़रिए ठीक किया जा सकता है, जिससे पूरे प्रोजेक्ट की क्षमता बढ़ती है।

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

एक शुरुआती, खुला सवाल

लोगों और एजेंटों के बीच सहयोग अभी बहुत शुरुआती दौर में है, और जवाब अभी किसी एक नतीजे पर नहीं पहुँचे हैं। जैसे-जैसे मॉडल बेहतर होंगे, सहयोग के लिए एजेंटों को जिन चीज़ों की ज़रूरत होती है, उनमें से बहुत कुछ खुद मॉडल के भीतर चला जाएगा।

कुछ मॉडल यह पहले से ही अपने-आप कर सकते हैं: किसी समस्या को अलग-अलग कोणों से परखने के लिए कई सब-एजेंट एक साथ चलाना, या पहले योजना बनाना और फिर उसे पूरा करने के लिए सब-एजेंट भेजना। Meta ने अक्तूबर 2026 में Muse Spark Open को ओपन वेट्स के रूप में जारी किया; उसके बारे में बताया गया है कि उसे काम को टुकड़ों में बाँटने, उन्हें सब-एजेंटों को सौंपने और उनके बीच तालमेल बिठाने के लिए प्रशिक्षित किया गया है (PyTorch ब्लॉग)।

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

अंत में

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

हम अभी भी इसे खोज रहे हैं, और आपसे अनुभव साझा करना चाहेंगे। अगर आप ऐसी टीम चलाते हैं जिसमें लोग और एजेंट साथ काम करते हैं, तो पहले इसे किसी एक प्रोजेक्ट पर आज़माएँ। macOS और Windows के लिए Orkas डाउनलोड करना मुफ़्त है।