ElevenAgent के ऑर्केस्ट्रेशन इंजन की गहराई से समझ

ElevenAgents को लो-लेटेंसी ऑर्केस्ट्रेशन इंजन से पावर मिलता है, जिसे खासतौर पर रियल-टाइम बातचीत के लिए बनाया गया है और इसमें 100ms से भी कम ओवरहेड जुड़ता है। इस आर्किटेक्चर में ElevenLabs की रिसर्च और OpenAI, Google, Anthropic जैसे लीडिंग प्रोवाइडर्स के फ्रंटियर LLMs के साथ-साथ ElevenLabs द्वारा होस्ट किए गए चुनिंदा ओपन-सोर्स मॉडल्स को जोड़ा गया है। जवाब देने की प्रक्रिया के अलग-अलग स्टेज पर कई मॉडल्स का इस्तेमाल करके, एजेंट बातचीत को तेज़ और कॉन्टेक्स्ट के हिसाब से सही बनाता है। हर मॉडल की ताकत को सही समय पर इस्तेमाल करके, हम अलग-अलग एंटरप्राइज़ टास्क्स और कन्वर्सेशनल सिचुएशंस में भरोसेमंद, स्केलेबल परफॉर्मेंस पाते हैं, साथ ही इंटेलिजेंस, स्पीड और लागत का सही संतुलन भी रखते हैं।

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

इंडिपेंडेंट एजेंट

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

ElevenLabs में इंडिपेंडेंट एजेंट्स के लिए ये समझना जरूरी है कि वे कैसे:

• इफेक्टिव जेनरेशन रिक्वेस्ट बनाते हैं
• जरूरी डॉक्युमेंट्स निकालते और जोड़ते हैं
• एजेंट के जवाब के लिए टूल कॉल्स जनरेट और एक्सीक्यूट करते हैं
• इवैल्यूएशन और डेटा कलेक्शन के लिए रिजल्ट्स आउटपुट करते हैं

बातचीत का कॉन्टेक्स्ट बनाना 

किसी ग्राहक और ElevenLabs एजेंट के बीच बातचीत कई टर्न्स में होती है, जहां हर टर्न में दोनों तरफ से मैसेज एक्सचेंज होते हैं। एजेंट और यूज़र के इन बारी-बारी से आए मैसेजेस की लिस्ट से ही बातचीत का कॉन्टेक्स्ट बनता है। हर टर्न में, LLM को जेनरेशन रिक्वेस्ट मिलती है जिसमें एजेंट और यूज़र के बारी-बारी से आए मैसेजेस होते हैं, जो पिछले टर्न से एक ज्यादा होते हैं। ये मैसेजेस हमेशा एक सिस्टम मैसेज से शुरू होते हैं, जो एजेंट का सिस्टम प्रॉम्प्ट होता है।

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

हालांकि, रिट्रीवल सिर्फ एक तरीका है जिससे एजेंट्स बाहरी सिस्टम्स से इंटरैक्ट करते हैं।

टूल्स का इस्तेमाल करके जानकारी निकालना और एक्शन लेना

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

• lookup_order के लिए टूल डिस्क्रिप्शनlookup_order: “ऑर्डर ID से ग्राहक के ऑर्डर की डिटेल्स निकालता है। ऑर्डर स्टेटस, खरीदी गई चीजें, शिपिंग एड्रेस और ट्रैकिंग नंबर रिटर्न करता है।”
• सिस्टम प्रॉम्प्ट इंस्ट्रक्शन: “ग्राहक की पहचान वेरिफाई करने के बाद, lookup_order टूल से उनका ऑर्डर डिटेल्स निकालें।”

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

• Webhook टूल्स जो बाहरी APIs को कॉल करते हैं।
• Client टूल्स जो टूल रिक्वेस्ट्स को इवेंट्स के रूप में कन्वर्सेशन वेब्सॉकेट के ज़रिए भेजते हैं।
• System टूल्स जो कॉल ट्रांसफर जैसी बिल्ट-इन एक्शन के लिए होते हैं।
• MCP टूल्स जो Model Context Protocol सर्वर्स से कनेक्ट होते हैं।

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

जहां ये तरीका बताता है कि टूल्स एजेंट की सोच में कैसे जुड़ते हैं, वहीं इनके चलने का समय भी सेट किया जा सकता है। टूल्स तीन तरह के एक्जीक्यूशन मोड्स में चल सकते हैं, हर एक अलग कन्वर्सेशनल जरूरत के लिए। Immediate Mode में, टूल जैसे ही LLM रिक्वेस्ट करता है, वैसे ही चल जाता है। यह तेज़ लुकअप्स के लिए डिफॉल्ट है, जैसे ऑर्डर स्टेटस चेक करना। अगर प्री-टूल स्पीच के साथ इस्तेमाल करें, तो एजेंट पहले छोटा सा जवाब देता है जैसे “मैं अभी चेक करता हूँ” और यूज़र को भेज देता है, जबकि टूल बैकग्राउंड में चलता रहता है, जिससे बातचीत में रुकावट नहीं आती। स्लो टूल्स के लिए, प्लेटफ़ॉर्म खुद ही इन फिलर मैसेजेस को वेट टाइम के हिसाब से बढ़ा देता है। Post-Tool Speech Mode में, टूल तब तक नहीं चलता जब तक एजेंट बोलना खत्म नहीं कर देता। यह असली दुनिया के एक्शन के लिए जरूरी है, जैसे कॉल ट्रांसफर करना, सेशन खत्म करना या पेमेंट सबमिट करना। यूज़र को पूरा कॉन्टेक्स्ट सुनाई देता है, जैसे “अब मैं आपको बिलिंग में ट्रांसफर कर रहा हूँ” और एक्शन से पहले रुकने का मौका मिलता है। Async Mode में टूल पूरी तरह बैकग्राउंड में चलता है, बिना बातचीत रोके। यह ईमेल भेजने, बाहरी वर्कफ़्लो ट्रिगर करने या डेटा लॉग करने जैसे कामों के लिए सही है, जहां एजेंट को रिजल्ट अपने जवाब में इस्तेमाल नहीं करना होता।

एक्जीक्यूशन और ऑर्केस्ट्रेशन सेट होने के बाद, अगला स्टेप है परफॉर्मेंस को मापना।

परफॉर्मेंस मापना

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

इवैल्यूएशन क्राइटेरिया

1. हर क्राइटेरिया में एक साफ लक्ष्य: एक वाक्य या छोटा बुलेट कई लक्ष्यों से बेहतर है।
2. ट्रांसक्रिप्ट पर आधारित और ऑब्जर्वेबल: लक्ष्य ऐसे लिखें कि सफलता/असफलता ट्रांसक्रिप्ट से तय हो सके (क्या कहा गया, एजेंट ने क्या किया, यूज़र ने क्या पूछा)। ऐसे लक्ष्य न रखें जिनके लिए बाहरी जानकारी चाहिए जो LLM के पास नहीं है।
3. साफ-साफ सफलता/असफलता/अनजान रिजल्ट: LLM को पहले से पता है कि सफल तभी मार्क करना है जब लक्ष्य पूरा हो, फेल तब जब न हो, और अनजान तब जब ट्रांसक्रिप्ट से पता न चले। इसलिए लक्ष्य ऐसे लिखें कि “पूरा हुआ” और “नहीं हुआ” साफ हो; अगर अस्पष्ट होगा तो मॉडल अनजान या गलत क्लासिफिकेशन कर सकता है।
4. संक्षिप्त रखें: कई बार एक साथ कई इवैल्यूएशन क्राइटेरिया भेजे जा सकते हैं। लंबे क्राइटेरिया शोर बढ़ा सकते हैं और गलतियां करवा सकते हैं।
5. भाषा मायने रखती है: LLM जो भी तर्क देगा, वह उसी भाषा में देगा जिसमें क्राइटेरिया डिस्क्रिप्शन लिखा है, इसलिए यह ध्यान में रखें।

डेटा कलेक्शन

1. क्या निकालना है, साफ-साफ बताएं: डिस्क्रिप्शन ही LLM के लिए मुख्य संकेत है। बताएं कि फील्ड का मतलब क्या है, किस स्थिति में सेट करना है, और जब साफ न हो तो क्या करना है (जैसे “अगर ग्राहक ने पसंदीदा तारीख नहीं बताई तो null छोड़ दें”)।
2. टाइप से मेल खाए: LLM जो वैल्यू देगा, वह हमेशा डेटा कलेक्शन पॉइंट के टाइप से मेल खाएगी (जैसे boolean, string, integer आदि)। डिस्क्रिप्शन भी उसी के हिसाब से होनी चाहिए। उदाहरण के लिए, integer के लिए “मांगी गई चीजों की संख्या निकालें”, और boolean के लिए “ग्राहक ने ऑफर मंजूर किया या नहीं - हां/नहीं”।
3. जहां संभव हो, enums का इस्तेमाल करें: string टाइप के लिए, अगर वैल्यूज़ फिक्स हैं तो स्कीमा में enum डालें; इससे मॉडल सीमित रहेगा और गलत आउटपुट कम होंगे।
4. हर आइटम में एक ही चीज निकालें: एक आइटम की डिस्क्रिप्शन में कई अलग-अलग बातें न डालें; हर कॉल के लिए एक साफ टारगेट रखें।
5. डिस्क्रिप्शन छोटी रखें: डिस्क्रिप्शन कुछ वाक्य हो सकती है; लंबे पैराग्राफ की जरूरत नहीं। ट्रांसक्रिप्ट पहले से यूज़र मैसेज में है, तो स्कीमा + छोटी डिस्क्रिप्शन काफी है।

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

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

वर्कफ़्लो

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

• सिस्टम प्रॉम्प्ट्स और सब-एजेंट्स के कन्वर्सेशनल गोल्स कैसे इंटरैक्ट करते हैं।
• ग्राफ में अलग-अलग ट्रांजिशन पॉइंट्स से कैसे गुज़रना तय होता है।

स्पेशलाइज्ड कन्वर्सेशनल गोल्स

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

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

इस कंट्रोल को संभव बनाने वाले मुख्य तरीकों में से एक है, सब-एजेंट्स के बीच ट्रांजिशन कैसे होते हैं।

LLM कंडीशन्स से वर्कफ़्लो ट्रांजिशन को ड्राइव करना

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

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

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

सुरक्षा और सेफ्टी

जहां ज्यादा सुरक्षा और सेफ्टी की जरूरत हो, ग्राहक ऑर्केस्ट्रेटर के अतिरिक्त हिस्सों पर भरोसा कर सकते हैं।

गार्डरेल्स

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

कंप्लायंट डेटा मैनेजमेंट

कभी-कभी स्पीकर्स एजेंट के साथ संवेदनशील जानकारी शेयर कर सकते हैं, जिस पर सख्त स्टोरेज और प्रोसेसिंग नियम लागू होते हैं, जैसे मेडिकल डेटा जिसे HIPAA-कंप्लायंट हैंडलिंग चाहिए। ऐसे यूज़ केस के लिए हम Agent या Workspace लेवल पर Zero Retention Mode (ZRM) ऑफर करते हैं। जब यह ऑन होता है, तो सारी कॉल डेटा सिर्फ मेमोरी में प्रोसेस होती है और कभी भी परमानेंट स्टोरेज में नहीं जाती। कॉल और प्रोसेसिंग खत्म होते ही ElevenLabs के पास कोई जानकारी नहीं रहती। नतीजतन, ट्रांसक्रिप्ट, ऑडियो रिकॉर्डिंग और एनालिसिस आउटपुट्स Agents डैशबोर्ड में उपलब्ध नहीं होते, और यह पॉलिसी कस्टमर-फेसिंग सिस्टम्स और इंटरनल लॉग्स दोनों पर लागू होती है। हालांकि डेटा सेव नहीं होता, कॉल के दौरान प्रोसेस होता है, और कोई भी पोस्ट-कॉल वेबहुक आउटपुट्स पा सकता है, जिससे ग्राहक जरूरत हो तो अपने सिस्टम में ट्रांसक्रिप्ट या एनालिसिस रिजल्ट सेव कर सकते हैं।

जब ZRM एक्टिव होता है, तो हम यह भी सुनिश्चित करते हैं कि सब-प्रोसेसर्स डेटा सेव न करें, इसके लिए उपलब्ध LLMs को उन्हीं प्रोवाइडर्स तक सीमित किया जाता है जिनके साथ कॉन्ट्रैक्ट में ट्रेनिंग या डेटा रिटेंशन पर रोक है; अभी इसमें Google Gemini और Anthropic Claude के मॉडल्स शामिल हैं। ग्राहक चाहें तो ZRM के तहत कोई और LLM इस्तेमाल कर सकते हैं, बशर्ते वे उस प्रोवाइडर के साथ खुद का एग्रीमेंट साइन करें और API कीज़ के ज़रिए कस्टम LLM सेट करें। क्योंकि इससे डेटा हैंडलिंग हमारे स्टैंडर्ड ट्रस्ट बाउंड्री से बाहर जाती है, हमारी सेफ्टी टीम को यूज़ केस मैन्युअली रिव्यू और अप्रूव करना होता है। ZRM से ElevenLabs और उसके सब-प्रोसेसर्स कॉल डेटा सेव नहीं करते, लेकिन ग्राहक को यह सुनिश्चित करना होता है कि उनके एजेंट द्वारा इस्तेमाल किए गए कोई भी बाहरी टूल्स या वेबहुक्स लागू रिटेंशन और रेगुलेटरी नियमों का पालन करें।

आगे की राह

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

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