हर कोई टीम जो AI एजेंट बना रही है, एक ही दीवार से टकराती है।
आप एक प्रॉम्प्ट और कुछ टूल्स से शुरू करते हैं।
यह काम करता है।
फिर ज़रूरतें बढ़ती हैं। और एज केस। और टीमें। और जोखिम।
अचानक आपका "एजेंट" एक 3,000-शब्दों का सिस्टम प्रॉम्प्ट बन जाता है जो एक साथ पाँच काम करने की कोशिश कर रहा होता है।
समाधान अधिक प्रॉम्प्ट इंजीनियरिंग नहीं है।
यह सही पैटर्न चुनना है।
ये हैं वे 15 पैटर्न जिनसे हर प्रोडक्शन एजेंटिक सिस्टम बनता है — और कब किसका उपयोग करना है, यह बिल्कुल सटीक।
पैटर्न चुनने से पहले
हर कार्य को एजेंट की ज़रूरत नहीं होती।
एक कार्य एजेंट को तब उचित ठहराता है जब:
→ एक मॉडल कॉल विश्वसनीय परिणाम नहीं दे सकता
→ मॉडल को रनटाइम पर टूल्स या डेटा स्रोतों के बीच चुनना होता है
→ कार्य में योजना, सत्यापन, या पुनरावृत्त सुधार की आवश्यकता होती है
→ वर्कफ़्लो में वास्तविक अनिश्चितता है जिसे हार्डकोड नहीं किया जा सकता
एक कार्य को आमतौर पर एजेंट की ज़रूरत नहीं होती जब इनपुट-से-आउटपुट पथ पूर्वानुमानित हो।
सारांशीकरण। वर्गीकरण। सरल निष्कर्षण। टेम्पलेटेड जनरेशन।
ये सीधे मॉडल कॉल के रूप में तेज़, सस्ते और अधिक विश्वसनीय हैं।
इन्हें एजेंट में लपेटने से केवल विलंबता और विफलता बिंदु जुड़ते हैं, बिना किसी लाभ के।

पैटर्न 1 — एकल एजेंट (Single Agent)
सबसे सरल और सबसे सामान्य शुरुआती बिंदु।
एक मॉडल। एक सिस्टम प्रॉम्प्ट। टूल्स का एक सीमित सेट।
मॉडल तय करता है कि किस टूल को कॉल करना है, परिणाम देखता है, और तब तक जारी रहता है जब तक उसके पास उत्तर देने के लिए पर्याप्त जानकारी न हो।
वास्तविक उदाहरण: एक ग्राहक सहायता एजेंट जो ऑर्डर की स्थिति देखता है, शिपिंग की जाँच करता है, और यदि समस्या हल नहीं कर सकता तो एक टिकट बनाता है — यह सब 2-3 टूल्स और एक स्पष्ट कार्य के साथ।
इसका उपयोग करें जब: कार्य अच्छी तरह से परिभाषित हो, टूल सेट छोटा हो, और एक एजेंट बिना भ्रमित हुए पूरे संदर्भ को संभाल सके।
यह तब टूटता है जब: आप टूल्स जोड़ते रहते हैं और सिस्टम प्रॉम्प्ट एक पेज से अधिक लंबा हो जाता है। यह संकेत है कि आपको एक अलग पैटर्न की ज़रूरत है — लंबे प्रॉम्प्ट की नहीं।

पैटर्न 2 — मल्टी-एजेंट अनुक्रमिक (Multi-Agent Sequential)
विशिष्ट एजेंट एक निश्चित क्रम में चलते हैं। प्रत्येक का आउटपुट अगले के इनपुट को फीड करता है।
वास्तविक उदाहरण: एक अनुबंध समीक्षा पाइपलाइन — एक एजेंट दायित्वों को निकालता है, अगला जोखिमों की पहचान करता है, तीसरा खरीद के लिए सारांश तैयार करता है। क्रम कभी नहीं बदलता।
इसका उपयोग करें जब: वर्कफ़्लो में स्पष्ट, दोहराए जाने योग्य चरण हों और प्रत्येक चरण बिल्कुल वही उत्पन्न करे जो अगले को चाहिए।
यह तब टूटता है जब: प्रक्रिया के बीच में जो पाया जाता है, उसके आधार पर वास्तव में क्रम बदलने की आवश्यकता होती है। अनुक्रमिक पाइपलाइन मानती हैं कि पथ निश्चित है — यदि ऐसा नहीं है, तो आपको अधिक गतिशील किसी चीज़ की ज़रूरत है।

पैटर्न 3 — मल्टी-एजेंट समानांतर (Multi-Agent Parallel)
स्वतंत्र उप-कार्य एक साथ चलते हैं, फिर एक दृश्य में संयुक्त हो जाते हैं।
वास्तविक उदाहरण: रात के 2 बजे एक प्रोडक्शन घटना। तीन एजेंट एक ही समय में लॉग, मेट्रिक्स और हाल के डिप्लॉयमेंट की जाँच करते हैं — एक के बाद एक नहीं — क्योंकि आउटेज के दौरान हर मिनट मायने रखता है।
इसका उपयोग करें जब: उप-कार्य वास्तव में स्वतंत्र हों और गति मायने रखती हो।
यह तब टूटता है जब: कार्य वास्तव में एक-दूसरे के परिणामों पर निर्भर करते हैं। आश्रित कार्य को समानांतर निष्पादन में मजबूर करने से केवल रेस कंडीशन और अधूरा संदर्भ बनता है।

पैटर्न 4 — लूप (Loop)
बाहर निकलने की शर्त पूरी होने तक चरणों के एक क्रम को दोहराएँ।
वास्तविक उदाहरण: एक डेटा सफाई एजेंट जो गंदे CSV डेटा का प्रोफाइल बनाता है, एक सफाई योजना प्रस्तावित करता है, जाँचता है कि क्या यह गुणवत्ता मानकों को पूरा करता है, और यदि नहीं करता तो पुनः प्रयास करता है — अधिकतम निर्धारित राउंड तक।
इसका उपयोग करें जब: कार्य को कई प्रयासों की आवश्यकता हो और आप एक स्पष्ट, जाँचने योग्य रुकने की स्थिति परिभाषित कर सकें।
यह तब टूटता है जब: कोई विश्वसनीय बाहर निकलने की शर्त न हो। इसके बिना, आपको बेकाबू लागत और एक ऐसा सिस्टम मिलता है जो कभी समाप्त नहीं हो सकता।

पैटर्न 5 — समीक्षा और आलोचना (Review and Critique)
एक जज एजेंट दूसरे एजेंट के आउटपुट की समीक्षा करता है, उसकी आलोचना करता है, और विशिष्ट कार्रवाई योग्य फीडबैक देता है।
वास्तविक उदाहरण: एक उत्पन्न रिपोर्ट की एक अलग "आलोचक" एजेंट द्वारा समीक्षा की जाती है जो किसी मानव तक पहुँचने से पहले कमजोर दावों, लापता सबूत, या अस्पष्ट अनुभागों को चिह्नित करता है।
इसका उपयोग करें जब: गुणवत्ता गति से अधिक मायने रखती हो और आप सिस्टम में एक दूसरी राय बेक करना चाहते हों, बाद में जोड़ना नहीं।
यह तब टूटता है जब: आलोचक एजेंट जनरेटर के समान अंध स्थानों का उपयोग करता है। समान मान्यताओं पर प्रशिक्षित एक समीक्षक उन्हीं गलतियों को नहीं पकड़ेगा।

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

पैटर्न 7 — समन्वयक (Coordinator)
एक केंद्रीय रूटिंग एजेंट वास्तव में पूछे जा रहे प्रश्न के आधार पर विशिष्ट एजेंटों को अनुरोध निर्देशित करता है।
वास्तविक उदाहरण: सहायता टिकट बिलिंग, तकनीकी, खाता, शिपिंग, या धोखाधड़ी विशेषज्ञों को रूट किए जाते हैं — प्रत्येक के पास एक एजेंट के बजाय संकीर्ण संदर्भ होता है जो सब कुछ जानने की कोशिश करता है।
इसका उपयोग करें जब: आपके पास वास्तव में विभिन्न प्रकार के अनुरोध हों जिन्हें अलग-अलग संदर्भ, टूल्स या निर्णय तर्क की आवश्यकता हो।
यह तब टूटता है जब: रूटिंग स्वयं अस्पष्ट हो जाती है। यदि अनुरोध साफ-साफ एक श्रेणी में नहीं आते हैं, तो समन्वयक एक नई बाधा और गलत रूटिंग का स्रोत बन जाता है।

पैटर्न 8 — पदानुक्रमित कार्य अपघटन (Hierarchical Task Decomposition)
एक रूट एजेंट एक जटिल लक्ष्य को छोटे उप-लक्ष्यों में तोड़ता है, उन्हें विशेषज्ञ कार्यकर्ताओं को सौंपता है, फिर सब कुछ एक उत्तर में संश्लेषित करता है।
वास्तविक उदाहरण: "अगले साल हमें किन 3 देशों में विस्तार करना चाहिए?" प्रतिस्पर्धी विश्लेषण, नियामक अनुसंधान, रसद व्यवहार्यता और बाजार आकार में टूट जाता है — प्रत्येक को एक अलग विशेषज्ञ द्वारा संभाला जाता है, फिर संयुक्त किया जाता है।
इसका उपयोग करें जब: समस्या एक तर्क पास के लिए बहुत व्यापक हो लेकिन स्वतंत्र विशेषज्ञता के क्षेत्रों में साफ-साफ टूट जाती है।
यह तब टूटता है जब: उप-लक्ष्य वास्तव में स्वतंत्र नहीं होते हैं। यदि कार्यधाराओं को वास्तविक समय में एक-दूसरे को सूचित करने की आवश्यकता है, तो उन्हें अग्रिम में विघटित करने से वह अंतःक्रिया खो जाती है।

पैटर्न 9 — झुंड (Swarm)
कई विशेषज्ञ एजेंट एक साझा चर्चा में योगदान करते हैं, एक-दूसरे की मान्यताओं को चुनौती देते हैं, और एक सुविधाकर्ता अंतिम सिफारिश का संश्लेषण करता है।
वास्तविक उदाहरण: क्या कंपनी को एक सब्सक्रिप्शन टियर लॉन्च करना चाहिए? रिसर्च, इंजीनियरिंग, वित्त और सहायता एजेंट एक सुविधाकर्ता द्वारा व्यापार-बंदियों को तौलने से पहले कई राउंड में अपने-अपने दृष्टिकोण पर बहस करते हैं।
इसका उपयोग करें जब: कोई एकल "सही" उत्तर न हो — आपको वास्तव में प्रतिस्पर्धी दृष्टिकोणों द्वारा आकार दिए गए एक सुविचारित निर्णय की आवश्यकता हो।
यह तब टूटता है जब: आपको तेज़, नियतात्मक उत्तर की आवश्यकता हो। झुंड जानबूझकर धीमे और खोजपूर्ण होते हैं — यदि आपको गति चाहिए तो गलत उपकरण।

पैटर्न 10 — ReAct (Reason and Act)
एजेंट तर्क और क्रिया के बीच वैकल्पिक करता है: तय करता है कि क्या जाँचना है, एक टूल कॉल करता है, परिणाम देखता है, तय करता है कि अभी तक पर्याप्त सबूत है या नहीं।
वास्तविक उदाहरण: "क्यू प्रोसेसर फंसा हुआ लगता है" — एजेंट दस्तावेज़ खोजता है, सेवा स्वास्थ्य की जाँच करता है, निष्कर्षों को सहसंबंधित करता है, और उसके बाद ही एक समाधान सुझाता है। जाँच पथ पूर्वनिर्धारित नहीं है; यह इस बात पर निर्भर करता है कि वह रास्ते में क्या पाता है।
इसका उपयोग करें जब: उत्तर का पथ वास्तव में अग्रिम में योजनाबद्ध नहीं किया जा सकता — यह इस बात पर निर्भर करता है कि प्रत्येक चरण क्या प्रकट करता है।
यह तब टूटता है जब: जाँच बिना अभिसरण के लंबी चलती है। हमेशा तर्क-क्रिया चक्रों को सीमित करें, अन्यथा आप अनंत अन्वेषण का जोखिम उठाते हैं।

पैटर्न 11 — मानव-इन-द-लूप (Human-in-the-Loop)
एजेंट जाँच करता है और सिफारिश करता है, लेकिन जोखिम भरे या अस्पष्ट मामलों पर अंतिम निर्णय मानव लेता है।
वास्तविक उदाहरण: रिफंड अनुमोदन — कम जोखिम वाले, स्पष्ट मामले स्वचालित होते हैं। उच्च राशि, धोखाधड़ी संकेत, या नीति अपवाद कुछ भी अंतिम रूप देने से पहले मानव समीक्षा के लिए रुक जाते हैं।
इसका उपयोग करें जब: निर्णय में वास्तविक वित्तीय, कानूनी या प्रतिष्ठित जोखिम हो और पूर्ण स्वचालन अभी स्वीकार्य न हो।
यह तब टूटता है जब: आप इसे एक वास्तुशिल्प सुविधा के बजाय केवल एक UI सुविधा के रूप में मानते हैं। आपको टिकाऊ स्थिति, समीक्षक असाइनमेंट, टाइमआउट हैंडलिंग और एस्केलेशन पथ की आवश्यकता है — न कि केवल एक "रोकें" बटन की।

पैटर्न 12 — योजना बनाएँ और निष्पादित करें (Plan-and-Execute)
एक योजनाकार एजेंट कोई भी कार्रवाई करने से पहले अग्रिम में एक पूर्ण संरचित योजना बनाता है — समीक्षा योग्य और संशोधनीय। फिर एक निष्पादक चरणों के माध्यम से चलता है।
वास्तविक उदाहरण: "वर्कर फ्लीट को 10 से 20 इंस्टेंस में आकार दें, सत्यापित करें कि क्यू खाली हो गया है, रनबुक अपडेट करें।" निष्पादन शुरू होने से पहले पूरी योजना दिखाई देती है, ReAct के विपरीत जहां पथ चरण दर चरण उभरता है।
इसका उपयोग करें जब: आप चाहते हैं कि कोई भी कार्रवाई होने से पहले योजना समीक्षा योग्य या अनुमोदन योग्य हो — वास्तविक परिणामों वाले संचालन के लिए महत्वपूर्ण।
यह तब टूटता है जब: वातावरण योजना के निष्पादित होने की तुलना में तेज़ी से बदलता है। आँख बंद करके निष्पादित की गई एक बासी योजना बिल्कुल भी योजना न होने से भी बदतर है।

पैटर्न 13 — रिफ्लेक्शन (Reflexion)
एजेंट अपनी स्वयं की विफलताओं का मूल्यांकन करता है, इस बात पर विचार करता है कि क्या गलत हुआ, और उस स्मृति को अगले प्रयास में ले जाता है।
वास्तविक उदाहरण: एक कोड जनरेशन एजेंट एक स्क्रिप्ट लिखता है, वह रनटाइम पर विफल हो जाती है, एजेंट वास्तविक त्रुटि का विश्लेषण करता है, रिकॉर्ड करता है कि क्या ठीक करना है, और पुनः प्रयास करता है — हर प्रयास के साथ समझदार होता जाता है, उसी गलती को दोहराने के बजाय।
इसका उपयोग करें जब: विफलताएँ जानकारीपूर्ण हों और आत्म-सुधार वास्तव में अगले प्रयास में सुधार करता हो।
यह तब टूटता है जब: विफलता मोड यादृच्छिक या एक-दूसरे से असंबंधित हों। रिफ्लेक्शन तभी मदद करता है जब सीखने के लिए कोई वास्तविक पैटर्न हो।

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

पैटर्न 15 — ईवेंट-संचालित एजेंट (Event-Driven Agent)
एजेंट पूछे जाने की प्रतीक्षा नहीं करता। यह एक ईवेंट स्ट्रीम की सदस्यता लेता है और शर्त ट्रिगर होते ही कार्य करता है।
वास्तविक उदाहरण: एक धोखाधड़ी का पता लगाने वाला एजेंट जो एक संदिग्ध लेन-देन ईवेंट फायर होते ही प्रतिक्रिया करता है — जब तक सहायता टिकट अंततः इसे सामने लाता है, तब तक नुकसान हो चुका होता है।
इसका उपयोग करें जब: समय किसी भी चीज़ से अधिक मायने रखता हो, और मानव अनुरोध की प्रतीक्षा करने का मतलब कार्य करने की खिड़की को खो देना हो।
यह तब टूटता है जब: ट्रिगरिंग स्थितियाँ खराब परिभाषित हों। अस्पष्ट ट्रिगर्स वाली एक शोरगुल वाली ईवेंट स्ट्रीम एक ऐसी प्रणाली में बदल जाती है जो लगातार झूठा अलार्म देती है — या इससे भी बदतर, वास्तविक संकेत को खो देती है।

पैटर्न चयन — अनिश्चितता से मेल खाएँ, प्रचार से नहीं
सही पैटर्न आपके काम में अनिश्चितता के आकार से मेल खाता है:
→ अनिश्चित कि किस टूल का उपयोग करें → एकल एजेंट या ReAct
→ अनिश्चित कि कहाँ रूट करें → समन्वयक
→ गुणवत्ता के बारे में अनिश्चित → समीक्षा और आलोचना या पुनरावृत्त शोधन
→ अनिश्चित निष्पादन पथ → योजना बनाएँ और निष्पादित करें या ReAct
→ स्वयं-सुधार के बारे में अनिश्चित → रिफ्लेक्शन या लूप
→ व्यावसायिक जोखिम के बारे में अनिश्चित → मानव-इन-द-लूप या कस्टम लॉजिक
→ अनिश्चित समस्या संरचना → पदानुक्रमित अपघटन या झुंड
→ अनुरोध की प्रतीक्षा नहीं कर सकते → ईवेंट-संचालित एजेंट
एक झुंड एकल एजेंट से अधिक उन्नत नहीं है यदि कार्य को केवल एक विश्वसनीय टूल कॉल की आवश्यकता है।
योजना बनाएँ और निष्पादित करें ReAct से अपग्रेड नहीं है यदि आपकी योजना चरण तीन तक बासी हो जाती है।
सबसे विश्वसनीय प्रोडक्शन सिस्टम सबसे स्वायत्त नहीं होते हैं।
वे स्वायत्तता को ठीक वहीं रखते हैं जहाँ वह मूल्य बनाती है — और इसे हर जगह नियंत्रित करते हैं।

प्रोडक्शन एजेंटिक सिस्टम के लिए 10 नियम
- सबसे छोटे पैटर्न से शुरू करें जो काम करता है। कमजोर टूल अनुबंधों वाले मल्टी-एजेंट सिस्टम की तुलना में साफ टूल अनुबंधों वाला एकल एजेंट बेहतर है।
- टूल विवरण अनुबंधों की तरह लिखें। मॉडल केवल विवरण से जानता है कि टूल क्या करता है — आपके इरादे से नहीं।
- प्रति अनुरोध पुनरावृत्तियों, टूल कॉल और खर्च को सीमित करें। बजट सीमा के बिना एक एजेंट एक देयता है जो बिल में दिखने की प्रतीक्षा कर रही है।
- पूर्ण क्रिया अनुरेखण लॉग करें। टूल कॉल, तर्क, आउटपुट, अंतिम निर्णय। इसके बिना, घटना जाँच अनुमान है।
- अपरिवर्तनीय कार्यों को नियतात्मक जाँच या मानव अनुमोदन के पीछे रखें। कभी भी मॉडल को धन संचलन या प्रोडक्शन परिवर्तन से पहले एकमात्र द्वार न बनने दें।
- केवल हैप्पी पथों से नहीं, बल्कि वास्तविक विफलता मामलों से मूल्यांकन करें। हैप्पी-पथ सटीकता एक प्रोटोटाइप है। एज-केस सटीकता एक उत्पाद है।
- सिस्टम प्रॉम्प्ट अपठनीय होने से पहले प्रॉम्प्ट को जिम्मेदारी से अलग करें। "लेकिन X मत करो जब Y" आपके प्रॉम्प्ट में रेंगना इसका मतलब है कि एजेंट दो काम कर रहा है।
- मल्टी-एजेंट सिस्टम को वितरित सिस्टम के रूप में मानें। आंशिक विफलता, टाइमआउट, पुनर्प्रयास और अवलोकनीयता वैकल्पिक नहीं हैं।
- मॉडल समीक्षा नियतात्मक सत्यापन का विकल्प नहीं है। गुणवत्ता में सुधार के लिए न्यायाधीशों का उपयोग करें। शुद्धता लागू करने के लिए परीक्षण और अनुमति जाँच का उपयोग करें।
- सरल पैटर्न को प्राथमिकता दें — इसलिए नहीं कि सरल हमेशा बेहतर होता है, बल्कि इसलिए कि आप जो जटिलता बजट बचाते हैं उसे बेहतर टूल, बेहतर प्रॉम्प्ट, बेहतर मूल्यांकन पर खर्च किया जा सकता है।
ये सभी 15 हैं।
अधिकांश टीमें इसलिए विफल नहीं होतीं क्योंकि उन्होंने गलत पैटर्न चुना।
वे इसलिए विफल होती हैं क्योंकि उन्होंने कभी नहीं पूछा कि वे वास्तव में किस अनिश्चितता को हल कर रहे थे।
पैटर्न चुनें। समस्या के आकार से मेल खाएँ। स्वायत्तता वहाँ न जोड़ें जहाँ वह अपनी जगह नहीं कमाती।
अगर यह उपयोगी था:
→ इसे अपनी टीम के हर इंजीनियर के साथ साझा करने के लिए रिपोस्ट करें जो एजेंट बना रहा है
→ और अधिक ऐसे विश्लेषणों के लिए @sairahul1 को फॉलो करें
→ इसे बुकमार्क करें — जब भी आप कोई नया एजेंट प्रोजेक्ट शुरू करेंगे तो आप इस पर वापस आएंगे
मैं AI, उत्पाद बनाने और ऐसे सिस्टम के बारे में लिखता हूँ जो आपके बिना काम करते हैं।





