आवाज़ एक ऐसा फीचर बन गई है जिसे हर AI एजेंट प्लेटफॉर्म जल्द से जल्द लॉन्च करने की होड़ में है। सबसे स्पष्ट कदम इसे एक स्टैंडअलोन चैनल के रूप में बनाना है, जो आपके वेब ऐप, आपके CLI टूल, या आपके Telegram बॉट के साथ चलता है। यह सहज लगता है। आप आवाज़ देखते हैं, और एक वॉइस इंटरफ़ेस बना देते हैं। लेकिन यह सहज ज्ञान एक कमज़ोर आर्किटेक्चर बनाता है। यह काम को दोहराता है, आपके लॉग्स को खराब करता है, और धीरे-धीरे आपके प्रोजेक्ट के कॉन्टेक्स्ट को बिगाड़ देता है।
APC और APX में, हमने एक अलग रास्ता चुना। आवाज़ एक चैनल नहीं है। यह एक मोड (mode) है। यह किसी सरफेस को बदलने के बजाय उसके ऊपर काम करता है। इस अंतर को सही ढंग से समझना ही सिस्टम को बिखरने से बचाता है।
गलत एब्स्ट्रैक्शन
जब आप आवाज़ को एक अलग चैनल मानते हैं, तो आप परोक्ष रूप से यह मान लेते हैं कि एजेंट से बात करना टाइप करने से मौलिक रूप से अलग बातचीत है। इंजीनियरिंग टीमें इसके जवाब में कोडबेस को विभाजित कर देती हैं। अचानक एक CLI चैनल और एक अलग voice-CLI चैनल आ जाता है। एक वेब चैनल और एक समानांतर voice-web चैनल आ जाता है। प्रत्येक के लिए अपने स्वयं के प्रॉम्प्ट वेरिएशन, फॉर्मेटिंग नियम और कॉन्टेक्स्ट हैंडलिंग लॉजिक की आवश्यकता होती है।
यहीं से गड़बड़ी शुरू होती है। अब एजेंट के व्यवहार में किए गए किसी भी बदलाव को कई प्रॉम्प्ट ट्रीज़ में कॉपी करना पड़ता है। यदि टीम एक भी सरफेस को भूल जाती है, तो अनुभव खंडित हो जाता है। उपयोगकर्ताओं को टेक्स्ट पर एक टोन मिलता है और बोलने पर थोड़ा अलग व्यक्तित्व। समय के साथ, ये छोटी-छोटी विसंगतियां 'सिस्टम ड्रिफ्ट' में बदल जाती हैं। पोर्टेबल कॉन्टेक्स्ट लेयर पोर्टेबल नहीं रह जाती क्योंकि उसे एक ब्रांच में वोकल डिलीवरी और दूसरी में साइलेंट टेक्स्ट का ध्यान रखना पड़ता है। एब्स्ट्रैक्शन लीक हो जाता है, और आपका कभी एक जैसा रहने वाला प्रोजेक्ट डेफिनेशन चैनल-विशिष्ट हैक्स (hacks) के संग्रह में बदल जाता है।
कॉन्टेक्स्ट को रनटाइम से अलग करना
इसे रोकने के लिए, हम ज़िम्मेदारियों को दो परतों (layers) के बीच विभाजित करते हैं जो पूरी तरह से अलग रहती हैं।
APC प्रोजेक्ट कॉन्टेक्स्ट को संभालता है। यह उन एजेंट्स, नियमों और स्किल्स को परिभाषित करता है जो एक प्रोजेक्ट बनाते हैं। इसे सिस्टम के स्थिर अर्थ (stable meaning) के रूप में सोचें। यह संरचनात्मक प्रश्नों के उत्तर देता है। यह एजेंट क्या जानता है? इसे क्या करने की अनुमति है? यह किन टूल्स को कॉल कर सकता है? APC को इस बारे में पूरी तरह से तटस्थ (agnostic) रहना चाहिए कि उत्तर स्क्रीन पर दिखाया जा रहा है, चैट API के माध्यम से भेजा जा रहा है, या स्पीकर के माध्यम से सुनाया जा रहा है।
APX रनटाइम लेयर को संभालता है। यह उन सरफेस को मैनेज करता है जिन्हें आप वास्तव में छूते हैं: CLI, वेब एप्लिकेशन, डेस्कटॉप इंटरफ़ेस, Telegram बॉट। जब कोई उपयोगकर्ता अनुरोध भेजता है, तो APX चुनता है कि प्रतिक्रिया कहाँ और कैसे प्रस्तुत की जाए। उत्तर को पढ़ने के लिए फॉर्मेट करना है या बोलने के लिए ऑप्टिमाइज़ करना है, यह निर्णय रनटाइम का विषय है। यह APX में होना चाहिए, APC में नहीं।
इस अलगाव का मतलब है कि APC में परिभाषित प्रोजेक्ट तब भी बरकरार रहता है चाहे APX कितने भी सरफेस क्यों न पेश करे। कॉन्ट्रैक्ट नहीं बदलता। केवल प्रेजेंटेशन लेयर बदलती है।
मोड वास्तव में कैसे काम करते हैं
हमारे कार्यान्वयन (implementation) में, Telegram, CLI और वेब ऐप जैसे सरफेस 'चैनल' हैं। एक चैनल आपको बताता है कि बातचीत कहाँ हुई। आवाज़ को चैनल मेटाडेटा के माध्यम से एक 'मोड' के रूप में लेयर किया जाता है। एक मोड आपको बताता है कि प्रतिक्रिया को कैसा व्यवहार करना चाहिए।
प्रॉम्प्ट बिल्डर इस सीमा का सम्मान करता है। यह APC में प्रोजेक्ट कॉन्टेक्स्ट से जानकारी लेता है, फिर चैनल मेटाडेटा की जांच करता है। यदि डेस्कटॉप सरफेस वॉइस मोड में चल रहा है, तो बिल्डर केवल उसी क्षण लक्षित निर्देश जोड़ता है। शायद यह मॉडल को छोटे वाक्यों, सिंथेसिस के लिए स्पष्ट विराम चिह्नों, या बोले जाने वाले नंबरों के नियमों की ओर निर्देशित करे। यदि वही डेस्कटॉप सरफेस टेक्स्ट मोड में चल रहा है, तो वे वोकल निर्देश प्रॉम्प्ट में कभी नहीं आते।
परिणाम प्रति सरफेस एक ही प्रॉम्प्ट ट्री है। कोई अलग voice-desktop ब्रांच नहीं है। कोई whisper-web वेरिएंट नहीं है। मॉडिफायर केवल तभी लागू होता है जब रनटाइम इसकी मांग करता है, और वह भी अंतिम आवश्यक क्षण में। मुख्य प्रॉम्प्ट स्थिर रहता है।
आपको क्या लाभ मिलता है
यह आर्किटेक्चर तीन ठोस तरीकों से फायदेमंद है।
कम रखरखाव लागत। यदि आवाज़ अपना खुद का चैनल होती, तो प्रत्येक सरफेस को एक जुड़वां (twin) की आवश्यकता होती। आपको एक CLI चैनल और एक voice-CLI चैनल, एक Telegram चैनल और एक voice-Telegram चैनल, इत्यादि का रखरखाव करना पड़ता। हर बार जब आप सिस्टम प्रॉम्प्ट को एडजस्ट करते, फॉर्मेटिंग बग को ठीक करते, या स्किल डिस्क्रिप्शन को रिफाइन करते, तो आपको उस बदलाव को दोनों ट्रीज़ में फैलाना पड़ता। यदि एक भी छूट गया, तो उपयोगकर्ता अंतर को नोटिस कर लेंगे। एक मोड का उपयोग करके, आप प्रति सरफेस एक ही प्रॉम्प्ट ट्री रखते हैं। आवाज़ रास्ते के मोड़ के बजाय एक कंडीशनल ओवरले बन जाती है, जिससे इंटरैक्ट करने के नए तरीके जोड़ने पर भी आपका वर्कलोड लीनियर बना रहता है।
सटीक लॉगिंग। चैनल रिकॉर्ड करते हैं कि इंटरैक्शन कहाँ हुआ। मोड्स रिकॉर्ड करते हैं कि रिप्लाई कैसे दिया गया। डेस्कटॉप इंटरैक्शन डेस्कटॉप इंटरैक्शन ही रहता है, चाहे यूजर ने उसे पढ़ा हो या सुना हो। जब आपकी टीम किसी बग को ट्रैक करती है या एनालिटिक्स की समीक्षा करती है, तो उन्हें "desktop-voice" को "desktop-text" के विरुद्ध इस तरह मेल करने की आवश्यकता नहीं होती जैसे कि वे अलग-अलग प्रोडक्ट सर्फेस हों। चैनल आइडेंटिफायर साफ रहता है, और मोड फ्लैग मेटाडेटा में उसके ठीक बगल में रहता है। आपके लॉग्स सटीक रहते हैं, और डीबगिंग सरल बनी रहती है क्योंकि लोकेशन और व्यवहार आपस में उलझे हुए नहीं होते हैं।
साफ प्रोजेक्ट कॉन्टेक्स्ट। APC कॉन्ट्रैक्ट को परिभाषित करता है। इसे इस बात से फर्क नहीं पड़ना चाहिए कि रिप्लाई बोला गया है, फुसफुसाया गया है, या मोनोस्पेस फॉन्ट में रेंडर किया गया है। ये रनटाइम संबंधी चिंताएं हैं। वॉइस फॉर्मेटिंग को APX के अंदर रखकर, हम APC की पोर्टेबिलिटी बनाए रखते हैं। आप एक APC प्रोजेक्ट डेफिनेशन को उठाकर पूरी तरह से नए रनटाइम एनवायरनमेंट में डाल सकते हैं, बिना वॉइस-विशिष्ट फॉर्मेटिंग धारणाओं या स्पीच-ऑप्टिमाइज़ेशन के अनावश्यक बोझ को साथ खींचे। सीमा बनी रहती है, और प्रोजेक्ट का अर्थ स्थिर रहता है।
डेस्कटॉप पर प्रमाण
हमारा अपना डेस्कटॉप पाथ दैनिक उपयोग में इसे प्रदर्शित करता है। डेस्कटॉप ही सरफेस है। जब कोई यूजर स्पीच इनेबल करता है, तो सिस्टम उसी डेस्कटॉप सरफेस को वॉइस मोड में चलाता है। क्योंकि वॉइस मोड लेयर में रहता है, डेस्कटॉप चैनल अपना पूरा कॉन्टेक्स्ट और व्यवहार बनाए रखता है। यह अलग नियमों वाला कोई अलग प्रोडक्ट नहीं बन जाता। प्रॉम्प्ट बिल्डर बस फ्लैग को नोटिस करता है और केवल आवश्यकता होने पर ही वॉइस निर्देश जोड़ता है। जब यूजर वापस टेक्स्ट पर स्विच करता है, तो वे निर्देश पूरी तरह से गायब हो जाते हैं। अंतर्निहित प्रोजेक्ट कॉन्टेक्स्ट कभी नहीं बदला। डेस्कटॉप हमेशा डेस्कटॉप ही रहा।
असली निष्कर्ष
मूल विचार सरल है। APC स्थिर प्रोजेक्ट अर्थ का वर्णन करता है। APX रनटाइम निष्पादन का वर्णन करता है। वॉइस किसी सरफेस पर एक मॉडिफायर है, उसका विकल्प नहीं। इसे इसी तरह मानें, और आपके प्रॉम्प्ट्स छोटे रहेंगे। आपके लॉग्स स्पष्ट रहेंगे। आपके