Claude Code के साथ कई projects चलाते-चलाते sub-agents लगातार बढ़ते गए।
जब भी ज़रूरत पड़ी, एक-एक बनाता गया और वे 22 हो गए।
पिछले महीने उन्हें घटाकर 17 कर दिया।
लेकिन बंद करते समय यह नहीं लिखा कि क्यों बंद किया।
3 महीने बाद archive folder खोलकर देखा तो समझ ही नहीं आया कि क्यों बंद किया था।
पाँच में से सिर्फ़ एक में ही कारण लिखा हुआ था।
यह हाल तब था जब बनाने वाला सिर्फ़ मैं ही था।
22 तक क्यों पहुँचे
बढ़ाते समय वजह हमेशा साफ़ होती है। ज़रूरत होती है, इसलिए बनाते हैं।
समस्या उल्टी दिशा में है। बंद करते समय "शायद बाद में काम आ जाए" वाली बात अटकती रहती है।
यह भरोसा नहीं बनता कि इसकी अब कोई उपयोगिता नहीं है, इसलिए उसे छोड़ देते हैं। ऐसे-ऐसे करके 22 हो गए।
अब पीछे मुड़कर देखता हूँ तो बढ़ने की एक ही वजह थी।
यह तय करने के लिए कोई gate ही नहीं था कि "यह agent नहीं, tool होना चाहिए"।
अगर काम दोहराव वाला है, प्रक्रिया तय है, और context के आधार पर निर्णय की ज़रूरत नहीं है, तो वह agent नहीं है।
उसे skill या script के रूप में बनाया जा सकता है। token नहीं लगते, reproducibility 100% रहती है, और session बदलने पर भी वह भूलता नहीं है।
अगर यह gate नहीं हो, तो सब कुछ agent बन जाता है।
जो पाँच बंद किए
पीछे से हिसाब लगाकर देखा तो उन्हें हटाने के चार तरह के कारण निकले। यह फ़र्क अहम था।
उनमें से एक तो शुरू से agent होना ही नहीं चाहिए था।
वह content writing के लिए था, लेकिन उसकी प्रक्रिया पूरी तरह fixed थी।
उसे दो skills से replace किया और बंद कर दिया। इस पर साफ़ लिख दिया कि इसे दोबारा restore नहीं करना है।
वरना कभी न कभी कोई फिर से बना देगा।
तीन दूसरे agents के साथ role overlap कर रहे थे।
security checks, code audit के साथ overlap कर रहे थे; cron monitoring, health check के साथ; और planning, execution के साथ।
सभी एक ही domain में और एक जैसे permissions के साथ थे।
यहाँ से एक मानदंड मिला।
अगर दो agents एक ही domain और एक जैसे permissions में overlap करते हैं,
तो उन्हें अलग बनाए रखने की लागत (management overhead, delegation decision में देरी) उसके फ़ायदे से ज़्यादा हो जाती है।
"दोनों की ज़रूरत तो है" वाली भावना लंबे समय तक रोड़ा बनी रही,
लेकिन सवाल यह नहीं था कि ज़रूरी हैं या नहीं, बल्कि यह कि उन्हें अलग रखने की कोई वैल्यू है भी या नहीं।
एक ऐसा भी था जिसे कोई इस्तेमाल ही नहीं कर रहा था।
उस feature का traffic 70 दिनों तक 0 था।
इसे हटाया नहीं, बल्कि dormant रखा। service फिर शुरू होगी तो उसे वैसे ही restore कर देंगे।
नंबर लिखते समय जो सीखा
22 → 17 को document में लिखते समय एक बात समझ आई।
यह फ़ाइलों की गिनती नहीं थी। यह production में चल रहे agents की संख्या थी।
एक definition directory के बाहर भी थी, इसलिए सिर्फ़ files गिनने पर 21 और 16 निकलते हैं।
इसलिए document की शुरुआत में ही लिख दिया कि यह संख्या वास्तव में किस चीज़ को गिन रही है।
और git ls-tree से verify किया हुआ नतीजा भी साथ रखा।
वरना बाद में कोई files गिनकर बस इतना कहेगा, "यह तो match नहीं कर रहा"।
संख्या लिखते समय उसकी definition और verification method भी साथ लिखनी चाहिए।
बंद करते समय जिन बातों का पालन करने का तय किया
इस बार जो झटका लगा, उससे चार नियम बने।
-
बंद करते समय कारण फ़ाइल में लिखो। नहीं लिखोगे तो 3 महीने बाद फिर पीछे से हिसाब लगाना पड़ेगा। मेरे साथ सच में ऐसा हुआ।
-
delete मत करो, rename करके move करो। content 100% सुरक्षित रहता है और original के रूप में restore हो जाता है।
-
जिन चीज़ों को restore नहीं करना है, उन्हें साफ़ लिखो। नहीं लिखोगे तो कभी न कभी कोई उन्हें फिर ज़िंदा कर देगा।
-
restore procedure में "जहाँ absorb किया गया है, वहाँ duplicate roles हटाओ" यह ज़रूर डालो। इसे छोड़ोगे तो restore के बाद दोनों एक ही काम करेंगे।
साथ में व्यवस्थित की गई दूसरी बातें
इसी बहाने 4 साल के rules को समेटकर public कर दिया। उनमें से कुछ यहाँ लिख रहा हूँ।
छिपकर bypass करना मना
यह ऐसा rule है जो agent को constraints से टकराने पर उन्हें तोड़ने के बजाय report करने को मजबूर करता है।
अगर block वैध है, तो सिर्फ़ वही चरण hold पर रखा जाता है और बाकी काम चलता रहता है।
अगर block ग़लत फ़ैसला लगता हो, तब भी मनमाने ढंग से bypass नहीं किया जाता। आधार इकट्ठा करके ऊपर भेजा जाता है और approval लिया जाता है।
और अगर उस block से rule की अपनी ही खामी सामने आई, तो प्रतिक्रिया वहीं तक पूरी नहीं होती — उस खामी को ठीक करना भी उसका हिस्सा है।
असल में यह rule भी इसी तरह बना था। एक block झेलने के बाद ही इसे बनाया गया।
FAIL को PASS की तरह नहीं लिखते
भले ही मामला instruction के आधार पर बंद किया जा रहा हो, measured state जैसी है वैसी ही लिखी जाती है और re-open की शर्तें छोड़ी जाती हैं।
report Before/After के measured numbers के साथ होती है, और residuals व risks को achievements से पहले लिखा जाता है।
agent पर मूल रूप से success report देने का दबाव रहता है। rules से न रोको तो वे बार-बार वही करते रहेंगे।
autonomy को quantitative threshold से परिभाषित करना
"modification allowed / disallowed" जैसे binary model की जगह, analysis-type agents खुद कितनी हद तक changes कर सकते हैं, इसे numbers में तय किया गया।
-
सिर्फ़ 1 file
-
5 lines से कम
-
higher-grade file नहीं
-
impact score threshold से कम
सभी शर्तें पूरी हों (AND), और एक भी अटके तो escalation किया जाता है।
और आख़िरी clause सबसे अहम है — अगर मामला अस्पष्ट हो, तो delegation request। default conservative होना चाहिए, तभी rule नहीं टूटता।
निर्णय और execution को अलग रखना
verification और investigation को read-only sub-agents में parallel fan-out किया जाता है,
और file/DB execution को orchestrator केंद्र से serial में संभालता है।
क्योंकि अगर shared files को कई agents एक साथ modify करेंगे, तो टूटना तय है।
इसकी कीमत है। बड़े कामों में central serial processing bottleneck बनती है।
धीमा पड़ना जानते हुए भी टकराव से बेहतर समझकर यही चुना गया।
repository
https://github.com/YoungChulMoon/claude-agent-harness
यह बस कुछ Markdown files हैं। install करने जैसा कुछ नहीं है।
templates को .claude/agents/ के नीचे रखिए और ज़रूरी हिस्से भर दीजिए।
इसे एकमात्र सही जवाब कहने के बजाय, यह कहना बेहतर होगा कि यह उस environment में 4 साल तक काम करने का तरीका था।
team का आकार या project का स्वभाव अलग हो तो यह फिट न भी बैठे।
बढ़ाने की कहानियाँ बहुत मिलती हैं, लेकिन घटाने की कहानियाँ कम दिखती हैं।
उम्मीद है कि जिन लोगों के यहाँ भी agents इसी तरह बढ़ते जा रहे हैं, उनके लिए यह उपयोगी संदर्भ बनेगा।
अभी कोई टिप्पणी नहीं है.