आप दो एजेंटों से एक रिपोर्ट पर काम करवाते हैं और आपको दो पूरी रिपोर्टें वापस मिलती हैं। अब कमी पाठ की नहीं, बल्कि परस्पर विरोधी संस्करणों के बीच निर्णय की है। समानांतरता तो थी; समझदारी भरा श्रम-विभाजन अभी नहीं। लाभ वहाँ शुरू होता है जहाँ उप-कार्य ऐसे अलग-अलग परिणाम देते हैं जिन्हें मिलाया जा सके।
Claude Code सबएजेंट अपने स्वयं के संदर्भ, अपने स्वयं के कार्य और कॉन्फ़िगर किए जा सकने वाले टूल के साथ काम करते हैं। उनका उपयोग उन्हीं सीमाओं में गिना जाता है। एक अतिरिक्त संदर्भ ज़िम्मेदारी को अधिक स्पष्ट बना सकता है, लेकिन यह कोई दूसरा, स्वतंत्र सत्य नहीं देता। दोनों एजेंट एक ही स्रोत को गलत समझ सकते हैं।
कार्य को इस आधार पर बाँटना कि क्या वापस आता है
हमारा अपना उदाहरण एक मरम्मत कार्यक्रम पर एक छोटी रिपोर्ट है। स्रोत हैं एक समय-सारणी नोट, एक सामग्री सूची और पुष्ट निर्णय। एजेंट A को एक स्पष्ट मसौदा लिखना है। एजेंट B तीन दिए गए कथनों की जाँच करता है: कमरा स्वीकृत, प्रतिभागियों की संख्या पुष्ट और सामग्री लागत स्वीकृत।
एजेंट B से स्पष्ट रूप से दूसरी रिपोर्ट नहीं माँगी जाती। हर कथन के लिए, उसकी वापसी में स्थिति, स्रोत का स्थान और औचित्य होता है। यह बँटवारे को एक उपयोगी इंटरफ़ेस में ढालने के लिए बाध्य करता है। मुख्य कार्य दो पाठों को अंदाज़े से मिलाने के बजाय किसी विशिष्ट शर्त को सुधार सकता है।
{
"aussage": "Material costs approved",
"status": "open",
"quelle": "entscheidungen.txt, Material section",
"begruendung": "Approval is still a precondition."
}यह स्वयं डिज़ाइन किया गया फ़ॉर्मेट परिणामों का एक संभावित अनुबंध है, कोई दावा किया गया नेटिव एजेंट API नहीं। शुरुआत के लिए समान फ़ील्ड वाली एक पाठ-सूची भी उतनी ही उपयुक्त होगी। मायने यह रखता है कि “खुला” को चुपचाप “गलत” या “पुष्ट” के रूप में दोबारा न समझ लिया जाए।
साक्ष्य पढ़ने वाले को लेखन भूमिका की ज़रूरत नहीं है
दूसरे एजेंट को नामित स्रोत पढ़ने हैं और स्रोत-स्थान लौटाने हैं। इसके लिए उसे न तो रिपोर्ट दस्तावेज़ के समानांतर संपादन की ज़रूरत है और न ही संदेश भेजने की क्षमता की। उसके टूल कार्य के अनुसार चुनें और परिवेश की अनुमतियों को भी ध्यान में रखें। टूल सूची और वास्तविक एक्सेस नियंत्रण अलग-अलग परतें हैं।
एक सँभालने योग्य प्रोजेक्ट में कृत्रिम फ़ाइलों से शुरुआत करें। इससे किसी गायब स्रोत को पहचानना आसान हो जाता है। यदि एजेंट B ऐसी फ़ाइल माँगता है जो दी नहीं गई थी, तो वापसी में उस कमी का उल्लेख होना चाहिए। एक्सेस न होने का अर्थ यह नहीं है कि संबंधित निर्णय कभी अस्तित्व में ही नहीं था।
कौन-सा काम वास्तव में समानांतर किया जा सकता है?
एजेंट A स्रोतों की एक स्पष्ट रूप से लेबल की गई स्थिति के आधार पर लिख सकता है, जबकि एजेंट B तीनों कथनों की जाँच करता है। जैसे ही वह स्थिति बदलती है, दोनों को उसके एक पहचाने जा सकने वाले संदर्भ की ज़रूरत होती है। बाद में पुष्ट हुई सामग्री स्वीकृति अंतिम संस्करण में एक साथ खुले प्रश्न और तय तथ्य, दोनों के रूप में नहीं आनी चाहिए।
इसलिए एक व्यक्ति या एक मुख्य एजेंट को अंतिम फ़ाइल का स्वामी तय करें। बाकी नोट या अलग परिणाम देते हैं। यदि हर कोई एक ही फ़ाइल बदल सकता है, तो सामग्री का टकराव लेखन का टकराव भी बन जाता है। अधिक समानांतरता इस निर्भरता को हल नहीं करती।
बीच का अपडेट भी विशिष्ट रहना चाहिए: पढ़ी गई फ़ाइलें, पहले से जाँचे गए कथन और अभी भी गायब स्रोत। एक सामान्य “लगभग हो गया” मिलाने में बहुत कम मदद करता है, यदि ठीक निर्णायक स्रोत-स्थान ही गायब हो।
मिलाना अपने आप में एक अलग चरण है
रिपोर्ट के मसौदे और साक्ष्य सूची को साथ लें। हर विसंगति के लिए मूल अंश पर वापस जाएँ। यदि उसमें “बजट स्वीकृति के बाद” लिखा है, तो यह शर्त शब्दों में बनी रहनी चाहिए। दो एजेंटों की आपसी सहमति स्रोत से अधिक भारी नहीं होती।
एक उपयोगी अंतिम जाँच यह भी पूछती है कि क्या रिपोर्ट पूरी एजेंट बातचीत के बिना समझ में आती है। क्या स्रोत पहचाने जा सकते हैं? क्या खुली ज़िम्मेदारियाँ बनी रही हैं? क्या यह स्पष्ट है कि किस व्यक्ति ने अंतिम संस्करण को स्वीकृति दी? ये प्रश्न संयुक्त परिणाम से जुड़े हैं, न कि इससे कि कोई एक वापसी कितनी चमकदार दिखती है।
यहाँ वर्णित बँटवारा किसी सत्र के रूप में चलाया नहीं गया। यह एक पुनरुत्पादन-योग्य कार्य-अनुबंध दिखाता है: अलग-अलग परिणाम, सीमित टूल, स्रोतों की पहचानी जा सकने वाली स्थिति और मिलाने के लिए ठीक एक जगह। केवल यह अनुबंध ही आपको अतिरिक्त एजेंटों का किसी विशिष्ट उद्देश्य के लिए उपयोग करने में मदद करता है।
स्रोत और दस्तावेज़ीकरण की स्थिति: 25 अक्टूबर 2026।
