Building Agentic Systems: आपके पहले एजेंट से एक भरोसेमंद सिस्टम तक

भाग 1 में हमने चर्चा की थी कि छात्रों और कामकाजी पेशेवरों को agentic systems क्यों समझने चाहिए, और किसी एक framework को सीखना असली करियर कौशल क्यों नहीं है।

अब हम क्यों से कैसे की ओर बढ़ते हैं।

पहला एजेंट बनाना हैरानी की हद तक आसान हो सकता है।

मॉडल को एक लक्ष्य दें, एक या दो टूल जोड़ें, और उसे तय करने दें कि उन्हें कब इस्तेमाल करना है।

कठिन सवाल इसके बाद आता है:

उस चलते हुए डेमो को ऐसे सिस्टम में कैसे बदलें जिस पर आप सचमुच भरोसा कर सकें?

यहीं से agentic engineering शुरू होती है।

एक उपयोगी समस्या से शुरुआत करें

मान लीजिए हम एक रिसर्च असिस्टेंट बनाना चाहते हैं।

उपयोगकर्ता पूछता है:

इस सप्ताह AI सुरक्षा में क्या बदला? भरोसेमंद स्रोत खोजें और संदर्भों के साथ एक छोटा सारांश तैयार करें।

एक सरल संस्करण कुछ ऐसा दिख सकता है:

सवाल → AI मॉडल → सर्च टूल → स्रोत → जवाब

यह पहले से ही सामान्य चैटबॉट से ज़्यादा है, क्योंकि मॉडल तय कर सकता है कि उसे बाहरी जानकारी कब चाहिए और उसे पाने के लिए टूल का उपयोग कर सकता है।

पहले प्रोजेक्ट के लिए इतना काफ़ी है।

शुरुआत में researcher एजेंट, reviewer एजेंट, citation एजेंट, writing एजेंट और manager एजेंट बनाने न बैठें।

पहले यह साबित करें कि एक एजेंट एक उपयोगी समस्या को अच्छी तरह हल कर सकता है।

यह सिद्धांत इसलिए मायने रखता है क्योंकि हर अतिरिक्त एजेंट, टूल और वर्कफ़्लो कुछ गड़बड़ होने की और जगहें जोड़ देता है।

चरण 1: एजेंट को टूल दें

टूल के बिना, मॉडल मुख्यतः उसी जानकारी पर तर्क कर सकता है जो पहले से उसके पास उपलब्ध है।

टूल उसे कार्रवाई करने की क्षमता देते हैं।

हमारे रिसर्च असिस्टेंट के पास ये हो सकते हैं:

• एक वेब सर्च टूल
• एक पेज पढ़ने वाला टूल
• उपयोगी स्रोतों को सहेजने वाला एक फ़ंक्शन

बुनियादी लूप कुछ ऐसा बन जाता है:

लक्ष्य को समझें
→ तय करें कि कौन-सी जानकारी कम है
→ कोई टूल चुनें
→ उसे इस्तेमाल करें
→ नतीजे को देखें
→ तय करें कि आगे क्या करना है

यह सरल लूप कई agentic systems के केंद्र में है।

लेकिन टूल का डिज़ाइन मायने रखता है।

किसी टूल का उद्देश्य स्पष्ट, इनपुट पूर्वानुमेय और नतीजे समझने लायक होने चाहिए।

अगर किसी एजेंट के पास अस्पष्ट नामों वाले 50 टूल हों, तो यह चुनना कठिन हो जाता है कि कौन-सा इस्तेमाल करना है।

एजेंट को सब कुछ सौंप देने के बजाय, अच्छी तरह डिज़ाइन किए गए टूल का एक छोटा समूह अक्सर बेहतर होता है।

Anthropic का मौजूदा इंजीनियरिंग मार्गदर्शन यह बात सीधे कहता है: टूल की गुणवत्ता और टूल की स्पष्ट सीमाएं एजेंट के प्रदर्शन को काफ़ी हद तक प्रभावित कर सकती हैं।

चरण 2: state तभी जोड़ें जब सिस्टम को उसकी ज़रूरत हो

मान लीजिए हमारा रिसर्च असिस्टेंट पाँच स्रोतों में खोज करता है।

अब उसे ये याद रखना होगा:

• वह पहले क्या खोज चुका है
• उसने कौन-से स्रोत स्वीकार किए
• किन दावों के लिए अभी प्रमाण चाहिए
• काम किस चरण तक पहुँचा है

यही state है।

State इस सवाल का जवाब देता है:

इस खास काम में अभी क्या हो रहा है?

Memory इससे जुड़ी है, लेकिन अलग है।

Memory कई कामों में उपयोगी जानकारी सहेज सकती है, जैसे उपयोगकर्ता के पसंदीदा स्रोत या बार-बार दोहराई जाने वाली रिसर्च प्राथमिकताएं।

शुरुआती लोगों के लिए इस अंतर को सरल रखना काफ़ी है:

State = इस काम को जारी रखने के लिए जो चाहिए।

Memory = इस काम से आगे भी उपयोगी जानकारी।

सिर्फ़ इसलिए स्थायी memory न जोड़ें कि कोई एजेंट framework उसे सपोर्ट करता है।

जानकारी तभी सहेजें जब सिस्टम को सचमुच उसकी ज़रूरत हो।

चरण 3: तय करें कि AI को क्या नियंत्रित करना चाहिए

यह सबसे महत्वपूर्ण डिज़ाइन निर्णयों में से एक है।

कुछ प्रक्रियाएं पूर्वानुमेय होती हैं।

उदाहरण के लिए:

खोज → स्रोत निकालना → संदर्भ सत्यापित करना → सारांश लिखना

अगर ये चरण हमेशा इसी क्रम में होने चाहिए, तो हर बार मॉडल को प्रक्रिया गढ़ने देने के बजाय सामान्य वर्कफ़्लो बेहतर हो सकता है।

दूसरी समस्याएं कम पूर्वानुमेय होती हैं।

कोई रिसर्च एजेंट पा सकता है कि एक स्रोत दूसरे स्रोत का खंडन करता है, और तय कर सकता है कि उसे एक और खोज करनी चाहिए।

यहीं मॉडल-संचालित निर्णय उपयोगी बनता है।

एक व्यावहारिक सिस्टम अक्सर दोनों को मिलाता है।

वर्कफ़्लो तय करता है कि क्या होना ही चाहिए।

एजेंट तय करता है कि किसमें विवेक की ज़रूरत है।

यह अंतर अनावश्यक स्वायत्तता से बचने में मदद करता है।

Microsoft का मौजूदा मार्गदर्शन भी ऐसी ही सिफ़ारिश करता है: जहाँ सरल पैटर्न काम करें वहाँ उन्हें इस्तेमाल करें, और वर्कफ़्लो वहाँ इस्तेमाल करें जहाँ स्पष्ट निष्पादन क्रम और checkpoints मायने रखते हैं।

चरण 4: विफलता को डिज़ाइन का हिस्सा बनाएं

डेमो आमतौर पर मान लेता है कि सब कुछ काम करेगा।

प्रोडक्शन में ऐसा नहीं होता।

सर्च API विफल हो सकती है।

कोई वेबसाइट उपलब्ध न हो सकती है।

कोई टूल अधूरी जानकारी लौटा सकता है।

मॉडल गलत टूल चुन सकता है।

लंबे समय तक चलने वाला कोई काम बीच में रुक सकता है।

एक भरोसेमंद agentic system को इस तरह के सवालों के जवाब चाहिए:

• क्या इस चरण को retry करना चाहिए?
• कितनी बार?
• क्या काम इस टूल के बिना जारी रह सकता है?
• क्या उसे आखिरी सफल checkpoint पर लौटना चाहिए?
• उसे कब रुकना चाहिए?
• उसे कब किसी इंसान से पूछना चाहिए?

हमारे रिसर्च असिस्टेंट के लिए, किसी स्रोत की खोज का विफल होना ज़रूरी नहीं कि पूरे काम को बर्बाद कर दे।

सिस्टम विफलता को दर्ज कर सकता है, दूसरा स्रोत आज़मा सकता है और आगे बढ़ सकता है।

लेकिन अगर वह किसी अहम दावे को सत्यापित नहीं कर पाता, तो उसे चुपचाप कोई दावा गढ़ना नहीं चाहिए।

यही विफलता से उबरने और विफलता को छिपाने के बीच का अंतर है।

चरण 5: नतीजे का मूल्यांकन करें

कई एजेंट ट्यूटोरियल यहीं आकर बहुत जल्दी खत्म हो जाते हैं।

एजेंट ने जवाब तैयार किया।

लेकिन क्या वह अच्छा था?

हमारे रिसर्च असिस्टेंट के लिए हम इनका मूल्यांकन कर सकते हैं:

• क्या स्रोत प्रासंगिक थे?
• क्या दावों को समर्थन मिला?
• क्या संदर्भ सही दावों से जुड़े थे?
• क्या उसने जहाँ उपलब्ध थे वहाँ प्रामाणिक स्रोत इस्तेमाल किए?
• क्या उसने कुछ गढ़ा?
• क्या उसने स्वीकार्य लागत और समय के भीतर काम पूरा किया?

यही evaluation है, जिसे eval भी कहते हैं।

पारंपरिक सॉफ़्टवेयर में अक्सर हमें एक सरल जवाब मिल जाता है:

टेस्ट पास / टेस्ट फ़ेल

Agentic systems कठिन होते हैं क्योंकि कुछ आउटपुट पूरी तरह निर्धारित (deterministic) नहीं होते।

इसका मतलब यह नहीं कि उन्हें परखा नहीं जा सकता।

इसका मतलब है कि हमें तय करना होगा कि अच्छा नतीजा कैसा दिखता है।

एजेंट मूल्यांकन पर Anthropic का मौजूदा मार्गदर्शन यह बात साफ़ कहता है: क्योंकि एजेंट कई चरणों में काम करते हैं, state बदलते हैं और बीच के नतीजों पर प्रतिक्रिया देते हैं, इसलिए evaluation को सिर्फ़ अंतिम वाक्य नहीं, बल्कि सिस्टम के व्यवहार को परखना चाहिए।

खासकर छात्रों के लिए, रिज़्यूमे में एक और framework जोड़ने से ज़्यादा उपयोगी है evaluation को जल्दी सीख लेना।

चरण 6: एजेंट को observable बनाएं

अगर अंतिम जवाब गलत है, तो आपको जानना होगा कि क्यों।

क्या मॉडल ने सवाल गलत समझा?

क्या उसने कोई खराब स्रोत चुना?

क्या कोई टूल विफल हुआ?

क्या उसे सही जानकारी मिली और फिर भी उसने गलत फ़ैसला किया?

इसके लिए observability चाहिए।

एक उपयोगी trace कुछ ऐसा दिखा सकता है:

लक्ष्य
→ मॉडल का निर्णय
→ चुना गया टूल
→ टूल का नतीजा
→ अगला निर्णय
→ अंतिम आउटपुट

Agentic systems के लिए AWS का मौजूदा मार्गदर्शन इससे आगे जाता है और टूल इनवोकेशन, वर्कफ़्लो निष्पादन, state और एजेंट के व्यवहार को प्रोडक्शन observability के महत्वपूर्ण हिस्से मानता है।

सीखने के उद्देश्य से यह सरल नियम याद रखें:

अगर कोई एजेंट कोई कार्रवाई कर सकता है, तो आप यह फिर से समझ पाने में सक्षम होने चाहिए कि क्या हुआ।

इसके बिना डीबगिंग अंदाज़ा लगाने का खेल बन जाती है।

चरण 7: तय करें कि इंसान कहाँ शामिल हों

इंसान की भागीदारी का मतलब यह नहीं कि एजेंट विफल रहा।

कभी-कभी इंसानी मंज़ूरी (human approval) सही डिज़ाइन का हिस्सा होती है।

हमारे रिसर्च असिस्टेंट को खोज और सारांश अपने आप करने की अनुमति हो सकती है।

लेकिन एक अलग एजेंट की कल्पना कीजिए जो यह कर सकता है:

• क्लाउड संसाधन हटाना
• पैसे ट्रांसफ़र करना
• बाहरी ईमेल भेजना
• रिफ़ंड मंज़ूर करना
• प्रोडक्शन कॉन्फ़िगरेशन बदलना

इन कार्रवाइयों के परिणाम होते हैं।

एक अच्छा डिज़ाइन एजेंट को कार्रवाई तैयार करने दे सकता है, लेकिन निष्पादन से पहले रुकवा सकता है।

एजेंट प्रस्ताव रखता है → इंसान मंज़ूरी देता है → सिस्टम निष्पादित करता है

अहम सवाल यह नहीं है:

क्या AI यह कर सकता है?

सवाल यह है:

क्या AI को बिना किसी और निर्णय-बिंदु के यह करने की अनुमति होनी चाहिए?

Agentic engineering का एक हिस्सा यह तय करना भी है कि स्वायत्तता कहाँ रुकनी चाहिए। यह रेखा खींचने का एक व्यावहारिक उदाहरण हमारे Perspective स्वायत्तता भरोसे के बराबर क्यों नहीं है में देखें।

चरण 8: और स्वायत्तता जोड़ने से पहले सुरक्षा जोड़ें

हर टूल क्षमता बढ़ाता है।

वह जोखिम भी बढ़ा सकता है।

अगर कोई एजेंट किसी डेटाबेस, क्लाउड अकाउंट, फ़ाइल सिस्टम या बाहरी API तक पहुँच सकता है, तो पूछें:

• वह किस identity का उपयोग कर रहा है?
• वह identity किस तक पहुँच सकती है?
• क्या उसके पास इस काम की ज़रूरत से ज़्यादा अनुमति है?
• क्या क्रेडेंशियल सुरक्षित हैं?
• क्या अविश्वसनीय सामग्री उसकी कार्रवाइयों को प्रभावित कर सकती है?
• क्या उच्च-प्रभाव वाले ऑपरेशन प्रतिबंधित हैं?

सिर्फ़ इसलिए एजेंट को व्यापक अधिकार न दें कि सीमित पहुँच कॉन्फ़िगर करने में ज़्यादा मेहनत लगती है।

सिद्धांत वही है जो पारंपरिक सिस्टम सुरक्षा का है:

सिस्टम को सिर्फ़ उतनी पहुँच दें जितनी काम के लिए ज़रूरी है।

Agentic systems इसे और अहम बना देते हैं, क्योंकि अगली अनुमत कार्रवाई कौन-सी हो, यह खुद मॉडल तय कर सकता है।

TechiesJournal में एजेंट identity और सुरक्षा पर अलग से कवरेज है, इसलिए हम यहाँ उस विषय को नहीं दोहराएंगे। लेकिन असली एजेंट बनाने वाले हर व्यक्ति को सुरक्षा को आर्किटेक्चर का हिस्सा मानना होगा, बाद में जोड़ी जाने वाली सुविधा नहीं।

MCP कहाँ फ़िट बैठता है?

जैसे-जैसे आपका एजेंट ज़्यादा बाहरी सिस्टम इस्तेमाल करने लगेगा, आपका सामना Model Context Protocol, यानी MCP से होगा। प्रोटोकॉल को खुद समझने के लिए हमारी गाइड MCP, A2A और WebMCP एजेंटों को कैसे जोड़ते हैं देखें।

MCP AI एप्लिकेशन के लिए टूल और बाहरी संसाधनों को खोजने और उनके साथ इंटरैक्ट करने का एक मानक तरीका देता है।

इससे कस्टम इंटीग्रेशन का काम कम हो सकता है।

लेकिन MCP उन बुनियादी बातों की जगह नहीं लेता जिन पर हमने चर्चा की।

आपको फिर भी इन पर सोचना होगा:

• कौन-से टूल होने चाहिए
• एजेंट किस तक पहुँच सकता है
• authentication
• अनुमतियाँ
• टूल की गुणवत्ता
• error handling
• evaluation

MCP को बुनियादी tool calling समझने के बाद सीखें।

नहीं तो हो सकता है कि आप प्रोटोकॉल को समझ लें, लेकिन उस सिस्टम को नहीं जो आप बनाना चाहते हैं।

कई एजेंटों की ज़रूरत कब पड़ती है?

कई ट्यूटोरियल जितना बताते हैं, उससे बाद में।

मान लीजिए हमारा रिसर्च असिस्टेंट अच्छा काम करता है, लेकिन हमें पता चलता है कि स्रोत सत्यापन के लिए सचमुच अलग प्रक्रिया चाहिए।

हम आगे चलकर ज़िम्मेदारियाँ अलग कर सकते हैं:

रिसर्च एजेंट → प्रमाण समीक्षक → लेखक

यह उपयोगी हो सकता है।

लेकिन multi-agent डिज़ाइन ये भी जोड़ता है:

• ज़्यादा मॉडल कॉल
• ज़्यादा state
• ज़्यादा समन्वय
• ज़्यादा latency
• ज़्यादा लागत
• विफलता के ज़्यादा रास्ते

Anthropic और Microsoft दोनों का मौजूदा मार्गदर्शन मूलतः एक ही आर्किटेक्चर संबंधी बात कहता है: समस्या हल करने वाला सबसे सरल पैटर्न इस्तेमाल करें, और orchestration या कई एजेंट तभी जोड़ें जब काम को सचमुच उनकी ज़रूरत हो।

इसलिए एक और एजेंट बनाने से पहले पूछें:

यह अतिरिक्त एजेंट ऐसी कौन-सी समस्या हल करता है जो एक एजेंट या सामान्य वर्कफ़्लो नहीं कर सकता?

अगर कोई स्पष्ट जवाब नहीं है, तो उसे न जोड़ें।

एजेंट से agentic system तक

हमारा शुरुआती रिसर्च असिस्टेंट सरल था:

सवाल → मॉडल → खोज → जवाब

अब एक ज़्यादा भरोसेमंद संस्करण अलग दिखता है:

लक्ष्य
↓
एजेंट
↓
टूल
↓
State
↓
प्रमाण
↓
Evaluation
↓
Checkpoint / ज़रूरत पड़ने पर इंसानी निर्णय
↓
नतीजा

इन सबके चारों ओर होते हैं:

सुरक्षा + observability + विफलता से उबरना

इस चित्र का सुलभ टेक्स्ट विकल्प

विकास के तीन चरण। एक सरल एजेंट टूल वाला मॉडल है। एक उपयोगी एप्लिकेशन टूल और state वाला मॉडल है। एक भरोसेमंद सिस्टम मॉडल, टूल और state को बनाए रखता है और उसमें evaluation, observability, विफलता से उबरना, सुरक्षा और इंसानी नियंत्रण जोड़ता है। जोड़े गए तत्वों पर प्लस का चिह्न और गर्म रंग की पृष्ठभूमि है, ताकि यह प्रगति केवल रंग पर निर्भर न रहे।

यही महत्वपूर्ण बदलाव है।

मॉडल अब भी अहम है।

लेकिन मॉडल अब पूरा एप्लिकेशन नहीं रहा।

इसीलिए agentic systems बनाना अब सिर्फ़ prompting कौशल के बजाय, तेज़ी से एक सॉफ़्टवेयर-इंजीनियरिंग अनुशासन बनता जा रहा है।

आगे क्या बनाना चाहिए?

अगर आप सीख रहे हैं, तो इस लेख की हर बात एक साथ लागू करने की कोशिश न करें।

परत-दर-परत बनाएं।

पहले: एक एजेंट और एक उपयोगी टूल।

फिर: state जोड़ें।

फिर: तय करें कि सफल नतीजा कैसा दिखता है।

फिर: tracing और विफलता प्रबंधन जोड़ें।

फिर: अगर एजेंट परिणामी कार्रवाइयाँ कर सकता है, तो इंसानी मंज़ूरी जोड़ें।

इसके बाद ही जटिल orchestration, MCP-भारी आर्किटेक्चर या कई एजेंटों को आज़माएं।

सबसे अच्छा सीखने वाला प्रोजेक्ट वह नहीं जिसमें सबसे ज़्यादा एजेंट हों।

वह है जिसमें आप समझा सकें:

एजेंट क्या हासिल करने की कोशिश कर रहा है,
वह क्या कर सकता है,
क्या गलत हो सकता है,
आप विफलता का पता कैसे लगाते हैं,
और अंतिम नतीजे पर भरोसा क्यों किया जाना चाहिए।

यही एजेंट डेमो बनाने और agentic system बनाने के बीच का अंतर है।

Building Agentic Systems श्रृंखला जारी रखें

भाग 1: पिछला। Building Agentic Systems: What Students and Working Professionals Should Learn Now। तय करें कि agentic systems आपके समय के लायक हैं या नहीं और आपकी भूमिका को इस कौशल की कितनी गहराई चाहिए, तो यहाँ से शुरू करें।

भाग 2: आप यहाँ हैं। Building Agentic Systems: From Your First Agent to a Reliable System। एक सरल टूल-उपयोग करने वाले एजेंट से state, evaluation, observability, सुरक्षा और विफलता से उबरने वाले सिस्टम तक की तकनीकी यात्रा को समझें।

भाग 3: अगला। Learning Agentic AI: Free Courses, Hands-On Labs and Certifications। हम AWS, Microsoft, Google, OpenAI, Anthropic और अन्य के मौजूदा सीखने के संसाधनों की तुलना करेंगे, और मुफ़्त प्रशिक्षण, कोर्स प्रमाणपत्र, हैंड्स-ऑन क्रेडेंशियल और पेशेवर प्रमाणनों को अलग-अलग समझाएंगे।

स्रोत और आगे का पठन

स्रोतों की समीक्षा: 2 अक्टूबर 2026।

1. Anthropic — Building Effective Agents। वर्कफ़्लो और एजेंट के बीच का अंतर समझने, यह जानने कि सरल आर्किटेक्चर को पहले क्यों रखना चाहिए, और अतिरिक्त स्वायत्तता कब उचित है, इसके लिए उपयोगी।
2. Anthropic — Writing Effective Tools for Agents। बताता है कि टूल की गुणवत्ता, स्पष्ट इंटरफ़ेस और evaluation एजेंट के प्रदर्शन के लिए क्यों मायने रखते हैं।
3. Anthropic — Demystifying Evals for AI Agents। इसका व्यावहारिक स्पष्टीकरण कि कई चरणों वाले एजेंट व्यवहार को व्यवस्थित evaluation की ज़रूरत क्यों है।
4. Microsoft — Agent Framework। मौजूदा दस्तावेज़ीकरण जो पहले एजेंट और टूल से शुरू होकर state, memory, वर्कफ़्लो, इंसानी भागीदारी, checkpoints और होस्टिंग तक जाता है।
5. AWS — Agentic AI Lens। Agentic systems में observability, state, resilience, सुरक्षा और संचालन व्यवहार को कवर करने वाला उपयोगी प्रोडक्शन मार्गदर्शन।
6. OpenAI — Agents SDK documentation। टूल, state, orchestration, guardrails, मानवीय समीक्षा, tracing और evaluations को कवर करने वाले मौजूदा डेवलपर संसाधन।