हर काम के लिए एक harness: Claude Code में dynamic workflows

Claude Code के Dynamic Workflows का परिचय

यह Anthropic की Claude Code टीम (Thariq Shihipar, Sid Bidasaria) द्वारा प्रकाशित लेख है, जिसमें Claude Code में नए जोड़े गए Dynamic Workflows फ़ीचर की व्याख्या की गई है। Dynamic Workflows एक ऐसा तरीका है जिसमें Claude काम के अनुसार मौके पर ही JavaScript फ़ाइल के रूप में अपना execution structure (harness) खुद लिखता है और कई sub-agents को orchestrate करता है। Claude Code का मौजूदा default harness coding tasks के लिए optimized है, लेकिन लंबे समय तक चलने वाले, बड़े पैमाने के parallel, और adversarial verification की ज़रूरत वाले कामों में इसकी सीमाएँ थीं। इन्हें हल करने के लिए Claude को खुद customized harness बनाने देना ही इसका मुख्य विचार है।

परिचय की पृष्ठभूमि और काम करने का तरीका

• single context की सीमाएँ : एक context window में planning और execution एक साथ चलाने पर तीन तरह के failure modes सामने आते हैं। agentic laziness, जिसमें एजेंट आधा काम करके ही उसे पूरा घोषित कर देता है; self-preferential bias, जिसमें वह अपने ही नतीजों का पक्ष लेता है; और goal drift, जिसमें context compression की प्रक्रिया के दौरान मूल लक्ष्य धुंधला पड़ जाता है।
• काम करने की संरचना : JavaScript फ़ाइल चलाकर sub-agents बनाए और orchestrate किए जाते हैं, और JSON, Math, Array जैसी standard functions का इस्तेमाल किया जा सकता है। हर sub-agent का model type (Sonnet, Opus आदि) और worktree isolation रखना है या नहीं, यह भी workflow खुद तय करता है। बीच में रुकने पर session resume करके आगे जारी रखा जा सकता है।
• इस्तेमाल का तरीका : Claude से workflow बनाने को कहें या trigger शब्द "ultracode" का उपयोग करें।

मुख्य patterns

• Classify and Route : classifier agent पहले task type पहचानता है, फिर उसके अनुसार उपयुक्त agent या processing flow की ओर भेजता है। अंतिम चरण में results को classify करने के लिए भी इसका उपयोग किया जा सकता है।
• Fan-out and Synthesize : बड़े काम को छोटे हिस्सों में बाँटकर हर हिस्से के लिए अलग agent चलाया जाता है, फिर synthesize चरण में सभी नतीजों को जोड़कर एक बनाया जाता है। यह उन कई छोटे tasks के लिए उपयुक्त है जिनमें clean context की ज़रूरत होती है।
• Adversarial Verification : हर task agent के साथ एक अलग verification agent जोड़ा जाता है, जो rubric के आधार पर नतीजों को चुनौती देकर verify करता है।
• Generate and Filter : कई ideas generate करने के बाद rubric और verification की मदद से उन्हें छाँटा जाता है, duplicates हटाए जाते हैं, और केवल सबसे अच्छे candidates रखे जाते हैं।
• Tournament : एक ही काम को अलग-अलग approaches से N agents प्रतिस्पर्धात्मक रूप से करते हैं, और judge agent pairwise comparison के जरिए विजेता चुनता है। लेख के अनुसार pairwise comparison, absolute score evaluation की तुलना में अधिक भरोसेमंद है।
• Loop Until Convergence : जब काम की मात्रा पहले से तय न हो, तो नए discoveries या errors खत्म होने तक agents बनाकर प्रक्रिया दोहराई जाती है।

उपयोग के मामले

• बड़े पैमाने की refactoring और migration : callsites, failing tests, और modules के आधार पर काम को बाँटा जाता है; हर worktree में sub-agent बदलाव करता है; फिर दूसरा agent adversarial review करके merge करता है। Zig से Rust में rewrite का एक वास्तविक उदाहरण दिया गया है, और यदि resource-intensive commands से बचने को कहा जाए तो parallelism अधिकतम किया जा सकता है।
• deep research (/deep-research skill) : web search को fan-out करके sources इकट्ठे किए जाते हैं, adversarial verification से दावों की जाँच की जाती है, और फिर citations के साथ report synthesize की जाती है। इसका उपयोग Slack में status reports लिखने, codebase की गहराई से पड़ताल करने जैसे कामों में भी किया जा सकता है।
• fact-checking : पहले एक agent report के भीतर मौजूद सभी factual claims पहचानता है, फिर हर claim के लिए verification sub-agent source जाँचता है, और एक अलग verification agent source quality तक का मूल्यांकन करता है।
• qualitative sorting और ranking : 1000 से अधिक पंक्तियों वाले support tickets को severity के अनुसार क्रमबद्ध करने जैसे, एक बार में संभालना कठिन काम tournament-style pairwise comparison pipeline या bucket-based parallel processing और merge के जरिए हल किए जाते हैं।
• rules verification और CLAUDE.md automation : हर rule के लिए verification agent रखकर omissions पकड़े जाते हैं, और skeptic persona agent rules की वैधता की समीक्षा करता है। इसके उलट, हाल की sessions और code reviews में बार-बार आने वाले सुधारों को cluster करके नए rules अपने आप निकाले भी जा सकते हैं।
• intermittent failure debugging और postmortem analysis : logs, files, और data के हिसाब से स्वतंत्र agents अलग-अलग evidence के आधार पर hypotheses बनाते हैं, और verifier तथा challenger panel उन hypotheses का मूल्यांकन करता है। यह केवल code ही नहीं, बल्कि revenue गिरने के कारणों या data pipeline failures के विश्लेषण में भी लागू हो सकता है।
• triage और backlog processing : support queue और bug reports को classify किया जाता है, मौजूदा items से duplicates हटाए जाते हैं, फिर या तो automatic fixes किए जाते हैं या इंसानों तक escalation किया जाता है। अविश्वसनीय external content पढ़ने वाले agent और privileged actions करने वाले agent को अलग रखने वाला quarantine pattern सुझाया गया है। /loop के साथ मिलाकर इसे निरंतर संचालन के लिए भी इस्तेमाल किया जा सकता है।
• creative exploration और evaluation : design या naming जैसे taste-driven कामों में कई options बनाए जाते हैं, फिर review agents rubric के आधार पर उन्हें score और select करते हैं। skills की quality को score करके सुधारने वाले हल्के evaluation के लिए भी यह उपयोगी हो सकता है।
• Model Routing : classifier agent पहले task complexity की जाँच करता है, फिर Sonnet और Opus में से उपयुक्त model चुनकर route करता है।

फायदे और अंतर

• अंतर : Claude Agent SDK या claude -p से बनाए जाने वाले मौजूदा static workflows को generalized processing के लिए generic तरीके से लिखना पड़ता है, जबकि Dynamic Workflows में Claude हर बार मौके पर customized harness लिखता है।
• फायदे : context अलग-अलग होने से कई agents अपने-अपने लक्ष्यों पर केंद्रित रह सकते हैं, इसलिए laziness, self-preference, और goal drift जैसी समस्याएँ संरचनात्मक रूप से कम हो सकती हैं। संचालन की दृष्टि से भी interrupted session resume, token budget तय करना ("use 10k tokens"), /goal और /loop के साथ संयोजन, और s key से save करके ~/.claude/workflows directory या skills के जरिए share करने जैसी सुविधाएँ उपलब्ध हैं।
• कमियाँ और सावधानियाँ : token usage काफ़ी बढ़ सकता है, इसलिए यह हर task के लिए उपयुक्त नहीं है। लेखक स्पष्ट रूप से कहते हैं कि सामान्य coding tasks के लिए पाँच reviewers का panel ज़रूरी नहीं होता, और उपयोग से पहले खुद से पूछना चाहिए: "क्या सच में अधिक compute की ज़रूरत है?" Best practices अभी भी विकसित हो रही हैं।

Dynamic Workflows को Claude Code को एक single coding assistant से कई agents को orchestrate करने वाले meta-orchestrator में विस्तार देने वाले बदलाव के रूप में देखा जा सकता है। यह static pipelines और autonomous agents के बीच का एक मध्यवर्ती दृष्टिकोण है, और code migration, deep research, triage, तथा postmortem analysis जैसे लंबे और संरचित कामों में विशेष रूप से प्रभावी लग सकता है। हालांकि token cost अधिक है और best practices अभी स्थापित नहीं हुई हैं, इसलिए pattern के हिसाब से इसकी उपयुक्तता को सावधानी से परखते हुए "quick workflow" से छोटे स्तर पर शुरुआत करना बेहतर होगा।