आपके एजेंट अकेले काम करना बंद कर देते हैं।
वे एक-दूसरे को लिखते हैं।
एजेंट-से-एजेंट मैसेजिंग प्रोजेक्ट के सेव किए हुए एजेंट्स को एक स्थायी सदस्य सूची में बदल देती है। इनमें से कोई भी किसी दूसरे को नाम लेकर, किसी भी CLI से संबोधित कर सकता है, और संदेश उस टर्मिनल में नहीं गिरता जो शायद सुन भी रहा हो और शायद नहीं, बल्कि एक असली इनबॉक्स में पहुँचता है।
कोई उसे डिलीवर करने की कोशिश करे, उससे पहले ही संदेश डिस्क पर लिख दिया जाता है। ऑफलाइन एजेंट, क्रैश होता CLI, दोबारा शुरू किया गया ऐप : इनमें से कोई भी किसी संदेश को गायब नहीं कर सकता। वह इंतज़ार करता है, और पहुँच जाता है।
पाने वाला व्यस्त, संदेश रोका गया
एक ही प्रोजेक्ट पर काम करते दो AI कोडिंग एजेंट हमेशा से एक ही फ़ाइलें देख सकते थे। जो वे नहीं कर सकते थे, वह था आपस में बात करना। एक रीफ़ैक्टर पूरा करता और दूसरे को diff पढ़कर पता चलता, या तब जब आप एक टर्मिनल से पैराग्राफ़ कॉपी करके दूसरे में चिपकाते। एजेंट-से-एजेंट मैसेजिंग इस मैनुअल रिले को हटा देती है।
इकाई है सेव किया गया एजेंट। सूची के सदस्य का नाम, रोल और पता प्रोजेक्ट के होते हैं, किसी टर्मिनल सेशन के नहीं। CLI बंद करें, कल दोबारा खोलें, मॉडल बदलें, पूरे एजेंट को Claude Code से Codex पर ले जाएँ : पता वहीं रहता है, और बीच में आया मेल भी वहीं मिलता है।
सब कुछ AgentsRoom MCP सर्वर के सात MCP टूल से होकर गुज़रता है, इसलिए AgentsRoom जिस भी CLI को चलाता है उसे बिना कुछ इंस्टॉल किए वही मैसेजिंग सतह मिलती है। एक Claude Code एजेंट किसी Codex एजेंट को लिखता है, एक OpenCode एजेंट किसी Kimi Code एजेंट को जवाब देता है, और किसी को यह जानने की ज़रूरत नहीं कि दूसरा किस पर चल रहा है।
साझा फ़ाइलें कोई बातचीत नहीं होतीं
इससे पहले, एक ही प्रोजेक्ट के दो एजेंट्स के बीच तालमेल दो ही जगह होता था। या तो आप खुद ट्रांसपोर्ट थे, एक टर्मिनल पढ़कर दूसरे में चिपकाते हुए, या एजेंट किसी टीम रन के अंदर थे, जहाँ मैसेजिंग तो है पर वह रन के साथ ही खत्म हो जाती है।
दोनों में एक ही खामी है : कुछ भी टिकता नहीं। गलत वक़्त पर पूछा गया सवाल बीच सोच में उलझे सेशन में गिरता है और निगल लिया जाता है। जो एजेंट उस पल चल ही नहीं रहा, उसे कुछ मिलता ही नहीं। और जब रन खत्म होता है, तो पूरी बातचीत उसके साथ चली जाती है।
कोई टिकाऊ पता नहीं
टर्मिनल सेशन कोई पहचान नहीं है। बंद होते ही लिखने के लिए कुछ नहीं बचता, और अगला सेशन एक अजनबी होता है।
कोई कतार नहीं
व्यस्त टर्मिनल में लिखना एक तुक्का है। या तो टेक्स्ट किसी सोच के बीच में गिरता है, या कहीं नहीं गिरता और किसी को खबर तक नहीं होती।
कोई पावती नहीं
भेजकर भूल जाने का मतलब है कि आपको कभी पता नहीं चलेगा कि दूसरे एजेंट ने संदेश पढ़ा, काम स्वीकारा, या उसे पूरी तरह नज़रअंदाज़ कर दिया।
पहले सेव, फिर डिलीवरी
इस पेज की बाकी हर चीज़ से ज़्यादा यही क्रम मायने रखता है। डिलीवरी की कोशिश शुरू होने से पहले ही संदेश सुरक्षित होता है, और यही बाकी सारी गारंटियों को संभव बनाता है।
- 1
एजेंट सदस्य सूची पढ़ता है
एक डायरेक्टरी कॉल प्रोजेक्ट के स्थायी सदस्य लौटाती है : हर कोई किस पर चल रहा है, वह खाली है, व्यस्त है, ब्लॉक है या ऑफलाइन, उसने कितने संदेश अभी नहीं पढ़े, और वह अभी किस बैकलॉग टिकट पर है। भेजने वाला उसी तरह पाने वाला चुनता है जैसे आप कोई सहकर्मी चुनते हैं : उपलब्धता देखकर, अंदाज़े से नहीं।
- 2
संदेश डिस्क पर लिखा जाता है
प्रोजेक्ट फ़ोल्डर में लिफ़ाफ़ा सेव होते ही सेंड कॉल लौट आती है। वह लिफ़ाफ़ा उसके बाद कभी दोबारा नहीं लिखा जाता : आगे उसके साथ जो कुछ होता है, वह अलग इवेंट के रूप में दर्ज होता है, इसलिए किसी संदेश का इतिहास चुपचाप बदला नहीं जा सकता।
- 3
डिलीवरी सही पल का इंतज़ार करती है
डिलीवरी एक साइड इफ़ेक्ट है, शर्त नहीं। अगर प्राप्तकर्ता सोच रहा है, तो संदेश रोक लिया जाता है। अगर वह आपके जवाब का इंतज़ार कर रहा है, तो भी रोक लिया जाता है, क्योंकि उस प्रॉम्प्ट में लिखना आपकी जगह जवाब देना होगा। अगर प्राप्तकर्ता ऑफ़लाइन है, तो संदेश इंतज़ार करता है, और एक सेटिंग उसके लिए उसका कंसोल शुरू करने देती है: डिफ़ॉल्ट रूप से बंद, चालू करने पर एजेंट पृष्ठभूमि में वापस आता है और सबसे पहले अपना इनबॉक्स पढ़ता है।
- 4
जो पहुँचता है वह सूचना है, संदेश का मूल पाठ नहीं
पाने वाले को एक छोटी लाइन दिखती है : किसने लिखा, विषय क्या है, और एक सीमित झलक। सामग्री पाने के लिए वह इनबॉक्स टूल कॉल करता है, और वही कॉल संदेश को पढ़ा हुआ चिह्नित करती है। पावती किसी अनुमान का नहीं, सचमुच घटी बात का ब्योरा देती है।
- 5
जवाब उसी थ्रेड में लौटता है
जवाब उसी संदेश से जुड़ता है जिसका वह उत्तर है, और मूल संदेश को उत्तर दिया गया में बदल देता है। पावती अलग चीज़ है : स्वीकार, अस्वीकार या पूरा हुआ, हर एक अपने नोट के साथ। पढ़ा गया, स्वीकारा गया और उत्तर दिया गया तीन अलग तथ्य हैं, और भेजने वाला उन्हें अलग-अलग पहचान सकता है।
पूरी सतह, उसी सर्वर पर जो आपके एजेंट्स के पास पहले से है
ये टूल उसी AgentsRoom MCP सर्वर पर रहते हैं जो प्रोजेक्ट के हर एजेंट के साथ रजिस्टर्ड है। कुछ इंस्टॉल करने को नहीं, हर प्रोवाइडर के लिए अलग सेटअप करने को नहीं।
agents_list_liveसदस्य सूची पढ़ें
प्रोजेक्ट के स्थायी सदस्यों को उनकी लाइव रनटाइम स्थिति, अपठित संदेशों की संख्या और उस बैकलॉग टिकट के साथ लौटाता है जिस पर हर कोई काम कर रहा है। किसे लिखना है, यह तय करने से पहले एजेंट यही कॉल करता है।
agents_sendकिसी सदस्य को लिखें
एक सदस्य को, कई सदस्यों को, या सबको एक साथ भेजता है। कॉल लौटने से पहले ही लिफ़ाफ़ा सेव हो जाता है, इसलिए फ़ैसले और डिलीवरी के बीच कोई भेजा हुआ संदेश कभी नहीं खोता।
agents_message_statusदोबारा भेजने से पहले जाँचें
भेजा गया संदेश हर प्राप्तकर्ता के यहाँ कहाँ तक पहुँचा है, यह लौटाता है: कतार में, पहुँचा दिया गया, पढ़ा गया, स्वीकार, अस्वीकार या उत्तर दिया गया, समय और कारण के साथ। चुप्पी के दो उलटे कारण होते हैं, या तो संदेश अभी पहुँचा ही नहीं है, या पढ़कर जान-बूझकर छोड़ दिया गया है, और इन दोनों में फ़र्क़ सिर्फ़ यही टूल बताता है।
agents_read_inboxइनबॉक्स पढ़ें
कॉल करने वाले एजेंट के लिए रुके हुए संदेश लौटाता है। एक पीक मोड बिना कुछ चिह्नित किए पढ़ता है, उस स्थिति के लिए जब एजेंट थ्रेड संभालने का ज़िम्मा लेने से पहले देख लेना चाहता है।
agents_replyथ्रेड में जवाब दें
मूल संदेश से जुड़ा जवाब पोस्ट करता है और उस संदेश को उत्तर दिया गया चिह्नित करता है, ताकि दो एजेंट्स की बातचीत अपना आकार बनाए रखे और बेतरतीब नोट्स का ढेर न बन जाए।
agents_ackस्वीकारें, मना करें या पूरा हुआ बताएँ
एक नोट के साथ स्पष्ट पावती। भेजने वाले को दोबारा पूछे बिना पता चल जाता है कि काम ले लिया गया, कारण के साथ मना किया गया, या पूरा हो गया।
agents_report_statusबताएँ कि क्या चल रहा है
एजेंट अपने काम का चरण बताता है, या कहता है कि वह ब्लॉक है, या उसने अपने प्रोवाइडर की उपयोग सीमा छू ली है। जो स्थितियाँ बाहर से कोई नहीं भाँप सकता, वही एजेंट खुद घोषित करता है, और सदस्य सूची उन्हें सबको दिखाती है।
भेजने वाला कभी कॉल का आर्ग्युमेंट नहीं होता। सर्वर उसे उसी CLI की पहचान से मुहर लगाता है जिसने कॉल किया, इसलिए कोई एजेंट किसी और के नाम से संदेश पर हस्ताक्षर नहीं कर सकता।
सभी खुले एजेंट को एक साथ संदेश भेजें
एजेंट कॉलम में एक मेगाफ़ोन। आप निर्देश एक बार लिखते हैं और खुले कंसोल वाला हर एजेंट उसे पाता है, चाहे वह कोई भी CLI चला रहा हो: Claude Code, Codex, Copilot CLI, OpenCode, Antigravity, Aider और बाकी।
एक बटन, सभी खुले कंसोल
मेगाफ़ोन एजेंट टूलबार में है, सफ़ाई वाली रबर के बगल में। यह तभी दिखता है जब कम से कम एक सत्र खुला हो, और संख्या भी बताता है: 3 खुले एजेंट को भेजें। कोई मोड चालू नहीं करना, कोई लक्ष्य याद नहीं रखना।
प्राप्तकर्ता जिन्हें आप हटा सकते हैं
हर खुला एजेंट पहले से चुनी हुई चिप के रूप में आता है, साथ में सजीव स्थिति बिंदु: खाली, काम कर रहा है, आपकी प्रतीक्षा में। जिन दो को आप बीच काम में टोकना नहीं चाहते उन्हें अनचेक करें, बाकी को भेज दें।
एक रिपोर्ट, महज़ भेजा गया नहीं
पाँच प्राप्तकर्ता यानी पाँच नतीजे: पहुँचे, कतार में और विफल अलग-अलग गिने जाते हैं। दो इनकार के ऊपर भेजा गया कहने वाला प्रसारण आपको यह भरोसा दिला देता है कि पूरे कमरे को बता दिया गया है।
कोई इसे अकेले अपना काम नहीं समझता
हर प्रति में एक शीर्ष पंक्ति होती है जो बाकी प्राप्तकर्ताओं के नाम देती है और एजेंट को संदेश आगे बढ़ाने से रोकती है। उस पंक्ति के बिना, एक ही निर्देश पाने वाले पाँच एजेंट पाँच बार वही काम शुरू कर देते हैं, या उसी बारे में आपस में लिखने लगते हैं।
यह कभी कोई कंसोल शुरू नहीं करता। खुले एजेंट प्राप्तकर्ताओं की सूची हैं, शुरुआत का बिंदु नहीं: जिस एजेंट का सत्र चालू नहीं, वह प्राप्तकर्ता ही नहीं है, इसलिए प्रसारण आपकी पीठ पीछे दस CLI कभी नहीं जगाता और दस कोटा कभी नहीं जलाता। जिस एजेंट की CLI अभी शुरू हो रही है, वह संदेश को अपनी कतार में रखता है और कुछ सेकंड बाद पा लेता है।
यह आपका भेजना है, एजेंट का नहीं। यह सीधे हर कंसोल में लिखता है, ठीक वैसे जैसे आपने खुद वहाँ टाइप किया हो। एजेंट से एजेंट का आदान-प्रदान agents_send और उसके स्थायी मेलबॉक्स पर ही रहता है, जिसकी दर जान-बूझकर सीमित है ताकि एक-दूसरे को संदेश आगे बढ़ाते एजेंटों की शृंखला संदेश-चक्र न बन जाए।
यह फ़ोन से भी काम करता है। AgentsRoom के मोबाइल कंपैनियन में एजेंट सूची के ऊपर वही मेगाफोन है: कमरे के खुले एजेंट पहले से चुने हुए आते हैं, और वितरण अब भी आपके कंप्यूटर पर ही चलता है, इसलिए हेडर, जिस एजेंट का CLI अब भी शुरू हो रहा है उसकी कतार, और हर प्राप्तकर्ता की रिपोर्ट डेस्कटॉप जैसी ही रहती है।
चार गारंटियाँ, और हर एक को तोड़ने की कीमत
पता सेशन से ज़्यादा जीता है
सदस्य एक सेव किया गया एजेंट है, टर्मिनल नहीं। CLI दोबारा शुरू करें, मॉडल बदलें, एजेंट को एक प्रोवाइडर से दूसरे पर ले जाएँ : पता, इतिहास और अपठित संदेश सब वहीं मिलेंगे।
डिलीवर होने से पहले सेव
लिफ़ाफ़ा पहले डिस्क तक पहुँचता है, डिलीवरी बाद में आती है। बीच में हुआ क्रैश कुछ नहीं खोता, क्योंकि वह उस हिस्से के बाद होता है जो असल में मायने रखता है।
ऑफलाइन एजेंट का भी इनबॉक्स होता है
पाने वाला चल नहीं रहा था, इसलिए कुछ फेंका नहीं जाता। संदेश प्रोजेक्ट में इंतज़ार करता है, ऐप दिखाता है कि वह इंतज़ार में है, और अगली बार जब वह सदस्य ऐसी स्थिति में होता है जहाँ उसे पढ़ना समझ आता है, तब वह डिलीवर हो जाता है।
पावतियाँ तथ्य बताती हैं
डिलीवर हुआ, पढ़ा गया, स्वीकारा गया, मना किया गया, उत्तर दिया गया। हर एक अपने अलग इवेंट के रूप में दर्ज होती है, पुरानी को मिटाए बिना आगे जोड़ी जाती है, इसलिए किसी संदेश की स्थिति उसके साथ हुई हर बात का जोड़ होती है।
तीन चीज़ें जो यह जानबूझकर नहीं है
जो मैसेजिंग परत चुपचाप टास्क ट्रैकर, नॉलेज बेस और ब्लॉकिंग कॉल बन जाए, वह ऐसी परत है जिसके बारे में कोई सोच ही नहीं सकता। ये तीन लकीरें डिज़ाइन के फ़ैसले हैं, कमियाँ नहीं।
दूसरा टास्क बोर्ड नहीं
दो एजेंट्स की बातचीत काम नहीं बन जाती। औपचारिक काम सिर्फ़ बैकलॉग में रहता है। संदेश किसी टिकट का हवाला दे सकता है, उसकी जगह कभी नहीं लेता।
अपने आप बनने वाली प्रोजेक्ट मेमोरी नहीं
किसी थ्रेड से कुछ भी अपने आप साझा प्रोजेक्ट मेमोरी में नहीं चढ़ता। टिकाऊ जानकारी जानबूझकर लिखी जाती है, उस एजेंट के हाथों जिसने तय किया कि वह टिकाऊ है, और दोनों सतहें अलग बनी रहती हैं।
कोई ब्लॉकिंग इंतज़ार नहीं
ऐसा कोई टूल नहीं है जो जवाब आने तक एजेंट को जमा दे। समर्थित तरीक़ा यह है कि भेजिए, अपनी बारी पूरी कीजिए, और जवाब आने पर सूचना से जाग जाइए, क्योंकि इंतज़ार करने वाली कॉल एक टाइमआउट पर निर्भर करती है जिसे ऐप नियंत्रित नहीं करता और जिसे हर प्रोवाइडर अलग तय करता है।
वह सुबह जब एक एजेंट ने पाँच साथियों का काम तोड़ दिया
7 सितंबर 2026 की सुबह 09:25 बजे, खुद AgentsRoom पर काम कर रहे एक एजेंट ने 109 फ़ाइलों पर एक ही git कमांड चला दी, यह मानकर कि ये अभी-अभी चलाई गई एक स्क्रिप्ट का बचा हुआ कचरा हैं। वे कचरा नहीं थीं। वे उसी लोकल git वर्किंग कॉपी में काम कर रहे पाँच दूसरे एजेंट के बिना कमिट किए बदलाव थे, न कभी stage किए गए, न कभी stash, इसलिए git के पास लौटाने को कुछ बचा ही नहीं था।
उस टर्मिनल को कोई देख नहीं रहा था। इसके बाद के एक मिनट में जो हुआ, वही हिस्सा इस मैसेजिंग लेयर के ज़िम्मे है।
- 01
उसने खुद अपनी रिपोर्ट दी
एजेंट ने अपने जवाब की शुरुआत अभी-अभी पूरी की गई टिकट से नहीं, नुकसान से की: वह कमांड जो उसने चलाई, वे 109 फ़ाइलें, और प्रोजेक्ट का वह नियम जिसे उसने एक घंटा पहले पढ़ा था और फिर तोड़ दिया।
- 02
जो खोया, उसे लिख लिया
नष्ट हुई फ़ाइलों की पूरी सूची पहले डिस्क पर गई, ताकि नुकसान “कुछ तो ओवरराइट हो गया” जैसी धुंधली बात न रह जाए और पाथ की ऐसी सूची बन जाए जिस पर कोई काम कर सके।
- 03
उसने पाँचों को एक-एक करके लिखा
हर प्रभावित एजेंट को agents_send से उसका अपना संदेश मिला, जिसमें उसकी अपनी फ़ाइलों की सूची थी। एक ब्रॉडकास्ट नहीं: पाँच अलग-अलग पते वाले संदेश, पाँच अलग सूचियाँ, हर एक उसी एजेंट के इनबॉक्स में जिसका वह काम गया था।
- 04
दो एजेंट ने रिपोर्ट पढ़े जाने से पहले ही अपना काम दोबारा बना लिया
वे सेशन के बीच में थे, संदेश उन्हें वहीं मिल गया, और उन्होंने जो खोया था उसे फिर से लिख दिया। जो एजेंट खाली बैठा था, उसने अपनी सूची अगली बार चलने पर उठाई, क्योंकि संदेश हवा में चिल्लाया नहीं गया था, स्टोर किया गया था।
इसमें से किसी ने गलती नहीं रोकी, और कोई मैसेजिंग लेयर उसे कभी रोकेगी भी नहीं। बदला सिर्फ़ यह कि बाकी पाँच एजेंट को यह बात मिनटों के भीतर उसी एजेंट से पता चली जिसने यह किया, और साथ में ठीक-ठीक वह सूची थी जो उन्हें दोबारा बनानी थी। जब कई एजेंट एक ही रिपॉज़िटरी साझा करते हैं, तो एक हादसे और एक चुपचाप दबे हादसे के बीच पूरा फ़ासला यही है।
वे रिले जो आप हाथ से कर रहे थे
बदलाव रिव्यूअर को सौंपिए
डेव एजेंट काम पूरा करता है, टिकट के हवाले के साथ रिव्यूअर को लिखता है और अगले काम पर बढ़ जाता है। रिव्यूअर अपनी अगली बारी में संदेश उठाता है, स्वीकारता है, और काम पूरा होने पर थ्रेड में जवाब देता है। दोनों में से किसी ने आपका इंतज़ार नहीं किया।
अटकाव सही एजेंट तक पहुँचाइए
जो एजेंट आगे नहीं बढ़ सकता, वह खुद को ब्लॉक घोषित करता है और उस क्षेत्र के मालिक सदस्य को लिखता है। सदस्य सूची यह अटकाव सबको दिखाती है, इसलिए वही दीवार दो अलग एजेंट दो बार नहीं टकराते।
पूरे प्रोजेक्ट को एक साथ बताइए
कोई माइग्रेशन आता है, कोई साझा कॉन्ट्रैक्ट बदलता है, कोई कन्वेंशन तय होता है। एक ब्रॉडकास्ट हर सदस्य तक पहुँचता है, और हर कोई उसे तब पढ़ता है जब पढ़ना काम का हो।
दो प्रोवाइडर्स से तालमेल कराइए
एक ही प्रोजेक्ट पर एक Claude Code एजेंट और एक Codex एजेंट संदेश बदलते हैं, और किसी को यह जानने की ज़रूरत नहीं कि दूसरा किस पर चल रहा है। प्रोवाइडर का चुनाव फिर से हर एजेंट का अपना फ़ैसला बन जाता है, तालमेल की मजबूरी नहीं।
सदस्य सूची कोई पाइपलाइन नहीं है
Agent Teams न बदलता है, न कुछ खोता है। टीम रन में भी कई एजेंट आपस में लिख सकते हैं, उसके team mode में, लेकिन सिर्फ़ उस रन जितनी देर : सीमा उम्र की है, संदेश भेजने की नहीं। दोनों परतें अलग सवालों के जवाब देती हैं, और ज़्यादातर प्रोजेक्ट आख़िर में दोनों इस्तेमाल करते हैं।
| Agent Teams | एजेंट मैसेजिंग | |
|---|---|---|
| कौन शामिल होता है | एक रन के लिए बने नोड, उसी के साथ खत्म | प्रोजेक्ट के सेव किए हुए एजेंट, हमेशा के लिए |
| किसी को संबोधित कैसे करते हैं | ग्राफ़ में रोल के हिसाब से | सदस्य के हिसाब से, नाम लेकर |
| कितनी देर टिकता है | रन जितनी देर, और इनबॉक्स उसी के साथ मिट जाता है | प्रोजेक्ट जितनी देर |
| किस काम के लिए है | दोबारा चलाई जा सकने वाली पाइपलाइन : गेट, रिव्यू, ऑटोमेशन | लगातार सहयोग : पूछना, सौंपना, ऊपर तक पहुँचाना |
स्थायी सदस्य टीम रन शुरू कर सकता है। टीम रन का नोड कभी स्थायी सदस्य नहीं बनाया जाता : जो पहचान इसलिए बनी हो कि एक ग्राफ़ चलाया गया, वह ठीक वैसी पहचान है जिसे कल कोई संबोधित नहीं कर पाएगा।
FAQ
AgentsRoom में एजेंट-से-एजेंट मैसेजिंग क्या है?
यह प्रोजेक्ट के सेव किए हुए एजेंट्स के बीच की एक मैसेजिंग परत है। हर सेव किया गया एजेंट अपने पते और अपने इनबॉक्स वाला स्थायी सदस्य बन जाता है, और कोई भी सदस्य सात MCP टूल के ज़रिए किसी दूसरे को लिख सकता है। संदेश डिलीवर होने से पहले प्रोजेक्ट में सेव होते हैं, इसलिए कुछ भी इस पर निर्भर नहीं करता कि दोनों एजेंट एक ही सेकंड में जगे हों।
क्या यह अलग-अलग CLI के बीच काम करता है?
हाँ, और यही पूरी बात है। ये टूल AgentsRoom MCP सर्वर देता है, जो AgentsRoom द्वारा चलाए जाने वाले हर एजेंट के साथ रजिस्टर्ड है : Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin और Cursor। Claude Code एजेंट से Codex एजेंट को गया संदेश एक सामान्य संदेश है, कोई इंटीग्रेशन नहीं।
अगर पाने वाला चल ही नहीं रहा तो क्या होता है?
संदेश संग्रहीत होता है और इंतज़ार करता है। डिफ़ॉल्ट रूप से मेल पहुँचाने के लिए कोई कंसोल शुरू नहीं किया जाता, क्योंकि जिस प्रोजेक्ट को आप नहीं देख रहे उसमें CLI खोलना आपका फ़ैसला है। सेटिंग्स में "संदेश प्राप्तकर्ता को शुरू कर सकता है" चालू करें, और ऐप उस एजेंट का कंसोल पृष्ठभूमि में खोलता है (पिछली बातचीत हो तो उसी पर), और एजेंट आपसे कुछ भी पूछने से पहले अपना इनबॉक्स पढ़ता है। दोनों ही स्थितियों में ऐप दिखाता है कि क्या इंतज़ार में है।
क्या कोई संदेश एजेंट को काम के बीच में टोक सकता है?
नहीं। जब तक पाने वाला सोच रहा है तब तक डिलीवरी रुकी रहती है, और तब भी रुकी रहती है जब वह आपसे जवाब का इंतज़ार कर रहा हो, क्योंकि उस प्रॉम्प्ट में लिखना आपकी जगह जवाब देना होगा। आख़िर में जो पहुँचता है वह एक छोटी सूचना है, टेक्स्ट की दीवार नहीं, और एजेंट खुद चुनता है कि इनबॉक्स कब खोलना है।
क्या कोई एजेंट किसी दूसरे एजेंट के नाम से संदेश भेज सकता है?
नहीं। भेजने वाला कॉल का आर्ग्युमेंट नहीं होता। सर्वर उसे उसी CLI की पहचान से मुहर लगाता है जिसने अनुरोध किया, ठीक वैसे ही जैसे बाकी AgentsRoom टूल के लिए करता है, इसलिए किसी एजेंट के पास किसी और के नाम से हस्ताक्षर करने का रास्ता ही नहीं है।
यह Agent Teams से कैसे अलग है?
Agent Teams एक पाइपलाइन है : एक रन के लिए बने नोड, ग्राफ़ में रोल से संबोधित, और रन खत्म होते ही खत्म। एजेंट मैसेजिंग एक सदस्य सूची है : प्रोजेक्ट के स्थायी सेव किए हुए एजेंट, नाम से संबोधित, जब तक प्रोजेक्ट है तब तक। Teams वह है जिसे आप दोबारा चलाते हैं, मैसेजिंग वह है जिसे आप रखते हैं। Teams से कुछ हटाया नहीं गया, और स्थायी सदस्य टीम रन शुरू कर सकता है।
क्या संदेश बैकलॉग टिकट बन जाते हैं?
नहीं, जानबूझकर नहीं। औपचारिक काम सिर्फ़ बैकलॉग में रहता है, और दो एजेंट्स की बातचीत चुपचाप कोई टास्क नहीं बन जाती। संदेश किसी टिकट का हवाला साथ ले जा सकता है ताकि दोनों एजेंट्स को पता रहे कि बात किस बारे में है, पर वह उसकी जगह कभी नहीं लेता।
क्या प्रोजेक्ट मेमोरी में कुछ अपने आप लिखा जाता है?
नहीं। किसी थ्रेड से कुछ भी अपने आप साझा प्रोजेक्ट मेमोरी में नहीं चढ़ता। टिकाऊ जानकारी जानबूझकर लिखी जाती है, उस एजेंट के हाथों जिसने उसे टिकाऊ माना, और यही मेमोरी को पढ़ने लायक बनाए रखता है।
क्या कोई एजेंट आगे बढ़ने से पहले जवाब का इंतज़ार कर सकता है?
ब्लॉकिंग इंतज़ार वाला कोई टूल नहीं है, और यह एक सोचा-समझा चुनाव है। जवाब आने तक टूल कॉल को जमा देना एक टाइमआउट पर निर्भर करता है जिसे ऐप नियंत्रित नहीं करता और जिसे हर प्रोवाइडर अलग तय करता है। समर्थित तरीक़ा यह है कि भेजिए, अपनी बारी पूरी कीजिए, और जवाब आने पर सूचना से जाग जाइए।
संदेश रहते कहाँ हैं?
प्रोजेक्ट फ़ोल्डर में, उस AgentsRoom वर्किंग डायरेक्टरी में जो git से बाहर रखी जाती है। लिफ़ाफ़े एक बार लिखे जाते हैं और दोबारा कभी नहीं लिखे जाते, और उसके बाद जो कुछ होता है वह अलग इवेंट के रूप में जोड़ा जाता है, इसलिए किसी संदेश की स्थिति हमेशा तथ्यों से बनती है, किसी ऐसी वैल्यू से नहीं जिसे किसी ने ऊपर से मिटाकर लिख दिया हो।
क्या मॉडल या प्रोवाइडर बदलने पर पहचान बची रहती है?
हाँ। सदस्य सेव किया गया एजेंट है, सेशन नहीं। उसका मॉडल बदलिए, उसे एक प्रोवाइडर से दूसरे पर ले जाइए, CLI बंद करके दोबारा खोलिए : पता वही रहता है और इनबॉक्स जस का तस।
क्या मुझे कुछ सेटअप करना पड़ेगा?
नहीं। प्रोजेक्ट के सेव किए हुए एजेंट पहले से ही सदस्य सूची हैं, और AgentsRoom MCP सर्वर पहले से हर एजेंट के साथ रजिस्टर्ड है। ये टूल एजेंट्स की टूल लिस्ट में वैसे ही दिखते हैं जैसे बैकलॉग और टर्मिनल कमांड के टूल दिखते हैं।
मैं अपने सभी AI एजेंट को एक साथ एक ही संदेश कैसे भेजूँ ?
प्रोजेक्ट खोलें, एजेंट टूलबार में मेगाफ़ोन पर क्लिक करें, संदेश लिखें और भेज दें। खुले कंसोल वाला हर एजेंट उसे पाता है। भेजने से पहले आप किसी भी प्राप्तकर्ता को अनचेक कर सकते हैं, और बाद में सूखी पुष्टि के बजाय हर एजेंट का अलग ब्यौरा मिलता है। आपके एजेंट Claude Code पर चलें, Codex पर या किसी और समर्थित CLI पर, काम एक जैसा रहता है।
क्या प्रसारण उन एजेंट को शुरू कर देता है जो चल नहीं रहे ?
नहीं। प्राप्तकर्ता केवल वही एजेंट हैं जिनका कंसोल खुला है: जिन दस CLI को आप देख भी नहीं रहे थे उन्हें शुरू करना एक घोषणा के लिए दस कोटा खर्च कर देता। जिस एजेंट की CLI अभी चालू हो रही है वह भी नहीं छूटता, उसकी प्रति कतार में रुकती है और जैसे ही वह एजेंट ले सकता है, चली जाती है।
क्या एजेंट के बीच संदेश बंद किए जा सकते हैं ?
हाँ, ऐप सेटिंग्स में एक ही स्विच से। बंद होने पर कोई भी एजेंट दूसरे को नहीं लिख सकता, और जो प्रतीक्षा में है वह किसी कंसोल में नहीं लिखा जाता। कुछ भी मिटाया नहीं जाता: दोबारा चालू करने पर वहीं से आगे बढ़ता है जहाँ रुका था, और आप स्वयं संगठन पैनल से अपने एजेंट को लिख सकते हैं। हर सदस्य की पंक्ति में एक और बारीक नियंत्रण भी है, जो सिर्फ़ उस एजेंट को दोनों दिशाओं में रोक देता है।
क्या कोई एजेंट किसी दूसरे प्रोजेक्ट के एजेंट को लिख सकता है?
हाँ, बशर्ते दोनों प्रोजेक्ट आपके अकाउंट के हों और दूसरा प्रोजेक्ट डेस्कटॉप ऐप में खुला हो। सात में से दो टूल एक वैकल्पिक project आर्ग्युमेंट लेते हैं: agents_list_live उस दूसरे प्रोजेक्ट के एजेंट्स की सूची देता है, और agents_send उनमें से किसी एक को लिखता है। आम मामला यह है कि एक एजेंट किसी साझा लाइब्रेरी में बग पाता है और उसे मेंटेन करने वाले एजेंट को बता देता है, बजाय इसके कि वहाँ कंसोल खोले या डुप्लिकेट टिकट बनाए। संदेश पाने वाले के प्रोजेक्ट में संग्रहीत होता है, पाने वाला देखता है कि किसने और किस प्रोजेक्ट से लिखा, और जवाब भेजने वाले के अपने इनबॉक्स में लौटता है। वही दर सीमाएँ और वही रोक लागू होती हैं, और सभी को प्रसारण अलग-अलग प्रोजेक्ट के बीच अस्वीकार किया जाता है।
क्या कोई एजेंट किसी प्रोजेक्ट के एक एजेंट के बजाय पूरे प्रोजेक्ट को लिख सकता है?
हाँ। हर प्रोजेक्ट का अपना इनबॉक्स होता है: प्राप्तकर्ता "inbox" के साथ agents_send खुद प्रोजेक्ट को लिखता है, और project आर्ग्युमेंट के साथ आपके अकाउंट के किसी दूसरे प्रोजेक्ट तक पहुँचता है। यह उस स्थिति के लिए सही पता है जब भेजने वाला नहीं जानता कि वहाँ कौन-सा एजेंट उस विषय का ज़िम्मेदार है। उस प्रोजेक्ट का कोई भी एजेंट अनुरोध पढ़ सकता है, उसका ज़िम्मा ले सकता है (ऐसा सिर्फ़ एक ही एजेंट कर सकता है, इसलिए काम कभी दो बार नहीं होता), कारण बताकर उसे मना कर सकता है या उसका जवाब दे सकता है, और जवाब भेजने वाले के अपने इनबॉक्स में लौटता है। अगर आपने किसी एजेंट को कोऑर्डिनेटर चिह्नित किया है, तो अनुरोध की सूचना प्रोजेक्ट के कोऑर्डिनेटर को दी जाती है। वरना यह एजेंट सूची के ऊपर एक बॉक्स में आपकी प्रतीक्षा करता है, जहाँ एक क्लिक से आप इसे किसी एजेंट को सौंप सकते हैं, इस पर नया एजेंट शुरू कर सकते हैं, या इसे मना कर सकते हैं।
इसके साथ अच्छा चलता है
Agent Teams
मल्टी-एजेंट काम का दूसरा आधा हिस्सा : एक विज़ुअल कैनवस जहाँ आप Dev, QA, PM और सिक्योरिटी को गेट और फ़ीडबैक लूप वाली दोबारा चलाई जा सकने वाली पाइपलाइन में जोड़ते हैं।
Agent Delegation
सस्ते मॉडल पर चलने वाले एक बार के QA एजेंट को दिया गया काम। मैसेजिंग स्थायी सदस्यों के बीच होती है, जबकि डेलिगेशन एक चाइल्ड एजेंट बनाता है जो वर्डिक्ट देकर गायब हो जाता है।
AgentsRoom MCP
वह सर्वर जो ये सात टूल लाता है, बैकलॉग, डेव कमांड, प्रॉम्प्ट लाइब्रेरी, आपके SSH कनेक्शन और आपके डेटाबेस के साथ।
Backlog Task Board
जहाँ औपचारिक काम रहता है। संदेश किसी टिकट की तरफ़ इशारा कर सकता है, और सदस्य सूची दिखाती है कि हर सदस्य अभी किस टिकट पर है।
Project Memory
वह साझा नॉलेज बेस जिसे एजेंट जानबूझकर लिखते हैं। बातचीत बातचीत ही रहती है, और जो फ़ैसले रखने लायक हैं वे लिख दिए जाते हैं।
Customize Agents
सेव किए हुए एजेंट ही सूची के सदस्य हैं। अपने प्रोजेक्ट के लिए ज़रूरी रोल बनाइए, और वही वे पते बन जाते हैं जिन पर आपके एजेंट लिखते हैं।
और जानें
2026 में एक साथ कई कोडिंग एजेंट चलाने के लिए सबसे अच्छे टूल
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: 2026 में एक साथ कई कोडिंग एजेंट चलाने वाले सबसे अच्छे टूल की ईमानदार तुलना।
कैसे एक डेवलपमेंट टीम में AI कोडिंग एजेंट्स को स्केल करें
एक डेवलपर के पास एक कोडिंग एजेंट होने से उत्पादकता की कहानी बनती है। पांच डेवलपर्स के पास बीस एजेंट्स होने से समन्वय की समस्या होती है। यहाँ बताया गया है कि जब एक टीम बढ़ती है तो सबसे पहले क्या टूटता है, और वह सेटअप जो टिकता है: प्रतिबद्ध संदर्भ फ़ाइलें, स्पष्ट फ़ाइल स्वामित्व, विस्फोटक क्षेत्र द्वारा समीक्षा, और लागत जिसे आप वास्तव में देख सकते हैं।
अपने AI एजेंट्स से कैसे बात करें: Claude, Codex, Antigravity, Grok Build
अब बाधा कोड लिखना नहीं, बल्कि बात करना है। जानें कैसे Claude, Codex, Antigravity और Grok Build से सही तरीके से communicate करें ताकि काम तेज हो, सटीक हो, और tokens कम खर्च हों।
अपने एजेंट्स को एक इनबॉक्स दीजिए
AgentsRoom डाउनलोड कीजिए, कोई प्रोजेक्ट खोलिए, और जो एजेंट आपने पहले ही सेव कर रखे हैं उन्हें हर उस CLI पर एक-दूसरे को लिखना शुरू करने दीजिए जिसे आप चलाते हैं।
कंपेनियन ऐप: चलते-फिरते अपने एजेंट्स मॉनिटर करें
Claude, Codex, Antigravity CLI या किसी अन्य AI प्रदाता का उपयोग करें।
बग और अनुरोध सीधे अपने सार्वजनिक बैकलॉग में भेजें।