Claude Code में subagents का fan out, फिर जो लौटे उसकी जाँच

लोग Google में "claude fan out subagents" टाइप करते हैं, और काफ़ी लोग आख़िर में "command" भी जोड़ देते हैं, मानो कोई स्विच हो जिसे बस दबाना है। एक पैटर्न है, और एक कमांड भी है। हमने 16 अक्टूबर 2026 को दोनों को Claude Code 2.1.301 पर और Anthropic के दस्तावेज़ीकरण से मिलाकर जाँचा।

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

छोटा जवाब

Fan out का मतलब है कि एक सत्र किसी काम को ऐसे हिस्सों में बाँटता है जो एक-दूसरे पर निर्भर नहीं हैं, हर हिस्सा एक subagent को सौंपता है, उन्हें एक साथ चलने देता है, और जो लौटता है उसे मर्ज करता है। Claude Code में आप यह तीन तरीक़ों से कर सकते हैं।

इस पेज का बाक़ी हिस्सा हर तरीक़े को बारी-बारी से देखता है, फिर उन जाँचों को जो हम अपने fan out पर चलाते हैं।

एक subagent क्या देख सकता है और क्या नहीं

दस्तावेज़ीकरण के तीन तथ्य तय करते हैं कि आप काम को कैसे बाँटें।

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

नतीजे मुख्य बातचीत में लौटते हैं। subagent के काम का लंबा-चौड़ा हिस्सा उसके अपने संदर्भ में रहता है और सिर्फ़ उसका नतीजा लौटता है। लेकिन लंबी रिपोर्ट लौटाने वाले बहुत से subagents फिर भी आपके मुख्य संदर्भ को भर सकते हैं, और हर एक चलते समय अपने ख़ुद के टोकन ख़र्च करता है।

सीमाएँ हैं। डिफ़ॉल्ट रूप से, एक सत्र में 20 subagents एक साथ चल सकते हैं। 21वाँ Concurrent subagent limit reached के साथ विफल होता है, और यह एरर Claude से दोबारा कोशिश न करने को कहती है। आप इस सीमा को CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS से बढ़ा या घटा सकते हैं। subagents अपने ख़ुद के subagents शुरू कर सकते हैं, मुख्य बातचीत से तीन स्तर नीचे तक, और एक सत्र में कुल संख्या की कोई सीमा नहीं है।

तरीक़ा 1: सीधे शब्दों में माँगें

सबसे आसान fan out एक वाक्य है। Anthropic के दस्तावेज़ीकरण का उदाहरण:

Research the authentication, database, and API modules in parallel using separate subagents

हर subagent अपने हिस्से की पड़ताल करता है, फिर Claude एक सार लिखता है। दस्तावेज़ीकरण वह शर्त जोड़ता है जो मायने रखती है: यह तब सबसे अच्छा काम करता है जब रिसर्च के रास्ते एक-दूसरे पर निर्भर न हों। अगर डेटाबेस वाले सवाल को auth वाले सवाल का जवाब चाहिए, तो आपके पास तीन हिस्से नहीं, बल्कि एक ही क्रम है।

सीधे शब्दों में माँगने पर फ़ैसला Claude पर छूट जाता है। अगर आपने .claude/agents/ में कोई कस्टम subagent परिभाषित किया है, तो उसका @-मेंशन पक्का करता है कि वह उस काम के लिए चलेगा। Claude Code subagents पर हमारा पेज बताता है कि ये फ़ाइलें कैसे काम करती हैं।

तरीक़ा 2: /batch, fan out कमांड के सबसे क़रीब

/batch Claude Code के साथ आने वाली एक स्किल है। आप उसे एक निर्देश देते हैं:

/batch migrate src/ from JavaScript to TypeScript

वह कोडबेस की पड़ताल करती है, काम को 5 से 30 स्वतंत्र इकाइयों में बाँटती है और आपको एक योजना दिखाती है। आपकी मंज़ूरी के बाद, वह हर इकाई के लिए बैकग्राउंड में एक subagent शुरू करती है, हर एक एक अलग-थलग git worktree में। हर subagent अपनी इकाई लागू करता है, टेस्ट चलाता है और अपना बदलाव प्रकाशित करता है। इसके लिए एक git रिपॉज़िटरी चाहिए, या एक WorktreeCreate hook जो किसी दूसरे वर्ज़न कंट्रोल सिस्टम के लिए worktrees बनाए।

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

तरीक़ा 3: claude -p पर एक लूप

जब काम फ़ाइलों की एक सूची हो और आप हर कॉल पर नियंत्रण चाहें, तो Anthropic की बेस्ट प्रैक्टिसेज़ एक लूप बताती हैं। पहले Claude से सूची लिखवाएँ (list all 2,000 Python files that need migrating and save the list to files.txt)। फिर:

for file in $(cat files.txt); do
  claude -p "Migrate $file from Python 2 to Python 3. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --permission-mode dontAsk
done

इस उदाहरण की तीन बातें अपनाने लायक़ हैं।

• जवाब मशीन से पढ़ा जा सकता है। "Return OK or FAIL" का मतलब है कि आपकी स्क्रिप्ट गद्य पढ़े बिना विफलताएँ गिन सकती है।
• अनुमतियाँ पहले से तय होती हैं। --allowedTools ठीक उतना ही मंज़ूर करता है जितना माइग्रेशन को चाहिए, और --permission-mode dontAsk बाक़ी सब कुछ नकार देता है, किसी ऐसे व्यक्ति का इंतज़ार करने के बजाय जो वहाँ है ही नहीं।
• आप दो या तीन फ़ाइलों से शुरू करते हैं। दस्तावेज़ीकरण यह साफ़ कहता है: पहली फ़ाइलों पर जो ग़लत होता है उसके आधार पर प्रॉम्प्ट सुधारें, फिर पूरी सूची चलाएँ।

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

CI के लिए, दस्तावेज़ीकरण --bare जोड़ने की सलाह देता है, जो hooks, स्किल, MCP सर्वर और CLAUDE.md को छोड़ देता है ताकि हर मशीन पर एक जैसा रन हो। bare मोड आपके सब्सक्रिप्शन लॉगिन का इस्तेमाल नहीं करता: इसे ANTHROPIC_API_KEY चाहिए।

हम हर रात fan out कैसे करते हैं

यह वह fan out है जो हम सच में चलाते हैं। हमारी रात की SEO टीम हर नई पोस्ट अंग्रेज़ी और फ़्रेंच में हाथ से लिखती है। फिर एक दूसरा एजेंट Claude Code subagents के साथ उसका सत्रह और भाषाओं में अनुवाद करता है, और पारंपरिक चीनी को अनुवाद करने के बजाय एक स्क्रिप्ट से सरलीकृत चीनी से बनाता है। 13 सितंबर 2026 से ग्यारह पोस्ट इस प्रक्रिया से गुज़री हैं, और हर एक बीस फ़ाइलों के रूप में आती है।

हिस्से

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

हर ब्रीफ़ में वही पाँच चीज़ें होती हैं, क्योंकि subagent को इसके अलावा कुछ नहीं दिखता:

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

जाँच लॉन्च से पहले लिखी जाती है

जाँच एक स्क्रिप्ट है, किसी subagent की राय नहीं। हर भाषा के लिए वह फ़ाइल की तुलना अंग्रेज़ी स्रोत से करती है:

• वही slug और वही तारीख़, शीर्षक H1 के बराबर;
• सेक्शन, सब-सेक्शन, इमेज, लिंक और टेबल पंक्तियों की वही संख्या, और बॉडी में FAQ के उतने ही जवाब जितने मेटाडेटा में सवाल;
• लिंक बाइट-दर-बाइट एक जैसे, कोड सेगमेंट बाइट-दर-बाइट एक जैसे;
• ब्रांड नाम गिने जाते हैं, अंग्रेज़ी से कभी कम नहीं;
• हर भाषा के लिए कैलिब्रेट की गई सीमाओं के भीतर लंबाई, क्योंकि चीनी वही बात अंग्रेज़ी को लगने वाले अक्षरों के लगभग 36% में कह देती है और जापानी लगभग आधे में;
• जहाँ भाषा में हों वहाँ विशेषक चिह्न मौजूद (पोलिश, तुर्की, वियतनामी)।

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

केंद्रीय जाँच ने क्या पकड़ा जो subagents की अपनी रिपोर्टों ने नहीं बताया

टेबल के भीतर अनुवादित कोड। 13 सितंबर को, लगभग आधे subagents ने एक टेबल में किसी कमांड के बाद, उन्हीं backticks के भीतर आने वाले शब्दों का अनुवाद कर दिया। हर एक ने अपने ब्रीफ़ का पालन वैसे किया था जैसे उसने उसे समझा। सुधार ब्रीफ़ में गया, subagents में नहीं: कोड सेगमेंट में सिर्फ़ कमांड होती है, और उसके बाद के शब्द backticks के बाहर रहते हैं।

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

हिस्सों के बीच एकरूपता। 15 अक्टूबर को, इसी तरह अनुवादित एक नए फ़ीचर पेज पर, मर्ज जाँच ने पुष्टि की कि 90 फ़ाइलों में सिर्फ़ अपेक्षित वाक्य बदले थे। लेकिन जापानी, कोरियाई और चीनी subagents में से हर एक ने "You may also like" के लिए उस शीर्षक से अलग शीर्षक चुना था जो उसकी भाषा पहले से एक पड़ोसी पेज पर इस्तेमाल करती थी। हर चुनाव एक सही अनुवाद था। कोई भी साइट के साथ एकरूप नहीं था। कोई subagent अपने हिस्से के भीतर से यह नहीं देख सकता था: सिर्फ़ मर्ज किए गए नतीजे पर एक पास ही इसे देख पाता है।

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

हिस्से के बाहर की रिपोर्टें। 15 अक्टूबर को, तुर्की पर काम कर रहे subagent ने बताया कि साइट 97 मौजूदा वाक्यों में "agent" के लिए "ajans", यानी एजेंसी, लिख रही थी। उसने उन्हें छुआ नहीं, क्योंकि उसका ब्रीफ़ ऐसा करने से मना करता था। हमने एक टिकट खोला और अगले दिन सुधार लाइव हो गया। subagents से यह पूछना कि उन्होंने क्या देखा, सिर्फ़ यह नहीं कि उन्होंने क्या किया, सस्ता है और फ़ायदा देता है।

मर्ज एक ही जगह होता है

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

कब fan out न करें

• हिस्से एक-दूसरे पर निर्भर हैं। अगर हिस्से B को हिस्से A का आउटपुट चाहिए, तो उन्हें क्रम से चलाएँ।
• काम छोटा है। हर subagent ख़ाली शुरुआत करता है और जो चाहिए उसे दोबारा पढ़ता है। दस मिनट के काम पर, नई शुरुआतें जितना बचाती हैं उससे ज़्यादा ख़र्च करवाती हैं।
• आप जाँच नहीं लिख सकते। अगर ख़ुद सब कुछ पढ़े बिना अच्छे हिस्से और बुरे हिस्से में फ़र्क़ करने का कोई तरीक़ा नहीं है, तो आपका समय मर्ज में ही जाएगा।
• कोटा तंग है। हर subagent अपने ख़ुद के टोकन ख़र्च करता है। fan out से आपको समय और साफ़ मुख्य संदर्भ मिलता है, छोटा बिल नहीं।

AgentsRoom कहाँ काम आता है

subagents एक ही Claude Code सत्र के भीतर रहते हैं। आपको उनके नतीजे दिखते हैं, उनका काम नहीं, और आप बीच में उनमें से किसी को दिशा नहीं दे सकते। जब आप चाहें कि हर हिस्सा एक ऐसा एजेंट हो जिसे आप अलग से देख सकें, जवाब दे सकें और जिसके काम की समीक्षा कर सकें, तो इसके बजाय अलग सत्र चलाएँ: हर टिकट अपने git worktree में, और Agent Teams जब हिस्से एक-दूसरे को काम सौंपते हैं। टीम का एक स्टेप एक जाँच कमांड ले जा सकता है, और उसका exit code, न कि एजेंट का अपना दावा, तय करता है कि रन आगे बढ़ेगा या नहीं। यह ऊपर वाला ही नियम है, जिसे रनर लागू करता है। यह Claude Code, Codex और उन दूसरे एजेंट CLI के साथ काम करता है जिन्हें AgentsRoom सपोर्ट करता है।

अगर आप अब भी subagents और Agent Teams के बीच तय कर रहे हैं, तो यह तुलना बताती है कि हर एक किसलिए है।