Agent Teams.
एक असली tech crew, scripted।

Claude subagents एक single parent Claude session से inline delegations हैं। Parent तय करता है कि subagent को कब call करना है, subagent एक isolated context window में run होता है, एक result return करता है, और parent चलता रहता है। AgentsRoom Teams एक level ऊपर है: हर node एक top-level Claude Code session है अपने terminal, अपनी state और अपने scrollback के साथ। आप हर agent को अपने tab में live देखते हैं, किसी भी moment किसी से भी बात कर सकते हैं, team को pause कर सकते हैं, workflow बदल सकते हैं और resume कर सकते हैं। यह Claude subagents का replacement नहीं है, आप दोनों bilkul इस्तेमाल कर सकते हैं। एक team node internally subagents इस्तेमाल कर सकता है।

यह AgentsRoom में समर्थित सभी 14 एजेंट CLI (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor और 10 अन्य) के साथ काम करता है। हर टीम नोड अपना प्रोवाइडर और मॉडल खुद चुनता है। MCP-आधारित टीम कोऑर्डिनेशन टूल्स सभी प्रोवाइडर्स पर एक जैसे काम करते हैं, क्योंकि वे स्टैंडर्ड Model Context Protocol के ज़रिए एक्सपोज़ होते हैं। अगर आपके बजट और लेटेंसी के हिसाब से यही सही बैठता है, तो आप भारी बैकएंड नोड पर Codex और QA नोड पर Haiku के साथ एक टीम चला सकते हैं।

एक structured object जो एक agent से अगले तक travel करता है। Fields: featureSummary (अभी ship हुई चीज़ का छोटा description), changedFiles (git diff name-status), touchedAreas (UI, API, DB, config), risks (कुछ भी जिसकी अगले agent को चिंता करनी चाहिए), testHints (QA के लिए priorities), flags (qaPassed जैसे booleans, conditional edges द्वारा इस्तेमाल)। Agent इस payload के साथ team_complete_step call करता है, runner server-side validate करता है, अगला agent इसे starting context के तौर पर receive करता है।

हाँ। जब एक node को re-enter किया जाता है (cycle 1 से ज़्यादा), AgentsRoom नया agent spawn नहीं करता। यह cycle 1 के original agent को reuse करता है, नया handoff payload सीधे उसके existing terminal में लिखता है, और agent पिछले cycles की पूरी Claude session memory रखता है। यह critical है: एक Dev agent जिसे पहले से पता है कि QA ने पिछली बार क्या flag किया था, bug fix करता है। Memory के बिना एक fresh Dev agent वही गलती दोहराएगा।

Team config में max-cycles guard है, default 3। जब cap पहुँच जाता है, run 'blocked' status के साथ pause होता है और आपका इंतज़ार करता है। आप run finalize कर सकते हैं, manually एक बार और handoff कर सकते हैं, या सब cancel कर सकते हैं। कोई infinite loops नहीं, कोई surprise overnight bills नहीं।

हाँ। Team एक single workspace और एक single branch में run होता है (या worktree अगर आप AgentsRoom Worktrees feature इस्तेमाल करते हैं)। हर agent पिछले वाले का काम git के ज़रिए देखता है। Handoff payload में run baseline के against git diff शामिल है ताकि अगला agent exactly जान सके क्या नया है।

नहीं। Teams AgentsRoom का हिस्सा हैं। आप अपनी provider keys लाते हैं (Claude, Codex, GitHub Copilot CLI, Cursor और 10 अन्य एजेंट CLI) और सिर्फ उन tokens का pay करते हैं जो आप इस्तेमाल करते हैं, single agent की तरह। एक छोटे ticket पर Dev to QA team चलाना typically वही cost करता है जो single Fullstack agent चलाना, क्योंकि QA step पर Haiku/Sonnet सस्ता है।

प्रोजेक्ट टीमें room के साथ रहती हैं, आपके खाते से सिंक और {project}/.agentsroom/teams-cache.json (gitignored) में कैश होती हैं। वैश्विक टीमें भी आपके खाते से सिंक होती हैं: लाइब्रेरी मशीन दर मशीन आपके साथ चलती है, ~/.agentsroom/teams/ ऑफ़लाइन कैश है। शामिल टेम्पलेट स्थानीय रहते हैं: हर मशीन उन्हें अपनी भाषा में लगाती है।

रन की स्थिति {workspace}/.agentsroom/team-runs/{runId}/ में डिस्क पर सहेजी जाती है (state.json, NOTES.md, inbox/, timeline.jsonl), परमाणु लेखन और केवल-जोड़ नोट्स के साथ। बाधित रन ऐप रीस्टार्ट पर फिर शुरू होता है: ऑर्केस्ट्रेटर सक्रिय चरण में दोबारा प्रवेश करता है, टर्मिनल फिर खोलता है, और एजेंट नोट्स व टीम टूल्स से अपना संदर्भ वापस पाता है। जिस रन की टीम मिटा दी गई हो, वह हमेशा लटके रहने के बजाय अपने आप बंद हो जाता है।

हाँ। हर रन स्वतंत्र है और अपने runId से पहचाना जाता है। एक ही प्रोजेक्ट के तीन टिकटों पर तीन अलग टीमें चल सकती हैं। एक रन के भीतर निष्पादन आपके ग्राफ़ का पालन करता है: डिफ़ॉल्ट रूप से क्रमिक, जहाँ आप समानांतर शाखाएँ खींचें वहाँ समानांतर (जैसे QA और Security एक साथ समीक्षा करते हुए), हमेशा एक निर्धारित संगम के साथ।

हाँ। नोड से बिना शर्त दो कनेक्शन खींचिए और दोनों लक्ष्य समानांतर शाखाओं के रूप में चलते हैं, हर एक अपने एजेंट और टर्मिनल में। शाखाएँ एक नोड गहरी होती हैं और एक साझा संगम नोड पर मिलनी चाहिए, जिसे एडिटर चलाने से पहले सत्यापित करता है। सभी शाखाओं के पूर्ण होते ही संगम को एक मिला हुआ payload मिलता है: भूमिका के लेबल वाले सारांश, दोहराव-मुक्त जोखिम और टेस्ट संकेत, और fail-safe नियम से मिले फ़्लैग (बूलियन टकराव false में सुलझता है)।

आप नोड पर एक शेल कमांड लिखते हैं, जैसे npm test, और चाहें तो एक फ़्लैग नाम (डिफ़ॉल्ट checkPassed)। एजेंट के चरण पूर्ण बताते ही AgentsRoom पाँच मिनट की सीमा के साथ कमांड को workspace में चलाता है। एग्ज़िट कोड 0 फ़्लैग में true लिखता है, बाकी कुछ भी false, एजेंट के अपने बारे में दावे को मिटाते हुए। विफलता पर आउटपुट के अंतिम किलोबाइट अगले एजेंट तक जाते हैं: वापसी असली स्टैक ट्रेस के साथ पहुँचती है, और परिणाम रन की टाइमलाइन में दिखता है।

हाँ। हर नोड आपकी Skills Library से स्किल्स जोड़ सकता है, प्रोजेक्ट या वैश्विक। एजेंट को चरण शुरू करने से पहले हर एक को लोड करने का निर्देश मिलता है: समीक्षा चेकलिस्ट, डिप्लॉय रनबुक या टेस्ट प्रक्रिया हर रन में लागू होती है, एजेंट की याददाश्त पर निर्भर रहने के बजाय।

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

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

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

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

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

सिर्फ़ उतना जितना वह पढ़ सकता है। रन के बीच जुड़ने वाले साथी का अपना सेशन होता है और काम की कोई याद नहीं होती, और ठीक इसीलिए उसकी राय की क़ीमत है। वह साझा नोट्स, रन की टाइमलाइन और रन शुरू होने के बाद के git diff से बराबरी पर आता है, और यह सब वह अपने ही टूल्स से पढ़ता है। यही पढ़ाई इस मोड की क़ीमत है, और इसी वजह से रिले मोड अब भी मौजूद है।

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