Claude के साथ ग्राफ इंजीनियरिंग: 0 से ग्राफ आर्किटेक्ट बनने तक का 14-चरणीय रोडमैप

अधिकतर लोग जो मल्टी-स्टेप एजेंट बनाने की कोशिश करते हैं, वे एक सीधी रेखा (straight line) बना लेते हैं। स्टेप एक, स्टेप दो, स्टेप तीन - हर एक शालीनता से पिछले स्टेप के पूरा होने का इंतज़ार करता है।

9/10 लोगों को ध्यान आता है कि उनमें से आधे स्टेप्स को कभी इंतज़ार करने की ज़रूरत ही नहीं थी।

वे रूट नहीं करते। वे ब्रांच नहीं करते। वे पैरेललाइज़ नहीं करते। वे बस कतार में लगते हैं - एक हेड, एक कॉन्टेक्स्ट, एक बार में एक काम, जब तक कि विंडो भर न जाए और एजेंट भूल न जाए कि वह क्या कर रहा था।

ताज़ा AI अल्फा पाने के लिए मेरा Substack फॉलो करें:

movez.substack.com

यह 14-स्टेप का रोडमैप है जो उस एकल-फ़ाइल लाइन को एक ग्राफ़ में बदल देता है: जो एक पूरे बेड़े (fleet) में फैल जाता है, अपने निष्कर्षों को स्वयं सत्यापित करता है, और एक ऐसे परिणाम पर केंद्रित होता है जिसे कोई अकेला एजेंट कभी धारण नहीं कर सकता।

यहाँ वह बदलाव है जिसे कोई स्पष्ट नहीं करता। एक प्रॉम्प्ट एक वाक्य है। एक लूप एक चक्र है। एक हार्नेस (harness) वह फर्श है जिस पर एजेंट खड़ा होता है।

लेकिन काम का आकार ही - क्या पहले चलता है, क्या एक साथ चल सकता है, किसे बाकी सबका इंतज़ार करना होता है - वह आकार एक ग्राफ़ है। नोड (nodes) सोचने का काम करते हैं। एजेज़ (edges) परिणामों को ले जाते हैं।

Claude Code ने इन ग्राफ़ों को सीधे बनाने के लिए टूलिंग (tooling) जारी की: डायनामिक वर्कफ़्लोज़ (dynamic workflows)।

Claude एक सादा JavaScript ऑर्केस्ट्रेशन स्क्रिप्ट लिखता है, फिर उसे निष्पादित करने के लिए उप-एजेंटों (subagents) का एक समन्वित बेड़ा तैयार करता है - और समन्वय (coordination) में स्वयं बिल्कुल भी मॉडल टोकन खर्च नहीं होते, क्योंकि यह कोड है, कोई बातचीत नहीं।

01. नोड्स काम हैं। एजेज़ वह हैं जो प्रवाहित होता है।

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

एक एज एक निर्भरता (dependency) है: इसका मतलब है कि इस नोड का आउटपुट उस नोड के इनपुट को फीड करता है। इससे ज़्यादा कुछ नहीं।

गलती यह है कि "और फिर" को एक एज मान लिया जाए। "फ़ाइल का सारांश बनाओ और फिर मुझे मौसम बताओ" - इन दोनों के बीच कोई एज नहीं है; मौसम, सारांश को उपभोग (consume) नहीं करता।

ये दो असंबद्ध नोड हैं जिन्हें एक लीनियर स्क्रिप्ट अनावश्यक रूप से जोड़ देती है। एज तभी अस्तित्व में आता है जब डेटा वास्तव में उसके पार जाता है।

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

1इसे बक्सों और तीरों के रूप में बनाएं। एक बक्सा agent() कॉल है।
2एक तीर एक वेरिएबल है जो एक कॉल के रिटर्न से दूसरे कॉल के
3प्रॉम्प्ट में पास होता है। यदि आप तीर नहीं खींच सकते - यदि कोई वेरिएबल पार नहीं होता - तो दोनों
4बक्से स्वतंत्र हैं, और स्वतंत्रता ही वह चीज़ है जिसका आप इस कोर्स के बाकी हिस्से में
5फ़ायदा उठाएंगे।

02. आपकी लीनियर स्क्रिप्ट एक अपभ्रष्ट ग्राफ़ है

जब आप एक एजेंट को "A करो, फिर B, फिर C, फिर D" के रूप में लिखते हैं, तो आपने एक ग्राफ़ बनाया है - एक एकल, अशाखित श्रृंखला (single unbranching chain)। हर नोड में ठीक एक एज अंदर और एक एज बाहर होता है।

यह सही ढंग से चलता है। यह धीमा और नाज़ुक भी चलता है, क्योंकि एक श्रृंखला में कोई अतिरेक (redundancy) नहीं है: यदि C रुक जाता है, तो D कभी नहीं होता, और A का काम ऊपर की ओर फंसा रहता है जहाँ से जाने की कोई जगह नहीं।

ग्राफ़ इंजीनियरिंग का पहला वास्तविक कौशल है श्रृंखला को फिर से खींचना। अपने लीनियर एजेंट को लें और प्रत्येक तीर के लिए स्टेप 1 का प्रश्न पूछें।

अधिकांश श्रृंखलाओं में दो या तीन तीर ऐसे होते हैं जो डेटा नहीं ले जाते - वे बस वह क्रम हैं जिसमें आपने संयोगवश चीज़ें टाइप की थीं।

उन तीरों को काट दें और श्रृंखला कुछ चौड़ी हो जाती है: कुछ स्वतंत्र नोड जो सभी एक साथ चल सकते हैं, एक ही नोड को फीड करते हुए जिसे उन सभी की ज़रूरत होती है।

03. हर नोड को एक अनुबंध दें

एक ऐसा नोड जिसके बारे में आप तर्क नहीं कर सकते, वह एक ऐसा नोड है जिसे आप समानांतर (parallelize) नहीं कर सकते। इसका समाधान एक अनुबंध है: बद्ध इनपुट, बद्ध आउटपुट, ठीक एक कार्य।

इनपुट वह है जो नोड पढ़ता है - स्पष्ट रूप से पास किया गया, कभी भी साझा विंडो से अनुमानित नहीं। आउटपुट एक परिभाषित आकार है, आदर्श रूप से मान्य (validated), ताकि अगला नोड बिना अनुमान लगाए इसका उपभोग कर सके।

एक वर्कफ़्लो में यह अनुबंध एक स्कीमा (schema) के साथ लागू किया जाता है। जब आप Claude को एक JSON स्कीमा के साथ agent() कॉल देते हैं, तो जो सब-एजेंट Claude तैयार करता है, उसे मान्य संरचित डेटा (validated structured data) लौटाने के लिए मजबूर किया जाता है - मान्यकरण (validation) टूल-कॉल लेयर पर होता है, इसलिए बेमेल होने पर Claude आपको फ्री-टेक्स्ट देने के बजाय पुनः प्रयास करता है जिसे आपको पार्स करके भरोसा करना पड़ता।

यह एक ऐसे नोड और एक ऐसे नोड के बीच का अंतर है जिसे Claude एक ग्राफ़ में जोड़ सकता है, और एक ऐसे नोड के बीच जो केवल तब काम करता है जब कोई इंसान इसका आउटपुट पढ़ता है।

1// एक वास्तविक अनुबंध वाला नोड: बद्ध इनपुट, मान्य आउटपुट, एक कार्य।
2const ITEM = {
3  type: 'object', additionalProperties: false,
4  properties: {
5    title:   { type: 'string' },
6    url:     { type: 'string' },
7    impact:  { type: 'string', enum: ['high', 'medium', 'low'] },
8  },
9  required: ['title', 'url', 'impact'],
10};
11
12const result = await agent(source.prompt, {
13  label:  `research:${source.key}`,
14  schema: ITEM,           // मान्य संरचित आउटपुट को बाध्य करता है
15  agentType: 'general-purpose',
16});
17// result अब एक ऐसा आकार है जिस पर अगला नोड भरोसा कर सकता है — फ्री टेक्स्ट नहीं।

04. एज को एक डेटा अनुबंध के रूप में मानें

एक एज सिर्फ "B, A के बाद आता है" नहीं है। यह एक वादा है कि क्या पार जाता है: A यह आकार उत्पन्न करता है, और B इस आकार का उपभोग करने के लिए बनाया गया है। जब आप एज को उसके डेटा से नाम देते हैं - न कि उसके क्रम से - तो दो चीज़ें आसान हो जाती हैं।

आप तुरंत देख सकते हैं कि एज वास्तविक है या नहीं (क्या डेटा वास्तव में चलता है?), और आप बिना ग्राफ़ को तोड़े, किसी भी सिरे पर नोड को बदल सकते हैं, जब तक आकार बना रहता है।

व्यवहार में, एज सादे JavaScript में रहता है। फैन-आउट और संश्लेषण (synthesis) के बीच का रिड्यूस स्टेप (reduce step) - फ़्लैटन, डिडुप्लिकेट, फ़िल्टर - आपके नोड्स द्वारा लौटाए गए आकृतियों पर काम करने वाला सिर्फ कोड है।

किसी एजेंट की ज़रूरत नहीं। ग्राफ़ सोच की शांत जीतों में से एक: लोग मॉडल टोकन पर जो भारी मात्रा में खर्च करते हैं, वह वास्तव में एक एज है, और एजेज़ मुफ़्त हैं।

1प्रलोभन है कि "परिणामों को संयोजित करने" के लिए एक एजेंट तैनात किया जाए। इसका
2विरोध करें। यदि संयोजन का मतलब फ़्लैटन-एंड-डिडुप है, तो वह results.flatMap(...)
3और एक Set है — नियतात्मक (deterministic), तत्काल, शून्य टोकन। एजेंटों को निर्णय के लिए बचाएं,
4प्लंबिंग के लिए नहीं। एक ग्राफ़ जहाँ हर एज एक एजेंट है, वह अपनी ही वायरिंग पर किराया चुका रहा है।

05. parallel() के साथ फैन आउट करें

यही वह चाल है जो सब कुछ चुकाती है। जब आपके पास N स्वतंत्र नोड हों - N स्रोतों की जाँच करनी हो, N फ़ाइलों की समीक्षा करनी हो, N रूटों का ऑडिट करना हो - तो आप उन्हें श्रृंखलाबद्ध नहीं करते।

आप Claude को उन्हें फैलाने और एक साथ चलाने के लिए कहते हैं। एक वर्कफ़्लो में यह parallel() है: Claude थंक्स (thunks) की एक सरणी (array) लेता है और प्रति थंक एक सब-एजेंट तैयार करता है, सभी एक साथ निष्पादित होते हैं, फिर आपको परिणामों की सरणी वापस देता है।

दो विवरण इसे मज़बूत बनाते हैं। पहला, parallel() एक बैरियर (barrier) है - यह लौटने से पहले हर थंक का इंतज़ार करता है, ताकि अगला चरण पूरा सेट देखे। दूसरा, जो थंक थ्रो करता है (फेंकता है), वह पूरे बैच को अस्वीकार (reject) करने के बजाय null पर हल (resolve) हो जाता है, ताकि एक खराब एजेंट पूरे रन को डुबो न सके।

हमेशा .filter(Boolean) के साथ परिणामों को फ़िल्टर करें। समवर्तीता (concurrency) आपके कोर काउंट और अतिरिक्त कतार (excess queues) के आसपास सीमित होती है, इसलिए आप सौ थंक पास कर सकते हैं और वे सभी खत्म हो जाएंगे - बस एक बार में कुछ मुट्ठी भर।

1phase('Research');
2
3// नौ स्रोत, नौ एजेंट, सभी एक साथ।
4const raw = await parallel(
5  SOURCES.map((s) => () =>
6    agent(s.prompt, {
7      label: `research:${s.key}`,
8      phase: 'Research',
9      schema: ITEM_SCHEMA,     // प्रत्येक नोड मान्य JSON लौटाता है
10      agentType: 'general-purpose',
11    }),
12  ),
13);
14
15const collected = raw.filter(Boolean);  // विफल एजेंटों से nulls हटाएं

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

यही वह चीज़ है जो Claude को एक वर्कफ़्लो को दर्जनों या सैकड़ों सब-एजेंटों तक स्केल करने देती है, बिना सत्र को डुबोए। ऑर्केस्ट्रेशन लेयर पर शून्य टोकन खर्च होते हैं क्योंकि यह Claude के सोचने का एक और मोड़ (turn) नहीं है।

06. एक बैरियर पर फैन इन करें

फैन-आउट तभी उपयोगी है जब कोई चीज़ इसे इकट्ठा करे। फैन-इन वह नोड है जहाँ एजेज़ अभिसरित (converge) होते हैं - जहाँ एक एजेंट (या कोड का एक टुकड़ा) एक साथ सभी अपस्ट्रीम परिणामों को देखता है और कुछ ऐसा करता है जिसके लिए पूरे सेट की आवश्यकता होती है: स्रोतों में डिडुप्लिकेट करना, प्रभाव के अनुसार रैंक करना, यदि कुल खाली वापस आया तो जल्दी बाहर निकलना (early-exit)। यह एकमात्र स्थान है जहाँ एक बैरियर अपनी दीवार-घड़ी की लागत (wall-clock cost) कमाता है।

वह नियम जो ग्राफ़ को तेज़ रखता है: बैरियर का उपयोग केवल तभी करें जब किसी चरण को वास्तव में हर पिछले परिणाम की एक साथ आवश्यकता हो। सभी स्रोतों पर डिडुप्लिकेट करना? बैरियर - सही।

1// एज: सादा JS, कोई एजेंट नहीं, शून्य टोकन।
2const flat = collected.flatMap((c) => c.items);
3log(`Collected ${flat.length} items`);
4
5phase('Curate');
6// बैरियर नोड: डिडुप + रैंक के लिए पूरे सेट की आवश्यकता है।
7const curated = await agent(
8  `इन्हें प्रभाव के अनुसार डिडुप्लिकेट करें और रैंक करें:\n${JSON.stringify(flat)}`,
9  { phase: 'Curate', schema: CURATED_SCHEMA },
10);

बस एक सूची को फ़्लैट करना? वह एक एज है, इसे इनलाइन करें। परीक्षण (smell test) कठोर और सरल है: यदि आपने parallel → transform → parallel लिखा, और उस मध्य परिवर्तन (middle transform) में कोई क्रॉस-आइटम निर्भरता नहीं है, तो आपको पाइपलाइन (pipeline) का उपयोग करना चाहिए था और बैरियर को पूरी तरह से छोड़ देना चाहिए था।

07. डायमंड: विभाजन → कार्य → विलय

फैन-आउट और फैन-इन को एक साथ रखें और आपको हर गंभीर एजेंट ग्राफ़ की वर्कहॉर्स टोपोलॉजी (workhorse topology) मिलती है: डायमंड (diamond)।

एक नोड काम को विभाजित करता है, कई नोड समानांतर में काम करते हैं, एक नोड विलय करता है। यह एक बाज़ार स्कैन, एक निर्भरता ऑडिट, एक कोड रिव्यू, एक शोध रिपोर्ट के पीछे का आकार है - स्रोतों और प्रॉम्प्ट को बदलें और वही कंकाल अनुकूलित हो जाता है।

विहित रूप (canonical form) का एक नाम है जो याद रखने लायक है: फैन आउट → रिड्यूस → सिंथेसाइज़। चौड़ाई इकट्ठा करने के लिए फैन आउट करें, इसे संपीड़ित करने के लिए सादे कोड से रिड्यूस करें, उत्तर लिखने के लिए अंतिम एजेंट से सिंथेसाइज़ करें।

एक बार जब आप डायमंड देख लेते हैं, तो आप यह पूछना बंद कर देते हैं कि "मैं अपने एजेंट को और अधिक कदम कैसे उठाऊं" और यह पूछना शुरू कर देते हैं कि "विभाजन कहाँ है, विलय कहाँ है" - जो वह प्रश्न है जो वास्तव में स्केल करता है।

08. एक सशर्त के साथ रनटाइम पर एज को रूट करें

हर ग्राफ़ निश्चित (fixed) नहीं होता। कभी-कभी लेने वाला एज इस बात पर निर्भर करता है कि एक नोड ने क्या पाया। एक राउटर नोड एक परिणाम का निरीक्षण करता है और तय करता है कि कौन सा डाउनस्ट्रीम पथ सक्रिय होगा - टिकट को वर्गीकृत करें, फिर सही हैंडलर पर शाखा करें; डिफ़ (diff) के आकार की जाँच करें, फिर या तो त्वरित समीक्षा करें या पूर्ण ऑडिट शुरू करें।

एक वर्कफ़्लो में यह एक नोड के मान्य आउटपुट पर सिर्फ एक JavaScript if या switch है, क्योंकि नियंत्रण प्रवाह (control flow) कोड में रहता है।

यह वह जगह है जहाँ नियतत्ववाद (determinism) एक सीमा नहीं, बल्कि एक विशेषता बन जाता है। राउटर का निर्णय Claude-संचालित (Claude-powered) हो सकता है (एक सब-एजेंट वर्गीकृत करता है), लेकिन रूटिंग वह कोड है जो Claude ने लिखा - इसलिए यह उसी वर्गीकरण के लिए हर बार उसी तरह चलता है।

आपको नोड पर Claude का निर्णय और एज पर स्क्रिप्ट की विश्वसनीयता मिलती है। कोई आकस्मिक "Claude ने ऑडिट को छोड़ने का फैसला किया" आश्चर्य नहीं - क्योंकि छोड़ने को ग्राफ़ में लिखना होगा, और वह लिखा नहीं गया है।

1// राउटर नोड: एक एजेंट वर्गीकृत करता है, कोड एज चुनता है।
2const { severity } = await agent(
3  `इस डिफ़ के जोखिम को वर्गीकृत करें:\n${diff}`,
4  { schema: { type: 'object',
5      properties: { severity: { enum: ['low', 'high'] } },
6      required: ['severity'] } },
7);
8
9let review;
10if (severity === 'high') {
11  // भारी पथ: पूर्ण समानांतर ऑडिट
12  review = await parallel(FILES.map((f) => () => agent(`Audit ${f}`)));
13} else {
14  // हल्का पथ: एक त्वरित पास
15  review = await agent(`Quick review of ${diff}`);
16}

09. एज पर एक सत्यापनकर्ता रखें

एक ग्राफ़ का वास्तविक लाभ (leverage) अधिक एजेंट नहीं है - यह वह संरचना है जिसे आप उनके चारों ओर लपेटकर विश्वास (confidence) उत्पन्न कर सकते हैं।

एक सत्यापनकर्ता नोड (verifier node) किसी परिणाम को डाउनस्ट्रीम जाने की अनुमति देने से पहले एज पर बैठता है, और इसका एकमात्र काम निष्कर्ष (finding) को खत्म करने का प्रयास करना है। यदि वह बच जाता है, तो वह पास हो जाता है। यदि नहीं, तो वह कभी उत्तर तक नहीं पहुँचता।

तीन पैटर्न हैं जिन्हें अपने हाथों में रखना उपयोगी है।

• प्रतिकूल सत्यापन (Adversarial verify): प्रत्येक निष्कर्ष के लिए, N स्वतंत्र संशयवादी (skeptics) तैयार करें जिन्हें इसका खंडन करने के लिए प्रेरित किया गया हो; इसे तभी रखें जब बहुमत बच जाए।
• विविध-दृष्टिकोण सत्यापन (Perspective-diverse verify): प्रत्येक सत्यापनकर्ता को एक अलग लेंस दें - शुद्धता, सुरक्षा, क्या-यह-दोहराता-है - क्योंकि विविधता उन विफलता मोड (failure modes) को पकड़ती है जो N समान जाँचें कभी नहीं पकड़ेंगी।
• जज पैनल (Judge panel): विभिन्न कोणों से N प्रयास उत्पन्न करें, उन्हें समानांतर जजों से स्कोर करें, विजेता से संश्लेषण करें, साथ ही उपविजेताओं में से सर्वश्रेष्ठ को ग्राफ्ट करें।

यह ठीक वही पैटर्न है जिसने एक वास्तविक टीम को Bun रनटाइम को पोर्ट करने दिया, जिसमें लूप में प्रतिकूल कोड समीक्षा (adversarial code review) शामिल थी।

10. नोड्स को अलग करें ताकि एक विफलता पूरे ग्राफ़ को जहरीला न कर सके

एक श्रृंखला में, एक विफलता झरने की तरह फैलती है (cascades) - C मर जाता है, D कभी नहीं चलता, पूरी चीज़ रुक जाती है। एक ग्राफ़ में, विफलता को उसके नोड तक सीमित रखा जाना चाहिए।

यह पहले से ही आंशिक रूप से सच है: parallel() के अंदर जो थंक थ्रो करता है, वह null पर हल हो जाता है, इसलिए आठ अच्छे एजेंट अभी भी लौटते हैं जबकि एक खराब बाहर गिर जाता है। आपका .filter(Boolean) ही सीमा (containment) है।

प्रत्येक फैन-इन को पूर्ण सेट मानने के बजाय लापता इनपुट को सहन करने के लिए डिज़ाइन करें।

अधिक सूक्ष्म विफलता है नोड्स का एक दूसरे पर कदम रखना। जब एजेंट समानांतर में फ़ाइलें लिखते हैं, तो वे टकरा सकते हैं।

समाधान अलगाव (isolation) है: "वर्कट्री (worktree)" - प्रत्येक एजेंट अपने स्वयं के git worktree में चलता है, एक सैंडबॉक्स में अपना काम करता है, और साफ-सुथरा विलय (merge) करता है।

इसका उपयोग केवल तभी करें जब नोड्स वास्तव में समानांतर में लिख रहे हों। यह उस एक टोपोलॉजी के लिए सीटबेल्ट है जिसे इसकी आवश्यकता है, न कि हर रन पर एक डिफ़ॉल्ट टैक्स।

11. एक चक्र जोड़ें - लेकिन इसे अभिसरित होने दें

कभी-कभी आपको तब तक पता नहीं चलता कि काम कितना बड़ा है जब तक आप उसमें न हों: अज्ञात आकार की खोज, एक बग स्वीप जहाँ एक बग मिलने से तीन और बग सामने आते हैं। इसके लिए एक चक्र (cycle) की आवश्यकता है - एक नियंत्रित एज जो पहले के नोड पर वापस जाता है।

खतरा स्पष्ट है: एक चक्र जो अभिसरित नहीं होता, वह एक अनंत लूप है जो तब तक एजेंटों को तैयार करता है जब तक आपका बजट खत्म न हो जाए।

जो पैटर्न अभिसरित होता है, वह है लूप-अनटिल-ड्राई (loop-until-dry): खोजकर्ताओं (finders) को तब तक तैयार करते रहें जब तक K लगातार दौर (consecutive rounds) कुछ भी नया सामने न लाएँ, फिर रुक जाएँ। एक विवरण जो इसे बना या बिगाड़ सकता है - और वह गलती जो लगभग हर कोई पहली बार करता है - वह यह है कि आप किसके विरुद्ध डिडुप्लिकेट करते हैं।

जो कुछ भी देखा गया है, उसके विरुद्ध डिडुप्लिकेट करें, न कि केवल पुष्टि किए गए परिणामों के विरुद्ध। अन्यथा अस्वीकृत निष्कर्ष हर दौर में फिर से प्रकट होते हैं, लूप कभी सूखता नहीं, और आपने एक ऐसी मशीन बनाई है जो उन्हीं मृत सिरों को हमेशा के लिए फिर से खोजने के लिए भुगतान करती है।

1const seen = new Set(); const confirmed = []; let dry = 0;
2
3while (dry < 2) {                       // 2 खाली दौर के बाद रुकें
4  const found = (await parallel(
5    FINDERS.map((f) => () => agent(f.prompt, { schema: BUGS }))
6  )).filter(Boolean).flatMap((r) => r.bugs);
7
8  const fresh = found.filter((b) => !seen.has(key(b)));
9  if (!fresh.length) { dry++; continue; } // कुछ नया नहीं → सूखेपन की ओर
10  dry = 0;
11  fresh.forEach((b) => seen.add(key(b))); // SEEN के विरुद्ध डिडुप, confirmed के नहीं
12
13  // गिनती करने से पहले प्रत्येक नए निष्कर्ष को विविध-लेंस से सत्यापित करें
14  const judged = await parallel(fresh.map((b) => () =>
15    parallel(['correctness', 'security', 'repro'].map((lens) => () =>
16      agent(`Judge "${b.desc}" via ${lens} — real?`, { schema: VERDICT })))
17    .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))));
18
19  confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));
20}

12. नोड्स के बीच मॉडलों को स्तरित करें

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

उबाऊ नोड्स को एक सस्ते मॉडल पर चलाएँ और अपने महंगे टोकन वहाँ खर्च करें जहाँ निर्णय वास्तव में रहता है।

एक वर्कफ़्लो में, Claude द्वारा तैयार किया गया प्रत्येक सब-एजेंट आपके सत्र मॉडल को इनहेरिट करता है जब तक कि स्क्रिप्ट इसे ओवरराइड न करे - इसलिए डिफ़ॉल्ट रूप से एक बड़ा रन पूरी तरह से आपके सत्र स्तर पर बिल करता है। एकल agent() कॉल पर model विकल्प Claude को बताता है कि उस नोड को कहीं और रूट करे।

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

13. टोपोलॉजी ही आपकी लागत और विलंबता है

ग्राफ़ का आकार केवल सजावटी नहीं है - यह दीवार-घड़ी के समय (wall-clock time) पर सबसे बड़ा लीवर है। वह विकल्प जो सभी को फँसाता है: parallel() बनाम pipeline()। एक parallel() बैरियर सब कुछ को अगले चरण के शुरू होने से पहले सबसे धीमे नोड का इंतज़ार कराता है।

एक pipeline() प्रत्येक आइटम को सभी चरणों के माध्यम से स्वतंत्र रूप से स्ट्रीम करता है, बिना किसी बैरियर के - आइटम A चरण 3 में हो सकता है जबकि आइटम B अभी भी चरण 1 में है। तेज़ आइटम धीमे आइटम के पीछे निष्क्रिय रहने के बजाय जल्दी खत्म हो जाते हैं।

डिफ़ॉल्ट रूप से pipeline() का उपयोग करें। बैरियर तक तभी पहुँचें जब किसी चरण को वास्तव में एक साथ हर पिछले परिणाम की आवश्यकता हो - एक क्रॉस-सेट डिडुप, कुल पर जल्दी-बाहर, एक प्रॉम्प्ट जो "अन्य निष्कर्षों" के विरुद्ध तुलना करता है। "यह क्लीनर कोड है" और "चरण अलग महसूस होते हैं" कारण नहीं हैं; बैरियर विलंबता वास्तविक, मापने योग्य, बर्बाद समय है। अलग होना, सिंक्रनाइज़ होने के समान नहीं है।

14. Claude को ग्राफ़ खींचने दें - स्व-रूटिंग

अंतिम चाल उन कार्यों के लिए ग्राफ़ को हाथ से खींचना बंद करना है जिनकी आप पहले से योजना नहीं बना सकते।

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

इसमें शामिल होने के तीन तरीके हैं। अपने प्रॉम्प्ट में "workflow" शब्द कहें और Claude कार्य के लिए एक लिखता है। एक सहेजा या बंडल किया हुआ चलाएँ - /deep-research एक वास्तविक ग्राफ़ है जो उत्पादन में शिप हो रहा है: स्कोप → समानांतर खोज → फ़ेच → प्रतिकूल सत्यापन → संश्लेषण, इस कोर्स का सटीक कंकाल।

या अल्ट्राकोड (ultracode) चालू करें और Claude सत्र में हर महत्वपूर्ण कार्य के लिए एक वर्कफ़्लो की योजना बनाता है। जब कोई रन अच्छा हो, तो उसकी स्क्रिप्ट को .claude/workflows/ में सेव करने के लिए s दबाएँ - संस्करण-नियंत्रित (version-controlled), नाम से पुन: चलाने योग्य, एक ग्राफ़ जिसे रिपो को क्लोन करने वाला कोई भी व्यक्ति लॉन्च कर सकता है।

1› src/routes/ के तहत हर रूट में लापता प्रमाणीकरण के लिए ऑडिट करने हेतु एक वर्कफ़्लो चलाएँ।
2प्रति रूट फ़ाइल एक एजेंट तैयार करें, फिर रिपोर्ट करने से पहले प्रत्येक निष्कर्ष को सत्यापित करें। ● Claude ने एक ऑर्केस्ट्रेशन स्क्रिप्ट लिखी · बैकग्राउंड में लॉन्च हो रहा है… /workflows — auth-audit · चल रहा है ✓ Scope 1/1 2.1k tok ·
34s ✓ Fan-out 18/18 प्रति रूट फ़ाइल एक एजेंट ◯ Verify 11/18 प्रति निष्कर्ष 3-वोट संशयवादी… ○ Synthesize 0/1 verify पर प्रतीक्षा कर रहा है सत्र प्रतिक्रियाशील रहता है — बेड़े के चलने के दौरान काम करते रहें

इस सप्ताह Claude के साथ बनाने के लिए छह ग्राफ़

• हर रूट पर सुरक्षा स्वीप। Claude प्रति रूट फ़ाइल एक सब-एजेंट तैयार करता है, प्रत्येक लापता प्रमाणीकरण जाँचों की तलाश में, फिर एक सत्यापनकर्ता पास रिपोर्ट तक पहुँचने से पहले हर निष्कर्ष की पुष्टि करता है। वह चौड़ाई जिसे कोई एक कॉन्टेक्स्ट धारण नहीं कर सकता।
• /deep-research के साथ उद्धृत रिपोर्ट। एक ग्राफ़ जो पहले से ही Claude Code में शिप होता है। Claude आपके प्रश्न को अलग-अलग कोणों में विघटित करता है, समानांतर खोज चलाता है, स्रोतों को डिडुप करता है, फिर लिखने से पहले तीन-वोट संशयवादियों के साथ प्रत्येक दावे का प्रतिकूल सत्यापन करता है।
• एक मॉड्यूल को, फ़ाइल दर फ़ाइल पोर्ट करें। Bun ceiling, आपके रिपो पर स्केल किया गया। Claude फ़ाइलों में अनुवाद फैलाता है, प्रत्येक पर एक गेट के रूप में टेस्ट सूट चलाता है, और विफलताओं को वापस लूप करता है - प्रतिकूल समीक्षा उन चीज़ों को पकड़ती है जिन्हें एक एकल पास टूटा हुआ शिप कर देगा।
• एक डिफ़ की प्रतिकूल समीक्षा। Claude डिफ़ आकार पर रूट करता है: एक छोटे बदलाव के लिए एक त्वरित पास, एक बड़े के लिए अलग-अलग लेंस - शुद्धता, सुरक्षा, प्रदर्शन - पर समीक्षकों के साथ पूर्ण समानांतर ऑडिट शुरू होता है, फिर एक जज पैनल संश्लेषण करता है।
• एक शेड्यूल पर इकोसिस्टम स्कैन। इसे एक बार सेव करें, इसे हमेशा के लिए फिर से चलाएँ। Claude कई स्रोतों की समानांतर में जाँच करता है - रिलीज़, ब्लॉग, चर्चाएँ - एक बैरियर पर प्रभाव के अनुसार रैंक करता है, और डाइजेस्ट लिखता है। .claude/workflows/ में संस्करण-नियंत्रित, नाम से लॉन्च करने योग्य।
• अज्ञात आकार की खोज। आप नहीं जानते कि कितने बग हैं। Claude समानांतर में खोजकर्ता चलाता है, प्रत्येक नई खोज को देखी गई हर चीज़ के विरुद्ध डिडुप करता है, उत्तरजीवियों को सत्यापित करता है, और तब तक लूप करता रहता है जब तक दो दौर कुछ नया नहीं लाते - फिर रुक जाता है।

निष्कर्ष:

एक प्रॉम्प्टर एक प्रश्न पूछता है। एक आर्किटेक्ट एक ग्राफ़ खींचता है।

लीनियर एजेंट कभी छत (ceiling) नहीं था - यह सिर्फ पहला आकार था, जिसे हर कोई इसलिए पकड़ता है क्योंकि यह हमारे टाइप करने के तरीके से मेल खाता है। एक लाइन, एक हेड, एक बार में एक काम।

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

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