ज़्यादातर लोग Claude का इस्तेमाल एक बार में एक सवाल का जवाब पाने के लिए कर रहे हैं।
इसे सेव कर लें :)
लोगों का एक छोटा समूह Claude का इस्तेमाल एजेंटों की एक पूरी टीम चलाने के लिए कर रहा है जो रिसर्च करती है, लिखती है, कोड करती है, एक-दूसरे के काम की समीक्षा करती है, और जब वे सो रहे होते हैं तब तैयार आउटपुट भेजती है।
इन दोनों समूहों के बीच का अंतर बुद्धिमत्ता का नहीं है।
यह ऑर्केस्ट्रेशन है।
एक अकेला एजेंट एक सहायक है। एजेंटों की एक टीम एक कार्यबल है। आपके प्रॉम्प्ट का जवाब देने वाला एक Claude इंस्टेंस उपयोगी है। पाँच Claude इंस्टेंस, जिनमें से प्रत्येक की एक परिभाषित भूमिका है, एक-दूसरे को काम सौंपते हैं और एक-दूसरे के आउटपुट की जाँच करते हैं, यह एक ऐसा सिस्टम है जो बीस मिनट में वह कर देता है जिसमें पहले आपको पूरा दिन लगता था।
और अभी लगभग कोई नहीं जानता कि इसे सही तरीके से कैसे बनाया जाए।
यही अवसर है। मल्टी-एजेंट सिस्टम ऐसा लगता है जैसे इसके लिए PhD और एक रिसर्च लैब की ज़रूरत होती है। ऐसा नहीं है। 2026 में उपलब्ध टूल के साथ, आप इस सप्ताह अपनी पहली काम करने वाली एजेंट टीम बना सकते हैं, बिना किसी मशीन लर्निंग बैकग्राउंड के, सिर्फ Claude और एक साफ दिमाग का उपयोग करके।
यहाँ बिल्कुल वैसा ही बताया गया है जैसे इसे शुरू से करना है।
पहले, उस मानसिक मॉडल को खत्म करें जो आपको रोक रहा है
ज़्यादातर लोग कभी एजेंट टीम नहीं बनाते इसका कारण यह है कि वे Claude को एक चैट विंडो समझते हैं।
आप टाइप करते हैं, वह जवाब देता है, आप फिर से टाइप करते हैं। यह उपभोक्ता अनुभव है, और यह आपको तुरंत सीमित कर देता है।
यहाँ बेहतर मॉडल है। Claude को एक ऐसे दिमाग के रूप में सोचें जिसे आप जितनी बार चाहें उतनी बार स्पिन अप कर सकते हैं। प्रत्येक कॉपी को एक अलग काम, एक अलग व्यक्तित्व, निर्देशों का एक अलग सेट और टूल का एक अलग सेट दिया जा सकता है। एक कॉपी को कभी यह जानने की ज़रूरत नहीं है कि दूसरे क्या कर रहे हैं। आप, ऑर्केस्ट्रेटर, तय करते हैं कि कौन किससे और किस क्रम में बात करेगा।
बस इतना ही एक मल्टी-एजेंट सिस्टम है। यह कोई जादू नहीं है। यह विशेषज्ञ Claude इंस्टेंस का एक समूह है, साथ ही एक योजना है कि उनके बीच काम कैसे प्रवाहित होगा।
एक बार जब यह समझ में आ जाता है, तो बाकी सब कुछ सिर्फ प्लंबिंग है।
हर एजेंट टीम को तीन भूमिकाओं की ज़रूरत होती है
कुछ भी बनाने से पहले, तीन मुख्य भूमिकाओं को समझें। लगभग हर उपयोगी एजेंट टीम इनमें से कुछ संयोजन है।
ऑर्केस्ट्रेटर। यह प्रबंधक है। यह आपके लक्ष्य को लेता है, उसे कार्यों में विभाजित करता है, तय करता है कि कौन सा विशेषज्ञ प्रत्येक कार्य को संभालेगा, और अंतिम परिणाम को इकट्ठा करता है। यह खुद गहरा काम नहीं करता है। यह प्रतिनिधि बनाता है और एकीकृत करता है। एक अच्छी तरह से बनाए गए सिस्टम में, यह एकमात्र एजेंट है जिससे आप सीधे बात करते हैं।
विशेषज्ञ। ये कार्यकर्ता हैं। प्रत्येक संकीर्ण और उत्कृष्ट है। एक रिसर्च विशेषज्ञ जो केवल तथ्यों को इकट्ठा और सत्यापित करता है। एक लेखक जो केवल रिसर्च को गद्य में बदलता है। एक कोडर जो केवल कोड लिखता और परीक्षण करता है। एक डिज़ाइनर जो केवल लेआउट और विज़ुअल स्पेक्स तैयार करता है। भूमिका जितनी संकीर्ण होगी, आउटपुट उतना ही बेहतर होगा, क्योंकि एक केंद्रित निर्देश हर बार एक अस्पष्ट निर्देश को हरा देता है।
आलोचक। यह वह भूमिका है जिसे लगभग हर कोई छोड़ देता है, और यह वही है जो शौकिया सिस्टम को पेशेवर सिस्टम से अलग करता है। आलोचक का एकमात्र काम एक मानक के खिलाफ विशेषज्ञों के आउटपुट की समीक्षा करना और यदि वह कम पड़ता है तो उसे वापस भेजना है। आलोचक के बिना एक टीम तेजी से कचरा पैदा करती है। आलोचक के साथ एक टीम ऐसा काम पैदा करती है जिसे आप वास्तव में शिप कर सकते हैं।
इन तीन भूमिकाओं को सही करें और आपके पास हर एजेंट टीम का ढांचा है जो बनाने लायक है।
आपका निर्माण पथ: पाँच चरण
आप पहले दिन पाँच-एजेंट सिस्टम नहीं बनाते हैं। आप एक एजेंट बनाते हैं, फिर दो, फिर एक टीम। यहाँ पथ है।
चरण 1: एक एकल उत्कृष्ट एजेंट बनाएं
कुछ भी ऑर्केस्ट्रेट करने से पहले, आपको एक ऐसे एजेंट की ज़रूरत है जो एक काम बेहद अच्छी तरह से करे।
एक Claude प्रोजेक्ट खोलें। यह आपका दीवारों से घिरा कार्यक्षेत्र है। उन निर्देशों, संदर्भ फ़ाइलों और उदाहरणों को डालें जो काम को परिभाषित करते हैं। एक प्रोजेक्ट संदर्भ को अलग रखता है ताकि एजेंट असंबंधित बातचीत से भ्रमित न हो।
अब सिस्टम निर्देश लिखें। यह सबसे महत्वपूर्ण चीज़ है जो आप इस पूरे पाठ्यक्रम में करेंगे। एक कमज़ोर निर्देश एक कमज़ोर एजेंट पैदा करता है, चाहे आप उनमें से कितने भी स्टैक करें। एक मजबूत निर्देश भूमिका, मानक, प्रारूप और सीमाओं को परिभाषित करता है।
यहाँ एक मजबूत एजेंट निर्देश की संरचना है:
- भूमिका: "आप एक रिसर्च विशेषज्ञ हैं। आपका एकमात्र काम किसी दिए गए विषय पर तथ्यात्मक दावों को इकट्ठा करना और सत्यापित करना है।"
- मानक: "प्रत्येक दावा एक विश्वसनीय स्रोत द्वारा समर्थित होना चाहिए। यदि आप किसी दावे को सत्यापित नहीं कर सकते हैं, तो आप इसे शामिल करने के बजाय असत्यापित के रूप में चिह्नित करते हैं।"
- प्रारूप: "निष्कर्षों को एक क्रमांकित सूची के रूप में लौटाएं। प्रत्येक आइटम: दावा, स्रोत, आत्मविश्वास का स्तर।"
- सीमाएं: "आप गद्य नहीं लिखते हैं। आप राय नहीं देते हैं। आप तथ्य इकट्ठा करते हैं और उन्हें सौंप देते हैं।"
इस चरण में क्या करें
- एक वास्तविक कार्य चुनें जो आप अक्सर करते हैं और जिसमें एक स्पष्ट, दोहराने योग्य प्रक्रिया शामिल है
- एक Claude प्रोजेक्ट में पूर्ण भूमिका/मानक/प्रारूप/सीमाएं निर्देश के साथ एक एकल एजेंट बनाएं
- इसे दस वास्तविक इनपुट पर परीक्षण करें और निर्देश को तब तक परिष्कृत करें जब तक आउटपुट सुसंगत न हो
- अंतिम निर्देश को एक पुन: प्रयोज्य टेम्पलेट के रूप में सहेजें
चरण 2: एक दूसरा एजेंट जोड़ें और उनके बीच काम पास करें
अब आप सभी मल्टी-एजेंट कार्यों की मुख्य चाल सीखते हैं: हैंडऑफ़।
सबसे सरल दो-एजेंट टीम एक कार्यकर्ता और एक आलोचक है। कार्यकर्ता एक ड्राफ्ट तैयार करता है। आलोचक इसकी समीक्षा करता है। यदि यह पास हो जाता है, तो आप इसे रख लेते हैं। यदि यह विफल हो जाता है, तो यह विशिष्ट फीडबैक के साथ वापस जाता है।
आप इसे पहले मैन्युअल रूप से चला सकते हैं। दो बातचीत खोलें। कार्यकर्ता के आउटपुट को आलोचक में पेस्ट करें। आलोचक के फीडबैक को वापस कार्यकर्ता में पेस्ट करें। प्रत्येक लूप के साथ गुणवत्ता को बढ़ते हुए देखें।
यह हाथ से अटपटा लगता है, और यही बात है। घर्षण को महसूस करना आपको सिखाता है कि आप बाद में क्या स्वचालित करेंगे। आप सहज रूप से समझ जाएंगे कि हैंडऑफ़ प्रारूप क्यों मायने रखता है, संरचित आउटपुट मुक्त पाठ को क्यों हरा देता है, और एक अस्पष्ट आलोचक बिल्कुल भी आलोचक न होने से भी बदतर क्यों है।
इस चरण में क्या करें
- एक कार्यकर्ता एजेंट और एक आलोचक एजेंट बनाएं, प्रत्येक अपने स्वयं के प्रोजेक्ट या बातचीत में
- सटीक प्रारूप को परिभाषित करें जो कार्यकर्ता आउटपुट करता है और आलोचक उपभोग करता है
- एक वास्तविक कार्य पर हाथ से पाँच पूर्ण कार्यकर्ता-आलोचक-कार्यकर्ता लूप चलाएं
- घर्षण के हर बिंदु को लिखें। वे आपके भविष्य के ऑटोमेशन लक्ष्य हैं
चरण 3: अपने एजेंटों को उपकरण दें
एक एजेंट जो केवल बात कर सकता है वह एक चैटबॉट है। एक एजेंट जो कार्य कर सकता है वह एक कार्यकर्ता है।
यह वह जगह है जहाँ Claude के कनेक्टर और Model Context Protocol आते हैं। MCP एक खुला मानक है जो Claude को एक सुसंगत इंटरफ़ेस के माध्यम से बाहरी टूल और डेटा स्रोतों से जुड़ने देता है। व्यवहार में, इसका मतलब है कि आपका एजेंट आपके दस्तावेज़ पढ़ सकता है, आपकी फ़ाइलें खोज सकता है, डेटाबेस से क्वेरी कर सकता है, API से खींच सकता है, या किसी अन्य ऐप में कार्रवाई कर सकता है।
कनेक्टर सक्षम होने पर, आपका रिसर्च एजेंट केवल वही भरोसा करने के बजाय वेब खोज सकता है और आपकी अपनी फ़ाइलें पढ़ सकता है जो वह पहले से जानता है। आपका लेखन एजेंट एक साझा स्टाइल गाइड से खींच सकता है। आपका कोडिंग एजेंट आपके वास्तविक रिपॉजिटरी को पढ़ सकता है।
उपकरण वही हैं जो एक चतुर बातचीत को वास्तविक काम में बदल देते हैं। जिस क्षण कोई एजेंट अपने स्वयं के इनपुट प्राप्त कर सकता है और अपने स्वयं के आउटपुट पर कार्य कर सकता है, आप एक कॉपी-पेस्ट बिचौलिए होना बंद कर देते हैं और एक प्रबंधक बनना शुरू कर देते हैं।
एक शब्द सावधानी जो प्रचार भीड़ छोड़ देती है: उपकरणों वाला एक एजेंट वास्तविक कार्रवाई कर सकता है, इसलिए आप इसे उपकरणों का सबसे संकीर्ण सेट देते हैं जिसकी इसे आवश्यकता है और आप किसी भी अपरिवर्तनीय चीज़ के लिए एक मानव को लूप में रखते हैं। एक फ़ाइल पढ़ना सुरक्षित है। आपकी ओर से एक ईमेल भेजना ऐसी चीज़ नहीं है जिसे आप पहले दिन बिना निगरानी के किसी एजेंट को करने देते हैं।
इस चरण में क्या करें
- अपने एजेंटों को वास्तव में जिन कनेक्टरों की आवश्यकता है, उन्हें एक बार में एक, प्रति बातचीत सक्षम करें
- अपने रिसर्च एजेंट को वेब सर्च और फ़ाइल एक्सेस दें और इसके आउटपुट की गुणवत्ता में उछाल देखें
- एक एजेंट को एक वास्तविक डेटा स्रोत से कनेक्ट करें जिसका आप प्रतिदिन उपयोग करते हैं
- परीक्षण करें कि जब कोई उपकरण कुछ भी या कोई त्रुटि नहीं लौटाता है तो क्या होता है, और एजेंट को निर्देश दें कि इसे कैसे संभालना है
चरण 4: ऑर्केस्ट्रेशन को स्वचालित करें
अब आप बिचौलिया बनना बंद कर देते हैं।
आपने मैन्युअल हैंडऑफ़ के घर्षण को महसूस किया है। आप प्रारूपों को जानते हैं। अब आप ऑर्केस्ट्रेटर, प्रबंधक एजेंट बनाते हैं जो आपके लिए पासिंग करता है।
ऑर्केस्ट्रेटर का निर्देश एक विशेषज्ञ से अलग दिखता है। यह प्रतिनिधिमंडल और असेंबली के बारे में है, निष्पादन के बारे में नहीं:
- "आप ऑर्केस्ट्रेटर हैं। आप एक लक्ष्य प्राप्त करते हैं। आप इसे उप-कार्यों में विभाजित करते हैं। आप प्रत्येक उप-कार्य को सही विशेषज्ञ को सौंपते हैं। आप उनके आउटपुट एकत्र करते हैं। आप ड्राफ्ट को आलोचक को भेजते हैं। आप अंतिम इकट्ठे परिणाम को तभी लौटाते हैं जब आलोचक अनुमोदन करता है।"
2026 में आपके पास इसे चलाने के दो साफ तरीके हैं। Claude के एजेंटिक टूलिंग के अंदर, आप उप-एजेंट स्थापित कर सकते हैं जिन्हें मुख्य एजेंट समानांतर काम के लिए स्पॉन और समन्वयित करता है, ऑर्केस्ट्रेटर एक साथ कई श्रमिकों में एक काम को विभाजित करता है और परिणामों को एक साथ जोड़ता है। या, यदि आप थोड़ा कोड के साथ सहज हैं, तो आप सीधे Claude API को कॉल करते हैं, ऑर्केस्ट्रेटर की योजना को प्रत्येक विशेषज्ञ को एक अलग अनुरोध के रूप में भेजते हैं और प्रतिक्रियाओं को वापस खिलाते हैं।
आपको दोनों की आवश्यकता नहीं है। वह चुनें जो आपके आराम स्तर से मेल खाता हो और इसे शिप करें।
इस चरण में क्या करें
- एक ऑर्केस्ट्रेटर निर्देश लिखें जो पूरी तरह से प्रतिनिधिमंडल और असेंबली पर केंद्रित हो
- इसे अपने मौजूदा विशेषज्ञों और आलोचक से जोड़ें
- इनपुट और आउटपुट के बीच कुछ भी छुए बिना एक पूर्ण लक्ष्य को शुरू से अंत तक चलाएं
- एक नियम जोड़ें जो किसी भी अपरिवर्तनीय कार्रवाई से पहले सिस्टम को रोकता है और आपसे पूछता है
चरण 5: इसे विश्वसनीय और दोहराने योग्य बनाएं
कोई भी एक बार एजेंट टीम को काम करवा सकता है। पेशेवर इसे सौवीं बार काम करवाते हैं।
यह चरण स्थायित्व के बारे में है। आप तीन चीजें जोड़ते हैं।
मूल्यांकन। ज्ञात अच्छे आउटपुट के साथ परीक्षण इनपुट का एक छोटा सेट बनाएं। किसी भी बदलाव के बाद उनके खिलाफ अपनी पूरी टीम चलाएं। यदि गुणवत्ता गिरती है, तो आप इसे अपने उपयोगकर्ताओं से पहले पकड़ लेते हैं। यह एकमात्र आदत है जो एक खिलौने को एक उपकरण से अलग करती है।
मेमोरी। अपनी टीम को लगातार संदर्भ दें ताकि वह हर सत्र में शून्य से शुरू न हो। Claude की प्रोजेक्ट मेमोरी और आर्टिफैक्ट्स में अब उपलब्ध स्थायी भंडारण के साथ, आपकी टीम सत्रों में निर्णय, प्राथमिकताएं और पिछले काम को याद रख सकती है।
विफलता प्रबंधन। पहले से तय करें कि जब कोई विशेषज्ञ कचरा लौटाता है, कोई उपकरण विफल हो जाता है, या आलोचक और कार्यकर्ता एक लूप में फंस जाते हैं तो क्या होता है। एक पेशेवर सिस्टम में एक परिभाषित एस्केप हैच होता है। एक शौकिया सिर्फ टूट जाता है और आपको एक नाराज उपयोगकर्ता से पता चलता है।
इस चरण में क्या करें
- एक दस-मामले का मूल्यांकन सेट बनाएं और इसे अपने सिस्टम में प्रत्येक बदलाव के बाद चलाएं
- लगातार मेमोरी जोड़ें ताकि टीम सत्रों के बीच संदर्भ ले जाए
- प्रत्येक एजेंट के लिए स्पष्ट विफलता व्यवहार को परिभाषित करें: जब इनपुट खराब हों तो क्या करना है
- आलोचक-कार्यकर्ता लूप पर एक कठिन सीमा निर्धारित करें ताकि टीम कभी हमेशा के लिए स्पिन न करे
एक वास्तविक उदाहरण: सामग्री टीम
मुझे इसे एक ऐसी टीम के साथ ठोस बनाने दें जिसे आप इस सप्ताहांत बना सकते हैं।
मान लें कि आप ऑटोपायलट पर शोधित, लिखित, तथ्य-जांचे गए लेख तैयार करना चाहते हैं। यहाँ टीम है:
ऑर्केस्ट्रेटर एक विषय और एक लक्ष्य लंबाई लेता है। रिसर्च विशेषज्ञ वेब खोजता है, सत्यापित तथ्य एकत्र करता है, और एक संरचित ब्रीफ लौटाता है। लेखक उस ब्रीफ को आपकी आवाज में एक पूर्ण ड्राफ्ट में बदल देता है, एक स्टाइल गाइड से टोन खींचता है जिसे आपने एक फ़ाइल के रूप में जोड़ा है। आलोचक ड्राफ्ट को तीन मानकों के खिलाफ जांचता है: रिसर्च ब्रीफ के मुकाबले तथ्यात्मक सटीकता, आपकी स्टाइल गाइड का पालन, और संरचनात्मक पूर्णता। यदि कुछ भी विफल होता है, तो यह विशिष्टताओं के साथ लेखक के पास वापस जाता है। केवल एक अनुमोदित ड्राफ्ट आप तक पहुंचता है।
आप ऑर्केस्ट्रेटर को एक पंक्ति देते हैं: "X पर 1,500 शब्दों का एक लेख लिखें।" बीस मिनट बाद आपको एक ड्राफ्ट मिलता है जिसे पहले ही दो बार शोध, लिखा और समीक्षा किया जा चुका है। आप अंतिम संपादन करते हैं और शिप करते हैं।
यह कोई कल्पना नहीं है। उसका हर टुकड़ा आज उपरोक्त चरणों के साथ बनाने योग्य है। आपके और उस टीम के बीच एकमात्र चीज़ बैठना और इसे एक बार में एक चरण बनाना है।
वे गलतियाँ जो एजेंट टीमों को मार देती हैं
कुछ जाल लगभग सभी को पकड़ लेते हैं। उन्हें छोड़ें और आप दोगुनी तेजी से आगे बढ़ेंगे।
एक के काम करने से पहले पाँच एजेंट बनाना। आपको पहले पूरा संगठन चार्ट डिजाइन करने का लालच होगा। ऐसा न करें। एक उत्कृष्ट एजेंट एक साथ जुड़े पाँच औसत एजेंटों को हरा देता है। प्रत्येक नए एजेंट को अर्जित करें।
अस्पष्ट भूमिकाएं। "रिसर्च में मदद करें" कोई भूमिका नहीं है। "तथ्यात्मक दावों को इकट्ठा करें और सत्यापित करें, एक संरचित सूची के रूप में लौटाएं, कभी गद्य न लिखें" एक भूमिका है। विशिष्टता ही सब कुछ है।
कोई आलोचक नहीं। एक टीम जो केवल उत्पादन करती है और कभी समीक्षा नहीं करती है, वह तेज, आत्मविश्वासी कचरा पैदा करती है। आलोचक वैकल्पिक नहीं है।
उपकरणों पर अत्यधिक भरोसा। कार्य करने की शक्ति वाले एक एजेंट को सबसे संकीर्ण अनुमतियों और किसी भी चीज़ पर एक मानव गेट की आवश्यकता होती है जिसे पूर्ववत नहीं किया जा सकता है। गति एक हटाई गई फ़ाइल या एक ईमेल के लायक नहीं है जिसे आप भेजने का इरादा नहीं रखते थे।
मूल्यांकन छोड़ना। यदि आप यह माप नहीं सकते कि आपकी टीम किसी बदलाव के बाद बेहतर या बदतर हुई है या नहीं, तो आप एक सिस्टम नहीं बना रहे हैं। आप जुआ खेल रहे हैं।
मल्टी-एजेंट सिस्टम के बारे में ईमानदार सच्चाई
एजेंटों की एक टीम एक ऐसी प्रक्रिया को ठीक नहीं करेगी जिसे आप समझते नहीं हैं।
यदि आप वर्णन नहीं कर सकते कि किसी कार्य को चरण दर चरण कैसे किया जाना चाहिए, तो आप इसे एजेंटों को सौंप नहीं सकते, क्योंकि प्रत्येक एजेंट को एक स्पष्ट निर्देश की आवश्यकता होती है और आप वही हैं जो इसे लिख रहे हैं। एजेंट टीम बनाने का काम ज्यादातर अपनी प्रक्रिया के बारे में स्पष्ट रूप से सोचने का काम है। एजेंट आसान हैं। स्पष्टता कठिन है।
लेकिन यहाँ वह है जो इसे सार्थक बनाता है। जो लोग एजेंटों को ऑर्केस्ट्रेट करना सीखते हैं, उन्हें AI द्वारा प्रतिस्थापित नहीं किया जाएगा। वे वही हैं जो पूरी टीम का काम खुद करने के लिए AI का उपयोग कर रहे हैं। वह है लीवरेज। एक व्यक्ति, एक स्पष्ट प्रक्रिया, और एजेंटों की एक टीम जो कभी नहीं सोती।
जिस खिड़की में इसे बनाना आपको बाकी सभी से वर्षों आगे रखता है, वह अभी खुली है।
आज से छह सप्ताह बाद आप या तो अभी भी एक चैट बॉक्स में एक सवाल टाइप कर रहे होंगे और एक जवाब की प्रतीक्षा कर रहे होंगे।
या आप एक ऐसी टीम चला रहे होंगे जो आपके सोते समय काम करती है।
अंतर यह है कि क्या आप आज चरण एक बनाना शुरू करते हैं।
अगर आपको यह उपयोगी लगा, तो मुझे फॉलो करें @eng_khairallah1 ऐसी और AI सामग्री के लिए। मैं हर हफ्ते ब्रेकडाउन, कोर्स और टूल पोस्ट करता हूं।
उम्मीद है यह आपके लिए उपयोगी था, खैरुल्लाह ❤️
