जब Anthropic ने 2024 के अंत में Building Effective Agents प्रकाशित किया, तो उसने उद्योग के लिए कुछ दुर्लभ किया: उसने इंजीनियरों को एक साझा शब्दावली प्रदान की। आर्टिफिशियल जनरल इंटेलिजेंस के बारे में एक और घोषणापत्र देने के बजाय, इस गाइड ने LLM सिस्टम को संरचित करने के लिए छह स्पष्ट पैटर्न पेश किए। डेढ़ साल बाद, 2026 में, परिदृश्य पूरी तरह से अलग दिखता है। Model Context Protocol एक सार्वभौमिक मानक बन गया है। Claude ने नई क्षमताएं हासिल कर ली हैं। अधिकांश संगठनों में अब प्रोडक्शन में कम से कम एक एजेंट चल रहा है। इस पृष्ठभूमि में, यह पूछना उचित है कि क्या वे छह पैटर्न अभी भी मायने रखते हैं, या वे पिछले साल के मॉडल वेट्स के साथ आर्काइव का हिस्सा बन चुके हैं।

यह जानने के लिए मैंने एक साइड रिपॉजिटरी में लोकल मॉडल के विरुद्ध सभी छह पैटर्न का परीक्षण किया। उत्तर है: हाँ। वे अभी भी टिके हुए हैं। लेकिन इसलिए नहीं कि वे अपरिवर्तनीय नियम हैं। वे इसलिए टिके हुए हैं क्योंकि पिछले अठारह महीनों के प्रोडक्शन अनुभव ने इस फ्रेमवर्क के मूल तर्क को प्रमाणित किया है।

इस फ्रेमवर्क ने वास्तव में हमें क्या दिया

इन छह पैटर्न को ठीक से याद रखना ज़रूरी है: Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers, और Autonomous Agents। आखिरी वाला अनिवार्य रूप से एक लूप है जिसमें मॉडल योजना बनाता है, कार्य करता है, निरीक्षण करता है, और तब तक दोहराता है जब तक कि कोई शर्त पूरी न हो जाए।

गाइड आने से पहले ही कई इंजीनियर प्रॉम्प्ट्स को चेन कर रहे थे या वर्कर थ्रेड्स को कार्य सौंप रहे थे। Anthropic ने जो प्रदान किया वह था वर्गीकरण (taxonomy)। एक व्यक्ति का "agent" दूसरे व्यक्ति का "workflow" था, और तीसरे व्यक्ति का "multi-step tool call" था। गाइड ने इस अव्यवस्था को स्पष्ट सीमाओं वाले बकेटों में व्यवस्थित कर दिया। इससे एक-दूसरे की बात समझे बिना ही ट्रेड-ऑफ पर चर्चा करना संभव हो गया। हाइप में डूबे इस क्षेत्र में, स्पष्ट भाषा एक प्रकार का बुनियादी ढांचा है।

उद्योग ने इसके चारों ओर नहीं, बल्कि इसके ऊपर निर्माण किया

2026 तक, ये श्रेणियां इस बात का हिस्सा बन चुकी हैं कि टीमें सिस्टम कैसे डिजाइन करती हैं। Anthropic अभी भी उन्हें अपने Academy कोर्सेस में सिखाता है। रिसर्च पेपर और इंजीनियरिंग ब्लॉग अभी भी नए आर्किटेक्चर का वर्णन करने के लिए उन्हीं छह बकेटों का उपयोग करते हैं। इस तरह का स्थायित्व उस विषय के लिए असामान्य है जो हर तिमाही में अपना स्टैक बदल देता है।

कारण सीधा है। उद्योग ने फ्रेमवर्क को बदला नहीं। बल्कि इसके ऊपर निर्माण किया। MCP जैसे नए टूल और नए Agent Skills मानक प्लंबिंग के रूप में कार्य करते हैं। वे किसी मॉडल को डेटाबेस से जोड़ना, टूल को एक्सपोज़ करना, या स्टेट को मैनेज करना आसान बनाते हैं। लेकिन वे यह तर्क नहीं बदलते कि ऑर्केस्ट्रेटर के बजाय राउटर का उपयोग कब करना है। एक बेहतर पाइप फर्श के नक्शे को दोबारा नहीं लिखता।

2026 का प्रोडक्शन डेटा इसकी पुष्टि करता है। सबसे सामान्य डिप्लॉयमेंट पैटर्न अभी भी ह्यूमन रिव्यू के साथ एक सिंगल टूल-यूज़ कॉल है। दूसरा सबसे सामान्य पैटर्न ठीक एक व्यक्ति को हैंडऑफ के साथ मल्टी-स्टेप वर्कफ़्लो है। दोनों ही Prompt Chaining और Routing के प्रत्यक्ष वंशज हैं। लाइव सिस्टम में पूर्ण स्वायत्त लूप अपवाद बने हुए हैं, नियम नहीं।

संयम की जीत हुई

मूल गाइड की सबसे अच्छी सलाह वही थी जिसे 2024 में सबसे अधिक अनदेखा किया गया था: जो काम करे, उसी सबसे सरल पैटर्न का उपयोग करें। यदि एक हार्डकोडेड पाथ काम पूरा कर सकता है, तो पूर्ण स्वायत्त एजेंट तैनात न करें।

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

यह महत्वाकांक्षा के खिलाफ तर्क नहीं है। यह संयोजन (composition) के पक्ष में तर्क है। पैटर्न तब सबसे अच्छा काम करते हैं जब आप मेनू में सबसे जटिल विकल्प को बिना सोचे-समझे चुनने के बजाय उन्हें जानबूझकर मिलाते हैं।

जहाँ दरारें दिखने लगती हैं

यह फ्रेमवर्क हर समस्या का समाधान नहीं है। कुछ कठिन सीमाएँ हैं जो प्रोटोटाइप चरण से बाहर निकलते ही सामने आ जाती हैं।

उच्च-आवृत्ति (high-frequency), कम लागत वाले कार्यों के लिए, deterministic code ही बेहतर है। जब pandas इसे बिना किसी hallucination के मिलीसेकंड में कर सकता है, तो एक LLM को CSV column को normalize नहीं करना चाहिए। यदि आप एक स्पष्ट evaluation goal परिभाषित नहीं कर सकते हैं, तो autonomous loops से बचें। बिना किसी स्पष्ट stopping condition के, मॉडल तब तक iterate करता रहेगा जब तक कि वह रुकने का कोई कारण न बना ले। उन high-stakes निर्णयों के लिए जिनमें external grounding की आवश्यकता होती है, केवल मॉडल के आंतरिक ज्ञान पर भरोसा न करें। और data retrieval में आने वाली bottlenecks पर नज़र रखें। कोई भी pattern जो vector search या external APIs पर निर्भर करता है, वह तब बाधित हो सकता है यदि आपका database धीमा है या आपका context window irrelevant chunks से भरा हुआ है।

ये काल्पनिक edge cases नहीं हैं। ये वे constraints हैं जो एक काम करने वाले demo और एक ऐसे system के बीच अंतर करती हैं जो weekend तक टिक सके।

एक कठोर जांच और एक गलत विफलता

मैंने अपना test repository बनाते समय इस framework के व्यावहारिक मूल्य को सीखा। मैं Evaluator-Optimizer pattern लागू कर रहा था। मेरा evaluator एक hardcoded regex के रूप में शुरू हुआ था जो विशिष्ट keywords के लिए मॉडल के output को स्कैन करता था। मॉडल ने एक सही और तर्कसंगत उत्तर दिया, जिसमें उन सटीक शब्दों के बजाय synonyms का उपयोग किया गया था जिन्हें मैं खोज रहा था। evaluator ने इसे विफलता के रूप में चिह्नित कर दिया।

मॉडल सही था। मेरी जांच बहुत कठोर थी।

इसे ठीक करने के लिए केवल एक शब्द सूची का विस्तार करने से कहीं अधिक की आवश्यकता थी। मैंने evaluator को ही LLM-based judgment में बदल दिया। इसमें अतिरिक्त tokens और कुछ मिलीसेकंड अधिक लगे, लेकिन इसने मूल्यांकन को सही स्तर के abstraction पर बहाल कर दिया। pattern स्वयं सही था। मैंने बस कार्य के लिए गलत implementation चुना था। यह ठीक उसी तरह की गलती है जिसे यह framework रोकने के लिए बनाया गया है। कुछ evaluations के लिए code की आवश्यकता होती है। अन्य के लिए model की। यह जानना कि कौन सा किसके लिए है, यही मुख्य उद्देश्य है।

अब इनका उपयोग कैसे करें

इन छह patterns को एक शुरुआती बिंदु के रूप में मानें, न कि पूर्ण नियम के रूप में। एक single prompt के साथ शुरुआत करें। यदि इनपुट प्रकारों में गुणवत्ता असंगत है, तो विभिन्न अनुरोधों को specialized prompts पर भेजने के लिए एक routing layer जोड़ें। यदि निर्णय लेने से पहले आपको कई स्वतंत्र दृष्टिकोणों की आवश्यकता है, तो Parallelization का उपयोग करें। यदि कार्य बड़ा और विभाज्य है, तो Orchestrator-Workers का प्रयास करें। पूर्ण autonomous loop का उपयोग तभी करें जब समस्या का दायरा pre-map करने के लिए बहुत व्यापक हो और आपके पास एक विश्वसनीय