जब एजेंट सहयोगी बन जाते हैं: Buzz के पीछे का विचार

Buzz के बारे में मैं पहले भी लिख चुका हूं, तब मेरा फोकस स्पष्ट रूप से Shared Compute और साझा मॉडल संचालन पर था। मेरे लिए शुरुआत में यह प्रोजेक्ट का सबसे रोमांचक और असामान्य हिस्सा था। लेकिन जितना अधिक समय मैं Buzz के साथ बिताता हूं, उतना ही दिलचस्प खुद वर्कस्पेस बनता जाता है। इसी वजह से मैंने Buzz को अब एक छोटे सेटअप में आज़माया है।

इसका एक कारण एक समस्या भी है जिसे मैं पिछले कुछ महीनों में लगातार अधिक महसूस कर रहा हूं। AI के साथ मेरा काम न केवल तेज़ हुआ है, बल्कि अधिक अव्यवस्थित भी हो गया है। Codex एक रिपॉज़िटरी पर काम करता है, Claude Code दूसरे विचार की जांच करता है, कोई अन्य एजेंट जानकारी इकट्ठा करता है, और बीच में कहीं टर्मिनल, ब्राउज़र, ईमेल और कई चैट चलते रहते हैं। हर एजेंट अपने आप में उपयोगी हो सकता है। समस्या ट्रांज़िशन पर पैदा होती है। कॉन्टेक्स्ट को कॉपी करना पड़ता है, फैसलों को दोहराना पड़ता है और नतीजों को मैन्युअली एक साथ लाना पड़ता है।

ठीक यहीं Buzz शुरू होता है। यह ओपन-सोर्स प्रोजेक्ट Block से आता है, जो Twitter के सह-संस्थापक Jack Dorsey द्वारा चलाई जाने वाली और Square के पीछे की कंपनी है। यह एक और AI असिस्टेंट बनाना नहीं चाहता। Buzz एक साझा वर्कस्पेस बनाता है जिसमें लोग और एजेंट एक ही चैनल, थ्रेड, प्रोजेक्ट और प्रोटोकॉल इस्तेमाल करते हैं। एक Codex एजेंट प्लान बना सकता है, Claude Code उसकी आलोचना कर सकता है, कोई इंसान फैसला ले सकता है और अगला एजेंट उसमें से रिपॉज़िटरी में बदलाव कर सकता है। पूरी चेन एक ही स्थान में दिखाई देती रहती है।

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

असली समस्या मॉडल नहीं है

अधिकतर AI उपकरण एक इंसान और एक एजेंट के बीच के रिश्ते के रूप में बने हैं। मैं Codex खोलता हूं, कोई काम दर्ज करता हूं और नतीजा मिलता है। इसके बाद मैं Claude Code खोलता हूं, वही पृष्ठभूमि दोबारा समझाता हूं और दूसरी राय मांगता हूं। अकेले कामों के लिए यह अच्छी तरह काम करता है। लेकिन किसी टीम में या कई समानांतर चलने वाले एजेंटों के साथ एक नई समन्वय समस्या पैदा होती है।

यही समस्या मैं अपनी रोज़मर्रा की ज़िंदगी से जानता हूं। Claude Code, Codex, Hermes, ब्राउज़र, चैट और कई टर्मिनल साथ-साथ चलते हैं। सेशन के लॉग एक टूल से दूसरे टूल में जाते रहते हैं। एक एजेंट को मीटिंग नोट्स पता होते हैं, दूसरे को रिपॉज़िटरी और तीसरे को ज़रूरी एक्सेस या स्किल्स। हर किसी के पास एक टुकड़ा है, लेकिन किसी के पास भी साझा कार्यस्थिति नहीं है।

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

एजेंट सदस्य हैं, चिपकाए गए बॉट नहीं

पहली नज़र में Buzz जाना-पहचाना लगता है। इसमें कम्युनिटीज़, सार्वजनिक और निजी चैनल, थ्रेड, डायरेक्ट मैसेज, फोरम, सर्च, हडल्स और एक मोबाइल ऐप है। सामान्य Slack इंटीग्रेशन से निर्णायक अंतर इसके नीचे छिपा है।

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

यह शुरुआत में यूज़र मैनेजमेंट का एक छोटा-सा बदलाव लगता है। लेकिन असली काम के लिए यह केंद्रीय है। एक Slack बॉट आमतौर पर किसी इंटीग्रेशन से जुड़ा होता है और किसी इंसान द्वारा मेंशन किए जाने का इंतज़ार करता है। अलग-अलग प्रदाताओं के दो बॉट आमतौर पर एक-दूसरे के बारे में कुछ नहीं जानते। Buzz में एजेंट दूसरे एजेंटों को संबोधित कर सकते हैं, टास्क सौंप सकते हैं और अपने नतीजों पर उसी थ्रेड में चर्चा कर सकते हैं। इससे Codex और Claude Code एक ही सिस्टम नहीं बन जाते। लेकिन उन्हें एक साझा संचार स्थान मिल जाता है।

Buzz खुद से सारी इंटेलिजेंस साथ नहीं लाता। वर्कस्पेस तथाकथित हार्नेस और मॉडलों को जोड़ता है जो पहले से लोकल, किसी सर्वर पर या किसी प्रदाता के ज़रिए चल रहे होते हैं। वर्तमान प्रोजेक्ट स्थिति के अनुसार इनमें Codex, Claude Code और Goose शामिल हैं। अन्य एजेंट खुले इंटरफ़ेस के ज़रिए जोड़े जा सकते हैं। यह एक “अपना एजेंट खुद लाओ” मॉडल है: Buzz समन्वय करता है, जबकि संबंधित एजेंट अपने ही टूल्स, स्किल्स, एक्सेस और मॉडल लागतों के साथ सोचता और काम करता है।

Relay साझा कार्यस्थिति है

तकनीकी रूप से Buzz कई हिस्सों से बना है। डेस्कटॉप ऐप इंटरफ़ेस है। कम्युनिटी असली वर्कस्पेस है। Buzz Relay इसके मैसेज, सदस्यों, एजेंटों, नियमों, मीडिया, सर्च डेटा, वर्कफ़्लो और Git इवेंट्स को स्टोर और वितरित करता है। एजेंट उसी मशीन पर काम कर सकते हैं जिस पर डेस्कटॉप ऐप है, किसी हमेशा चलने वाले सर्वर पर, या पूरी तरह अलग मशीन पर।

प्रोटोकॉल के रूप में Buzz Nostr का इस्तेमाल करता है। लोग और एजेंट अपनी निजी कुंजियों से इवेंट्स को साइन करते हैं। Relay पहचान और सदस्यता जांचता है, इवेंट्स को स्टोर करता है और उन्हें अधिकृत क्लाइंट्स तक पहुंचाता है। इससे Buzz कोई जादुई पीयर-टू-पीयर नेटवर्क नहीं बन जाता। Relay किसी कम्युनिटी का केंद्रीय स्रोत है। रिले के बीच कोई स्वचालित रेप्लिकेशन नहीं होता, और मैसेज उसी रिले पर रहते हैं जिस पर वे भेजे गए थे।

इस बनावट के दो दिलचस्प नतीजे हैं। पहचान किसी केंद्रीय Slack अकाउंट की न होकर एक अपनी की-पेयर पर आधारित होती है। साथ ही, कोई टीम वर्कस्पेस को खुद संचालित कर सकती है। जो पहले केवल टेस्ट करना चाहता है, वह Block द्वारा होस्ट की गई कम्युनिटी इस्तेमाल कर सकता है। जो डेटा होल्डिंग, उपलब्धता और बैकअप खुद नियंत्रित करना चाहता है, वह Relay अपनी इन्फ्रास्ट्रक्चर पर चला सकता है।

मौजूदा सर्वर आर्किटेक्चर जानी-मानी कॉम्पोनेंट्स का इस्तेमाल करता है: इवेंट्स और फुल-टेक्स्ट सर्च के लिए PostgreSQL, पब/सब के लिए Redis, और मीडिया के लिए S3-compatible स्टोरेज। यह कोई छोटी सर्विस नहीं है जिसे इंस्टॉल करने के बाद भुला दिया जाए। खुद चलाए गए Relay को TLS, अपडेट्स, बैकअप, मॉनिटरिंग और साफ-सुथरे की मैनेजमेंट की ज़रूरत होती है।

साझा कॉन्टेक्स्ट इतना मूल्यवान क्यों है

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

यह खासतौर पर तब उपयोगी है जब अलग-अलग एजेंटों की अलग-अलग ताकत हो। एक यथार्थवादी प्रक्रिया इस तरह दिख सकती है:

1. एक इंसान प्रोजेक्ट चैनल में लक्ष्य और सीमाएं बताता है।
2. एक रिसर्च एजेंट जानकारी इकट्ठा करता है और अपने स्रोत दर्ज करता है।
3. दूसरा एजेंट कमज़ोर बिंदुओं पर हमला करता है और प्रतिवाद ढूंढता है।
4. Codex या Claude Code एक ठोस योजना बनाता है।
5. एक अन्य एजेंट योजना को सुरक्षा, छूटे टेस्ट या अस्पष्ट मान्यताओं के लिए जांचता है।
6. इंसान की मंज़ूरी के बाद बदलाव को अलग वर्कट्री में लागू किया जाता है।
7. डिफ, टेस्ट नतीजे, रिव्यू और फैसला संबंधित चैनल में मिलते रहते हैं।

यह पैटर्न विरोधात्मक (adversarial) रिव्यू में खासतौर पर दिलचस्प है। एक मॉडल को स्पष्ट रूप से यह भूमिका मिलती है कि वह किसी प्रोडक्ट प्लान या इम्प्लीमेंटेशन पर हमला करे। दूसरे मॉडल को फैसलों का बचाव करना या उन्हें बेहतर बनाना है। क्योंकि दोनों को पूरा थ्रेड दिखता है, अब तक की कार्यस्थिति से एक असली मुकाबला पैदा होता है, न कि किसी कॉपी किए गए टेक्स्ट का अलग-थलग रिव्यू।

कंटेंट और बिज़नेस प्रक्रियाओं के लिए भी यह पैटर्न दिलचस्प है। एक एजेंट विषयों पर रिसर्च करता है, दूसरा लिखता है, तीसरा एडिट करता है। मेट्रिक्स या नई खबरें नियमित रूप से किसी चैनल में आ सकती हैं ताकि लोग और एजेंट मिलकर विकास पर चर्चा कर सकें। हडल्स एक कदम और आगे जाते हैं: लोग और एजेंट ऑडियो कॉन्फ्रेंस में बात करते हैं, बातचीत को टेक्स्ट में बदला जाता है और फिर उसे ठोस टास्क में तब्दील किया जा सकता है।

यही वह बिंदु है जहां Buzz महज़ ग्रुप चैट से कहीं आगे बढ़ जाता है। चैनल केवल संचार की जगह नहीं है। यह एक समझ में आने वाला कार्य लॉग बन जाता है।

Buzz GitHub को भी बदलना चाहता है

Buzz Git रिपॉज़िटरीज़, पैचेस, रिव्यू और स्टेटस इवेंट्स को उसी वर्कस्पेस में जोड़ता है। Relay खुद रिपॉज़िटरीज़ को होस्ट कर सकता है। एजेंट वर्कट्री इस्तेमाल कर सकते हैं, अलग-अलग वैरिएंट पर अलग से काम कर सकते हैं, बदलावों को पैच के रूप में तैयार कर सकते हैं और रिव्यू को प्रोजेक्ट कॉन्टेक्स्ट में डिस्कस कर सकते हैं।

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

फिर भी, मैं GitHub को अभी जल्दबाज़ी में खारिज नहीं करूंगा। GitHub केवल Git स्टोरेज नहीं है, बल्कि अधिकारों, रिव्यू, CI/CD, सिक्योरिटी स्कैन, रिलीज़, इंटीग्रेशन और बाहरी सहयोग के लिए वर्षों में विकसित एक इकोसिस्टम है। Buzz के पास काम करने वाला Git बुनियादी ढांचा और एक दिलचस्प Forge दृष्टिकोण है। लेकिन खुद प्रोजेक्ट की स्थिति स्पष्ट रूप से पहले से काम कर रहे हिस्सों, अभी जोड़े जा रहे फ़ंक्शन और विज़न के बीच फर्क करती है। महत्वपूर्ण रिपॉज़िटरीज़ के लिए तुरंत माइग्रेशन से ज़्यादा समझदारी क्रमिक इस्तेमाल में है।

Buzz के साथ मेरा पहला टेस्ट

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

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

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

गहन सॉफ्टवेयर डेवलपमेंट के लिए Codex या Claude Code में सीधे काम करना फिर भी तेज़ रहा। Buzz संचार, लॉगिंग और साझा कॉन्टेक्स्ट जोड़ता है। यह परत समय और टोकन्स खर्च करती है। हर अतिरिक्त एजेंट का अपना सेशन होता है, और कई मॉडलों के साथ व्यापक चैनल हिस्ट्री को कई बार प्रोसेस किया जा सकता है। इसलिए किसी लंबे कोडिंग रन के लिए मैं अब भी नेटिव हार्नेस इस्तेमाल करूंगा और Buzz को अधिक योजना, हैंडओवर और रिव्यू के लिए इस्तेमाल करूंगा।

अभी तक मैंने वर्कफ़्लो, लंबे हडल्स, लोकल मॉडल्स और कई हमेशा चलने वाले रिमोट एजेंटों को गहराई से टेस्ट नहीं किया है। ठीक यहीं Buzz को रोज़मर्रा में यह साबित करना होगा कि टास्क न केवल अच्छे से दिखते हैं, बल्कि भरोसेमंद तरीके से पूरे भी होते हैं। सॉफ्टवेयर अभी वर्ज़न 1.0 से पहले है और कुछ जगहों पर तदनुसार युवा महसूस होता है। प्रयोगों के लिए यह ठीक है। लेकिन केंद्रीय प्रक्रियाओं को अब भी नियंत्रण, दोहराव तर्क और स्पष्ट मैनुअल वापसी के रास्ते की ज़रूरत है।

साझा कॉन्टेक्स्ट एक सुरक्षा सीमा भी है

जो चीज़ Buzz को उपयोगी बनाती है, वही साथ ही हमले की सतह भी बढ़ाती है। जुड़ा हुआ Codex, Claude Code या Hermes एजेंट शायद फ़ाइल एक्सेस, शेल, ब्राउज़र, MCP सर्वर, ईमेल, कैलेंडर या अन्य आंतरिक टूल्स साथ लाता है। अगर कोई टीम सदस्य इस एजेंट को संबोधित कर सकता है, तो अनुमति सिर्फ चैट का जवाब लिखने से कहीं आगे जाती है।

इसलिए सबसे ज़रूरी नियम यह है: एक एजेंट को केवल उन चैनलों में काम करना चाहिए जिनकी सामग्री और सदस्य उसके टूल एक्सेस से मेल खाते हों। चैनल सदस्यता ही केंद्रीय एक्सेस गेट है। जो सदस्य है वह पढ़ और लिख सकता है। जो सदस्य नहीं है, उसे न तो निजी चैनल दिखने चाहिए और न ही उसके इवेंट्स को सब्सक्राइब करने की अनुमति होनी चाहिए।

क्रिप्टोग्राफ़िक हस्ताक्षर हर ऑडिट समस्या हल नहीं करते। Buzz एक चेन-आधारित, छेड़छाड़ दिखने वाला ऑडिट-लॉग रखता है। डेटाबेस पर राइट एक्सेस रखने वाला हमलावर छेड़छाड़ के बाद चेन को फिर से कैलकुलेट कर सकता है। इसलिए यह लॉग tamper-evident है, tamper-resistant नहीं। जब तक स्टोरेज का भरोसा पूरी तरह न टूटा हो, यह बदलावों को पहचानने योग्य बनाता है।

Block द्वारा होस्ट की गई कम्युनिटीज़ के लिए एक और बात जोड़नी होगी: मैसेज, डायरेक्ट मैसेज और अपलोड की गई मीडिया एंड-टू-एंड एन्क्रिप्टेड नहीं हैं। Block संचालन, सुरक्षा, मॉडरेशन या कानूनी दायित्वों के लिए इस सामग्री तक पहुंच सकता है। इसके अलावा, अगर कोई एजेंट किसी क्लाउड सर्विस का इस्तेमाल करता है, तो संबंधित मॉडल प्रदाता को प्रॉम्प्ट्स और चैनल सामग्री मिल सकती है।

Self-Hosting डेटा की स्वामित्व स्थिति को बदल देता है, लेकिन पूरे डेटा फ्लो को स्वचालित रूप से नहीं। अपना Relay मैसेज और फ़ाइलों को अपनी इन्फ्रास्ट्रक्चर पर रखता है। लेकिन अगर एजेंट अब भी किसी क्लाउड मॉडल का इस्तेमाल करता है, तो टास्क के लिए ज़रूरी डेटा फिर भी Relay से बाहर जाता है। सचमुच लोकल संचालन के लिए अपने Relay के साथ-साथ लोकल मॉडल और लोकल टूल्स दोनों चाहिए। Buzz Shared Compute की संभावनाओं और सीमाओं के बारे में मैं पहले ही अलग से लिख चुका हूं।

मैं फिलहाल Buzz को इस तरह इस्तेमाल करता हूं

अपने पहले टेस्ट के लिए मैंने एक छोटी, स्पष्ट रूप से सीमित कम्युनिटी इस्तेमाल की। कोई प्रोडक्शन क्रेडेंशियल्स नहीं, कोई ग्राहक डेटा नहीं और सीक्रेट्स वाली कोई रिपॉज़िटरी नहीं। दो एजेंट पूरी तरह काफी थे: एक बनाता है, एक जांचता है। इसके साथ मैं एक इंसान के रूप में टास्क, मंज़ूरी बिंदु और रुकने की शर्त तय करता हूं।

मेरा पहला सेटअप सौ एजेंटों वाला कोई स्वायत्त उद्यम नहीं था, बल्कि एक सीमित रिव्यू था:

• एक एजेंट मौजूदा इशू से तकनीकी योजना बनाता है।
• दूसरा एजेंट सुरक्षा खामियां, छूटी मान्यताएं और अनावश्यक जटिलता ढूंढता है।
• दोनों को स्रोत, फ़ाइलें और खुले सवाल बताने होते हैं।
• अधिकतम दो चर्चा दौरों के बाद टीम इंसानी मंज़ूरी का इंतज़ार करती है।
• इसके बाद ही कोई एजेंट अलग वर्कट्री में बदलाव तैयार कर सकता है।

इससे मैं Buzz की असली ताकत को टेस्ट कर सका, बिना तुरंत अपना पूरा संचालन बदले। साथ ही टोकन खपत, लेटेंसी, अधिकार और ट्रेसेबिलिटी भी दिखाई दिए।

अकेले काम करने और एक अकेले कोडिंग टास्क के लिए मैं सीधे एजेंट इंटरफ़ेस पर ही रहूंगा। यह तेज़ है और नियंत्रित करना आसान है। Buzz तभी दिलचस्प बनता है जब कई लोग, कई एजेंट या कई कार्यधाराओं को एक ही कॉन्टेक्स्ट चाहिए। इसलिए छोटी डेवलपर टीमें, एजेंसियां, रिसर्च ग्रुप्स और तकनीकी रूप से निपुण सोलोप्रेन्योर्स स्वाभाविक लक्ष्य समूह हैं।

किसी बड़ी कंपनी के लिए मैं ज़्यादा सावधान रहूंगा। वर्ज़न 1.0 से पहले, बिना लंबी सपोर्ट लाइन के और अब भी युवा वर्कफ़्लो के साथ, मैं Buzz को महत्वपूर्ण संचार या सोर्स कोड के लिए इकलौती जगह नहीं बनाऊंगा। कोई पायलट प्रोजेक्ट समझदारी हो सकता है। Slack और GitHub को पूरी तरह बदलना फिलहाल प्रोजेक्ट की विकास गति पर लगाया गया एक दांव होगा।

Buzz के पीछे का विचार मौजूदा क्लाइंट से बड़ा है

Buzz का सबसे दिलचस्प हिस्सा मेरे लिए कोई अकेला फ़ीचर नहीं है। चैनल, फोरम, हडल्स, Git-होस्टिंग और लोकल मॉडल दूसरी जगहों पर भी मौजूद हैं। नई बात यह ठोस मान्यता है कि एजेंट अब केवल अलग-अलग यूज़र के निजी टूल नहीं रहे। वे साझा कार्य प्रक्रिया के दिखाई देने वाले प्रतिभागी बन जाते हैं।

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

Buzz अभी कोई तैयार जवाब नहीं देता। सॉफ्टवेयर युवा है, कुछ वर्कफ़्लो अविश्वसनीय हैं, साझा कॉन्टेक्स्ट महंगा हो सकता है और Self-Hosting असली संचालन ज़िम्मेदारी लाता है। फिर भी यह प्रोजेक्ट एक असली समस्या पर सटीक बैठता है। जब एजेंट अधिक से अधिक काम संभालने लगते हैं, तो पांच अलग-अलग चैट साथ-साथ खोलना पर्याप्त नहीं है। हमें एक साझा जगह चाहिए जहां उनका काम दिखाई देने वाला, सीमित और जांचने योग्य बना रहे।

शायद Buzz कभी Slack और GitHub की जगह ले ले। आज के लिए एक छोटा लेकिन ज़्यादा महत्वपूर्ण दावा काफी है: Buzz इस बात का एक दमदार प्रारूप है कि जब उसमें सिर्फ इंसान काम नहीं कर रहे, तो वर्कस्पेस कैसा दिख सकता है। Shared Compute ने मुझे इस प्रोजेक्ट पर ध्यान दिलाया। साझा वर्कस्पेस वह वजह है जिसके लिए मैं Buzz को आगे टेस्ट करता रहूंगा।

पहले टेस्ट के बाद मेरा निष्कर्ष

Buzz ने मेरे छोटे टेस्ट में ठीक उसी समस्या को छुआ जो मुझे इस समय AI एजेंटों के साथ है। अलग-अलग मॉडल अब कतई बाधा नहीं हैं। मुश्किल यह है कि कई एजेंटों, फैसलों और नतीजों को एक साझा लाइन पर बनाए रखा जाए। Buzz इस काम को दिखाई देने योग्य बनाता है और Codex, Claude Code तथा दूसरे एजेंटों को ऐसी जगह देता है जहां वे न केवल मुझ पर, बल्कि एक-दूसरे पर भी प्रतिक्रिया दे सकते हैं।

मुझे साझा कॉन्टेक्स्ट, स्पष्ट रूप से अलग एजेंट पहचानों और किसी नतीजे को सीधे दूसरे मॉडल से चुनौती दिलवा पाने की संभावना ने प्रभावित किया। कम प्रभावित करने वाली रही अतिरिक्त ओवरहेड। एक अकेले कोडिंग टास्क के लिए Codex या Claude Code पर सीधा रास्ता अब भी तेज़ है। जैसे ही कई एजेंट या लोग शामिल होते हैं, Buzz अपनी ताकत दिखाना शुरू करता है।

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

अगली बार तक,
Joe

FAQ