चयनात्मक विशेषज्ञता: ऐसे एजेंट्स कैसे बनाएं जो प्रोडक्शन में टिके रहें

डेमो-स्तर का एजेंट बनाना पहले कभी इतना तेज़ नहीं था। एक सक्षम मॉडल जोड़ें, उसे कुछ टूल्स दें, और एक ही दोपहर में आपके पास ऐसा सिस्टम होता है जो मीटिंग बुक कर सकता है, जवाब का ड्राफ्ट बना सकता है या कमांड पर रिपोर्ट निकाल सकता है। परेशानी बाद में शुरू होती है। CX का VP, ऑपरेशंस हेड, प्लेटफ़ॉर्म लीड—यानी जो भी उस एजेंट को एंटरप्राइज़ स्तर पर चलाने के लिए ज़िम्मेदार हो—एक दीवार से टकराता है। डेमो में काम करने वाली चीज़, असली वॉल्यूम और वास्तविक जोखिम आते ही धीमी और अनिश्चित हो जाती है। आमतौर पर नीचे का प्लेटफ़ॉर्म फेल नहीं हुआ होता। उसके ऊपर की आर्किटेक्चर फेल हुई होती है।

रुकावट: एक एजेंट सब कुछ कर रहा है

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

यही सोच एक रुकावट पैदा करती है। जब एक ही एजेंट व्यापक दायरे में प्लानिंग, एक्ज़ीक्यूशन, याद रखने और समीक्षा करने की ज़िम्मेदारी लेता है, तो कई चीज़ें एक साथ बिगड़ने लगती हैं।

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

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

विनियमित उद्योग में, यह सिर्फ़ खराब अनुभव नहीं है—यह जवाबदेही से जुड़ी एक कंप्लायंस घटना है। यही एक वजह है कि प्रोडक्शन डिप्लॉयमेंट के लिए एजेंट का बीमायोग्य होना ज़रूरी शर्त बनता जा रहा है और हमने ElevenAgents को पहला कन्वर्सेशनल AI प्लेटफ़ॉर्म बनाया है, जो AIUC के ज़रिए AI बीमा के लिए पात्र है।

ध्यान दें कि वास्तव में क्या टूटा। एजेंट बातचीत में खराब नहीं था। समस्या यह थी कि वह हर ज़िम्मेदारी अकेले संभाल रहा था और किसी बात को समझने और उस पर कार्रवाई करने के बीच कोई चेकपॉइंट नहीं था। समाधान न तो कम महत्वाकांक्षा है, न ही शांत एजेंट। समाधान है सही संरचना।

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

मानसिक मॉडल: विभाग, हर फैसला लेने वाला CEO नहीं

सोचिए कि कोई कंपनी कैसे बढ़ती है। अगर CEO खुद इंजीनियरिंग, मार्केटिंग और HR से जुड़े हर फैसले ले, तो कंपनी ठप हो जाएगी। इसका हल ज़्यादा बुद्धिमान CEO को नियुक्त करना नहीं है। हल है स्पष्ट दायरे वाली विशेषज्ञ टीम्स बनाना।

यही तर्क AI सिस्टम्स पर भी लागू होता है। एक विशाल एजेंट के बजाय, आप सिस्टम को सीमित ज़िम्मेदारियों वाले विशेषज्ञ एजेंट्स में बांट सकते हैं। एक एजेंट डेटा निकालता है। एक कोड लिखता है। एक सिर्फ़ तथ्य-जांच करता है। हर एजेंट का फोकस संकरा होता है, जिससे उसके फैसले सस्ते, तेज़ और भरोसेमंद बनते हैं।

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

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

वास्तविक समझौते

मल्टी-एजेंट कोई मुफ़्त जीत नहीं है। इस आर्किटेक्चर का मूल्यांकन करने वाले किसी भी टेक्निकल लीडर को इसे अपनाने से पहले कोऑर्डिनेशन की लागत परखनी चाहिए—और वह ऐसा करेगा भी। सबसे अहम चेतावनी यह है।

सबसे आम फेल्योर मोड कॉन्टेक्स्ट फ्रैगमेंटेशन है। जब आप किसी टास्क को ऐसे एजेंट्स में बांटते हैं जो पूरा कॉन्टेक्स्ट साझा नहीं करते, तो हर एजेंट अधूरी जानकारी के आधार पर काम करता है और उनके फैसले ऐसे टकरा सकते हैं जिन्हें कोऑर्डिनेटर सुलझा नहीं सकता।

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

समाधान और एजेंट जोड़ना नहीं है। बातचीत को एकसाथ रखें और किसी प्रतिबद्धता से पहले उसे टूल के रूप में कंप्लायंस नियम देखने दें, ताकि कोई बात ज़ोर से कहे जाने से पहले नियम और ऑफ़र का मिलान हो जाए। यह एक डिज़ाइन विकल्प है और सक्षम प्लेटफ़ॉर्म इसे आसान बनाता है।

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

ROI को वास्तव में क्या आगे बढ़ाता है

एजेंट्स से वास्तविक रिटर्न पाने वाली टीम्स आमतौर पर वे नहीं होतीं जो सबसे समझदार एक मॉडल चुनकर उससे सारा काम करने की उम्मीद करती हैं। वे ऐसी टीम्स होती हैं जो सोच-समझकर आर्किटेक्चर से जुड़े फैसले लेती हैं कि कहां विशेषज्ञता चाहिए, कहां चीज़ों को एक निरंतर कॉन्टेक्स्ट में रखना है और ज़रूरत पड़ने पर एजेंट्स को कैसे कोऑर्डिनेट करना है।

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

सुझाव

आने वाले प्रोजेक्ट के लिए पहला कदम आर्किटेक्चर चुनना नहीं है। पहला कदम काम को मैप करना है।

सिस्टम को वास्तव में जिन खास क्षमताओं की ज़रूरत है, उनकी सूची बनाएं। चिह्नित करें कि कौन-से हिस्से सचमुच स्वतंत्र हैं और कौन-से घनिष्ठ रूप से जुड़े हुए हैं। पहचानें कि कहां अलग कॉन्टेक्स्ट एक सुविधा है, समस्या नहीं—जैसे तथ्य-जांच का ऐसा चरण जिसे आप मुख्य रीजनिंग थ्रेड से अलग रखना चाहते हैं। फिर, और सिर्फ़ तभी, तय करें कि ज़िम्मेदारियों को अलग एजेंट्स में कहां बांटना है।

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

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

ऐसा करें, और आपको उस कोऑर्डिनेशन लागत के बिना विशेषज्ञता के फायदे मिलते हैं जिसकी आपको ज़रूरत ही नहीं थी। अनुमानित व्यवहार, सीमित दायरे वाली विफलताएं और ऐसा सिस्टम जिसकी जटिलता आपने जानबूझकर चुनी है, प्रोडक्शन में जाकर खोजी नहीं है। इस तरह इस्तेमाल करने पर एजेंट प्लेटफ़ॉर्म ऐसा डेमो नहीं है जो स्केल होने पर डगमगाने लगे। यह ऐसा इन्फ्रास्ट्रक्चर है जो हर हिस्से को स्पष्ट काम देने पर और स्थिर होता जाता है। ElevenAgents को हमने इसी के लिए बनाया है।