एजेंट हमेशा पहले दिन के नियुक्ति होते हैं। अब समय है कि हम इसके लिए डिज़ाइन करें।

2027 तक, 74% कंपनियों से उम्मीद है कि वे किसी न किसी रूप में एजेंटों का उपयोग करेंगी, जैसा कि हालिया Deloitte अध्ययन में बताया गया है। कई वर्षों से, हमने अपने ऐप्स, वेबसाइटों, ऑपरेटिंग सिस्टम और दस्तावेज़ों को नेविगेट करने के मानव अनुभव को बेहतर बनाने के लिए सॉफ़्टवेयर डिज़ाइन और निर्मित किया है। अब, उपयोगकर्ता बिल्कुल भी मानव नहीं है। यह बदलाव केवल डैशबोर्ड और मानव कार्यों के लिए डिज़ाइन किए गए नियंत्रित वर्कफ़्लो से आगे के व्यापक प्रभाव रखता है। हम ऐसे क्षण में हैं जहाँ हमें एजेंटों के संचालन वातावरण को डिज़ाइन करना होगा, जबकि भी मानव वर्कफ़्लो को इस तरह डिज़ाइन करना होगा कि एजेंट अनुभव को इन वातावरणों में प्रभावी रूप से मार्गदर्शन किया जा सके।  

हम अभी भी यह सीखने के शुरुआती चरण में हैं कि एजेंटों को लगातार और भरोसेमंद सफलता के लिए हमसे क्या चाहिए। प्रवृत्ति यह है कि एजेंट एकीकरण को केवल प्रॉम्प्टिंग या UI समस्या के रूप में देखा जाए। एक सही‑शासन वाला निष्पादन वातावरण डिज़ाइन करना हमारी संस्कृति के लिए नया क्षेत्र है। हालांकि, अच्छा डिज़ाइन और अच्छा प्रबंधन के मूल सिद्धांत नहीं बदले हैं: हमें एजेंटों को स्पष्ट संदर्भ, अस्पष्टता‑रहित दिशा, और स्पष्ट इरादा देना चाहिए।

संदर्भ: कोडिंग पहले क्यों आया

यदि हम चाहते हैं कि एजेंट लगातार वह स्तर प्रदान करें जिसकी हम अपेक्षा रखते हैं, तो संदर्भ शायद सबसे महत्वपूर्ण इनपुट है। सॉफ़्टवेयर विकास में लगभग सभी अन्य क्षेत्रों की तुलना में अधिक रिकॉर्डेड डेटा होता है: रेपो, API स्कीमा, सिस्टमों के बीच संबंध, कोड रिव्यू और समुदाय चर्चा। इसलिए यह समझ में आता है कि AI फ्रंटियर लैब्स ने कोडिंग से शुरुआत की। यह उन कुछ क्षेत्रों में से एक है जहाँ बहुत सारा संदर्भ पहले से ही लिखा हुआ है। 

लेकिन जैसा कि किसी भी सॉफ़्टवेयर टीम के नए नियुक्ति से पता चलता है, इतनी सारी डेटा होने के बावजूद, एजेंटों में वह संस्थागत स्मृति नहीं होगी जो अनलेखित नियमों में निहित होती है, जिन्हें कभी दस्तावेज़ित नहीं किया गया। यह अंतर व्यापक है: 43% डेवलपर्स चिंतित हैं कि AI टूल्स को उनके विशिष्ट प्रोजेक्ट या कोडबेस के बारे में पर्याप्त संदर्भ नहीं मिलता। अंतर्निहित ज्ञान रोज़मर्रा की प्रथाओं से लेकर, जैसे विशिष्ट कार्यों के लिए पसंदीदा लाइब्रेरी, से लेकर उच्च‑स्तरीय संचालन “भूत” तक फैला होता है: देर रात का हॉटफ़िक्स जो हमेशा के लिए बना रहता है, या एक खाली दिखने वाला डेटाबेस कॉलम जो गुप्त रूप से कस्टम राजस्व रिपोर्ट को आधार देता है। यह संदर्भ एक वरिष्ठ इंजीनियर के सिर में, हालिया स्लैक थ्रेड में, या कहीं नहीं रहता। यह शायद ही कोडबेस में ही मिलता है।  

यदि यह सॉफ़्टवेयर, जो सबसे अच्छी तरह से दस्तावेज़ित क्षेत्रों में से एक है, में सत्य है, तो यह समझना आसान है कि कई अन्य उद्योगों में एजेंट पहले दिन से ही प्रभावी रूप से काम करने में क्यों संघर्ष करते हैं। स्वास्थ्य‑सेवा और कानून में, वह संस्थागत ज्ञान जो दैनिक कार्य को आकार देता है, सीखकर और आंतरिकीकृत होकर रहता है। यह लोगों के अनुभव में रहता है, न कि औपचारिक दस्तावेज़ीकरण में। एक कानूनी एजेंट को किसी विशेष पार्टनर की पसंदीदा संरचना, स्वर या तर्क नहीं पता हो सकता, जबकि एक स्वास्थ्य‑सेवा एजेंट को स्थानीय वर्कफ़्लो और एस्केलेशन प्रैक्टिस नहीं समझ में आ सकती जो एक व्यस्त क्लिनिक क्लिनिशियन‑लीड ट्रायेज़ को सपोर्ट करती है। केवल दस्तावेज़ीकरण इस अंतर को नहीं भर सकता, क्योंकि चुनौती केवल सूचना तक पहुँच नहीं है; यह संदर्भ के हस्तांतरण की है। एजेंटों को सफल बनाने के लिए, हमें उन्हें उसी तरह ऑन‑बोर्ड करना होगा जैसे हम एक नए नियुक्ति को करते हैं।

दिशा: ऑस्मोसिस क्यों काम नहीं करता

एक नए सहयोगी को ऑन‑बोर्ड करना केवल उचित सामग्री और पहुँच प्रदान करने से अधिक माँगता है। जब हम अपने आसपास के लोगों की सफलता में निवेशित होते हैं, तो हम नई सामग्री और पहुँच के साथ क्या करना है, इस पर ठोस दिशा प्रदान करते हैं: अपेक्षाएँ, हम क्या हासिल करना चाहते हैं इसका स्पष्टता, और रास्ते में फीडबैक। मैं यह सोच‑धारा एजेंटों के लिए डिज़ाइन करने में भी लागू करता हूँ। मैं स्पष्ट, विशिष्ट दिशा देता हूँ (वर्तमान कार्य के सापेक्ष)। यह किसी भी सहयोगी पर लागू होता है, चाहे उनका कार्यकाल कुछ भी हो। फिर भी, नए नियुक्ति के परिदृश्य में, दिशा को आगे बढ़ना चाहिए, क्योंकि उनके पास अभी तक कोई संस्थागत संदर्भ नहीं होता।

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

एक नए नियुक्ति के साथ, आप समय के साथ प्रश्न, फीडबैक, और नई अंतर्दृष्टि के माध्यम से इस अंतर को पाट सकते हैं जो वह संगठन की प्रक्रियाओं और प्राथमिकताओं के बारे में सीखता है। वास्तविक कॉफ़ी मशीन की बातचीत या टीम लंच। एक एजेंट के साथ, आपको यह अंतर‑पेटिंग डिज़ाइन में ही बनाना होगा। यह शामिल कर सकता है: 

• एजेंट को एक संरचित संदर्भ विंडो देना जो स्थायी नियमों, कार्य‑विशिष्ट तथ्यों और प्रासंगिक इतिहास को अलग करता हो, बजाय इसके कि दस्तावेज़ों का ढेर उसकी गोद में फेंका जाए। 
• उसकी अनुमतियों और निर्णय सीमाओं को पहले से परिभाषित करना: वह स्वतंत्र रूप से क्या कर सकता है, क्या अनुमोदन की आवश्यकता है, और क्या उसे कभी एक्सेस नहीं करना चाहिए। 
• कई ठोस उदाहरणों को सीधे अनुभव में एम्बेड करना, ताकि एजेंट के पास यह स्पष्ट मॉडल हो कि काम कैसे किया जाना चाहिए।
• पहले हुए डेड‑एंड्स को साझा करना।

एक सही‑शासन वाले एजेंट वातावरण को डिज़ाइन करना मॉडल के लिए काम को आसान बनाने के बारे में नहीं है। यह मानव इंजीनियरिंग टीम को अदृश्य तकनीकी ऋण से बचाने के बारे में है। लेकिन एक अच्छी‑दिशा वाले एजेंट भी निर्देशों का पूर्णतः पालन कर सकता है और फिर भी मुख्य बिंदु को मिस कर सकता है। दिशा उसे क्या करना है बताती है, लेकिन यह नहीं बताती कि “अच्छा” कैसा दिखता है। वही अंतर है जहाँ इरादा आता है।

इरादा: एजेंट मध्य में क्यों भटकते हैं

यह याद रखना महत्वपूर्ण है कि एजेंट पैटर्न‑मैचिंग मशीनें हैं, जो विशाल मात्रा में ज्ञान पर प्रशिक्षित होती हैं और स्वाभाविक रूप से सांख्यिकीय औसत प्रदान करने की ओर झुकी होती हैं। स्पष्ट, स्पष्ट इरादा के बिना, वही औसत आउटपुट ठीक वही होगा जो एजेंट वापस लाएगा। यदि आप एजेंट को “एक उपयोगकर्ता प्रमाणीकरण एंडपॉइंट जोड़ें” कहते हैं, तो वह एक पाठ्यपुस्तक‑स्तर का Express रूट बुनियादी पासवर्ड हैशिंग के साथ उत्पन्न करेगा। यह काम करता है, लेकिन यह आपकी टीम की कस्टम ऑथ सर्विस को पूरी तरह अनदेखा कर देता है, आवश्यक टेलीमेट्री को छोड़ देता है, और आपके मानकीकृत त्रुटि फ़ॉर्मेट को तोड़ देता है। यह कागज़ पर एक पर्याप्त फीचर है, लेकिन संदर्भ के अनुसार, यह व्यावहारिक रूप से एक आर्किटेक्चरल बग बन जाता है। “बग” जैसे इस प्रकार के परिचय को कम करके नहीं आँका जा सकता।

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

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

जहाँ रूपक टूटता है

नया‑नियुक्ति फ्रेमिंग काम करता है, जब तक कि वह नहीं करता। एक मानव नियुक्ति के साथ, अनुभव से दक्षता आती है, जिससे निर्णय क्षमता आती है। आपका नया नियुक्ति “क्यों” को आंतरिकीकृत करता देखना, समय के साथ भरोसा बनाता है, और सामान्यतः यह संचयी होता है। एक एजेंट के पास इस अनुभव को जमा करने और संग्रहीत करने की कोई जगह नहीं होती।

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

एजेंट जिम्मेदारी डिज़ाइन पर निर्भर करती है

यदि जिम्मेदारी एजेंट में नहीं रह सकती, तो वह उसके चारों ओर के ढाँचे में रहनी चाहिए। यह वही तीन प्रश्नों पर घटता है जो मैं किसी भी नए नियुक्ति को काम सौंपने से पहले पूछता हूँ: उनके पास कौन‑सा संदर्भ है? मैंने उन्हें कौन‑सी दिशा दी है? मेरा वास्तविक इरादा क्या है?

अगली बार जब आप किसी एजेंट को कार्य सौंपें, तो केवल आउटपुट को नहीं देखें। पहले अपने इनपुट को जांचें। क्या आपने उसे वह संदर्भ दिया जो एक नया नियुक्ति पहले दिन को चाहिए था? क्या आपकी दिशा इतनी विशिष्ट थी कि शाब्दिक रूप से ली जाने पर भी टिक सके? क्या आपका इरादा इतना स्पष्ट था कि “मध्यम उत्तर” सबसे अच्छा नहीं रहा?

इस स्पष्ट मार्गदर्शन के साथ (बाइट में?), कुछ रोचक होता है: एक एजेंट को भरोसेमंद बनने के लिए लंबा रनवे नहीं चाहिए। वह संदर्भ, दिशा, और सत्यापन जिसे आप अग्र‑निर्मित करते हैं, यह निर्धारित करता है कि वह प्रत्येक कार्य पर कैसे काम करता है। एक नया नियुक्ति समय के साथ आपका भरोसा जीतता है; एक एजेंट को हर बार उस सिस्टम के माध्यम से भरोसा जीतना पड़ता है जिसे आपने डिज़ाइन किया है। जिम्मेदारी ऐसी चीज़ नहीं है जिसमें वह विकसित होता है, यह शुरुआत से ही निर्मित होती है। सवाल यह नहीं है कि आपका एजेंट कब अधिक जिम्मेदारी के लिए तैयार होगा। सवाल यह है कि क्या आपने इसे हर एक कार्य पर वह जिम्मेदारी अर्जित करने के लिए डिज़ाइन किया है।