व्हॉइस (Voice) हे असे फीचर बनले आहे ज्याच्या मागे प्रत्येक AI एजंट प्लॅटफॉर्म धावत आहे. याचा सर्वात सोपा मार्ग म्हणजे ते एक स्वतंत्र चॅनेल (standalone channel) म्हणून तयार करणे, जे तुमच्या वेब ॲप, CLI टूल किंवा टेलिग्राम बॉटच्या बाजूला असेल. हे सहज वाटते. तुम्हाला व्हॉइस दिसते, आणि तुम्ही व्हॉइस इंटरफेस तयार करता. पण ही उपजत वृत्ती एक ठिसूळ आर्किटेक्चर (brittle architecture) तयार करते. यामुळे कामाची पुनरावृत्ती होते, तुमचे लॉग्स (logs) खराब होतात आणि हळूहळू तुमच्या प्रोजेक्टचा संदर्भ (context) विस्कळीत होतो.

APC आणि APX मध्ये, आम्ही एक वेगळा मार्ग निवडला आहे. व्हॉइस हे चॅनेल नाही. ते एक 'मोड' (mode) आहे. ते एखाद्या सरफेसवर (surface) बसते, त्याला बदलत नाही. हा फरक अचूकपणे समजून घेणे हीच गोष्ट आहे जी सिस्टमला विस्कळीत होण्यापासून वाचवते.

चुकीचे ॲब्स्ट्रॅक्शन (The Wrong Abstraction)

जेव्हा तुम्ही व्हॉइसला एक स्वतंत्र चॅनेल म्हणून वागवता, तेव्हा तुम्ही नकळत असे गृहीत धरता की एजंटशी बोलणे हे त्याच्याशी टाईप करण्यापेक्षा मूलभूतपणे वेगळे आहे. यामुळे इंजिनिअरिंग टीम्स कोडबेसचे विभाजन करतात. अचानक तिथे एक CLI चॅनेल आणि एक वेगळे voice-CLI चॅनेल तयार होते. एक वेब चॅनेल आणि एक समांतर voice-web चॅनेल तयार होते. प्रत्येकासाठी वेगळे प्रॉम्प्ट व्हेरिएशन्स (prompt variations), फॉरमॅटिंग नियम आणि कॉन्टेक्स्ट हँडलिंग लॉजिक लागते.

इथूनच गोंधळ सुरू होतो. एजंटच्या वर्तणुकीत केलेला छोटासा बदल आता अनेक प्रॉम्प्ट ट्रीजमध्ये (prompt trees) कॉपी करावा लागतो. जर टीम एखादा सरफेस विसरली, तर अनुभव विस्कळीत होतो. वापरकर्त्यांना टेक्स्टमध्ये एक टोन मिळतो आणि बोलताना थोडा वेगळा व्यक्तिमत्व जाणवते. कालांतराने, या छोट्या विसंगतींमुळे सिस्टममध्ये विस्कळीतपणा (system drift) येतो. पोर्टेबल कॉन्टेक्स्ट लेयर पोर्टेबल राहत नाही, कारण त्याला एका बाजूला व्होकल डिलिव्हरी आणि दुसऱ्या बाजूला शांत टेक्स्ट या दोन्ही गोष्टींचा विचार करावा लागतो. ॲब्स्ट्रॅक्शन लीक होते आणि तुमचे एकेकाळी एकसंध असलेले प्रोजेक्ट डेफिनेशन चॅनेल-विशिष्ट 'हॅक्स'च्या (hacks) संग्रहात रूपांतरित होते.

कॉन्टेक्स्ट आणि रनटाइमचे विभाजन (Splitting Context from Runtime)

हे टाळण्यासाठी, आम्ही जबाबदाऱ्या दोन अशा लेयर्समध्ये विभागल्या आहेत जे एकमेकांपासून पूर्णपणे वेगळे राहतात.

APC प्रोजेक्ट कॉन्टेक्स्ट (project context) सांभाळते. ते एजंट्स, नियम आणि स्किल्स परिभाषित करते जे एका प्रोजेक्टचा भाग असतात. याला सिस्टमचा स्थिर अर्थ (stable meaning) समजा. ते स्ट्रक्चरल प्रश्नांची उत्तरे देते. हा एजंट काय जाणतो? त्याला काय करण्याची परवानगी आहे? तो कोणती टूल्स वापरू शकतो? उत्तर स्क्रीनवर दिसेल, चॅट API द्वारे पाठवले जाईल की स्पीकरद्वारे ऐकवले जाईल, याबद्दल APC ला काहीही फरक पडत नाही.

APX रनटाइम लेयर (runtime layer) हाताळते. तुम्ही प्रत्यक्षात वापरत असलेले सरफेस (surfaces) जसे की CLI, वेब ॲप्लिकेशन, डेस्कटॉप इंटरफेस, टेलिग्राम बॉट हे APX व्यवस्थापित करते. जेव्हा वापरकर्ता एखादी विनंती पाठवतो, तेव्हा APX प्रतिसाद कुठे आणि कसा सादर करायचा हे ठरवते. उत्तर वाचण्यासाठी फॉरमॅट करायचे की बोलण्यासाठी ऑप्टिमाइझ करायचे, हा रनटाइमचा विषय आहे. तो APX मध्ये असावा, APC मध्ये नाही.

या विभाजनामुळे, APC मध्ये परिभाषित केलेला प्रोजेक्ट कितीही सरफेस APX ने उपलब्ध करून दिले तरी तो अखंड राहतो. कॉन्ट्रॅक्ट बदलत नाही, फक्त प्रेझेंटेशन लेयर (presentation layer) बदलतो.

मोड्स (Modes) प्रत्यक्षात कसे काम करतात

आमच्या अंमलबजावणीमध्ये, टेलिग्राम, CLI आणि वेब ॲप सारखे सरफेस हे चॅनेल्स आहेत. चॅनेल तुम्हाला सांगते की संवाद कोठे झाला. व्हॉइसला चॅनेल मेटाडेटाद्वारे (channel metadata) एक 'मोड' म्हणून जोडले जाते. मोड तुम्हाला सांगतो की प्रतिसाद कसा असावा.

प्रॉम्प्ट बिल्डर (prompt builder) या मर्यादेचा आदर करतो. तो APC मधील प्रोजेक्ट कॉन्टेक्स्टमधून माहिती घेतो आणि नंतर चॅनेल मेटाडेटा तपासतो. जर डेस्कटॉप सरफेस 'व्हॉइस मोड'मध्ये चालत असेल, तर बिल्डर केवळ त्याच वेळी विशिष्ट सूचना जोडतो. कदाचित तो मॉडेलला लहान वाक्ये, सिंथेसिससाठी स्पष्ट विरामचिन्हे किंवा बोलण्याच्या संख्यांच्या पद्धतींकडे वळवेल. जर तेच डेस्कटॉप सरफेस 'टेक्स्ट मोड'मध्ये असेल, तर त्या व्होकल सूचना प्रॉम्प्टमध्ये कधीच जात नाहीत.

याचा परिणाम म्हणजे प्रत्येक सरफेससाठी एकच प्रॉम्प्ट ट्री (prompt tree) मिळते. तिथे कोणताही वेगळा voice-desktop विभाग किंवा whisper-web व्हेरिएंट नसतो. मॉडिफायर (modifier) तेव्हाच लागू होतो जेव्हा रनटाइम त्याची मागणी करतो आणि तो देखील अगदी शेवटच्या क्षणी. मूळ प्रॉम्प्ट स्थिर राहतो.

तुम्हाला काय मिळते (What You Gain)

हे आर्किटेक्चर तीन ठोस प्रकारे फायदेशीर ठरते.

कमी देखभाल खर्च (Lower maintenance costs). जर व्हॉइस हे स्वतःचे चॅनेल असते, तर प्रत्येक सरफेसला एका जोडीदाराची (twin) गरज लागली असती. तुम्हाला एक CLI चॅनेल आणि एक voice-CLI चॅनेल, एक टेलिग्राम चॅनेल आणि एक voice-Telegram चॅनेल इत्यादी सांभाळावे लागले असते. प्रत्येक वेळी जेव्हा तुम्ही सिस्टम प्रॉम्प्टमध्ये बदल करता, फॉरमॅटिंगमधील त्रुटी सुधारता किंवा स्किलचे वर्णन अधिक स्पष्ट करता, तेव्हा तुम्हाला तो बदल दोन्ही ट्रीजमध्ये करावा लागेल. जर एकही बदल राहून गेला, तर वापरकर्त्यांना ती तफावत जाणवेल. 'मोड' वापरल्यामुळे, तुम्ही प्रत्येक सरफेससाठी एकच प्रॉम्प्ट ट्री ठेवता. व्हॉइस हे रस्त्यावरील फाटा (fork in the road) नसून एक 'कंडिशनल ओव्हरले' (conditional overlay) बनते, ज्यामुळे तुम्ही संवाद साधण्याच्या नवीन पद्धती जोडत असतानाही तुमच्या कामाचा भार रेषीय (linear) राहतो.

अचूक लॉगिंग. चॅनेलमध्ये संवाद कोठे झाला याची नोंद होते. मोड्समध्ये प्रतिसाद कसा देण्यात आला याची नोंद होते. वापरकर्त्याने तो वाचला असो किंवा ऐकला असो, डेस्कटॉपवरील संवाद हा डेस्कटॉपवरील संवादच राहतो. जेव्हा तुमची टीम बग शोधते किंवा ॲनालिटिक्स तपासते, तेव्हा त्यांना 'desktop-voice' आणि 'desktop-text' हे दोन वेगळे प्रॉडक्ट सर्फेसेस आहेत असे मानून त्यांचा मेळ घालण्याची गरज पडत नाही. चॅनेल आयडेंटिफायर स्वच्छ राहतो आणि मोड फ्लॅग मेटाडेटा मध्ये त्याच्या शेजारी व्यवस्थित राहतो. तुमचे लॉग्स अचूक राहतात आणि डीबगिंग सोपे राहते कारण स्थान आणि वर्तन एकमेकांत गुंतलेले नसतात.

स्वच्छ प्रोजेक्ट कॉन्टेक्स्ट. APC कॉन्ट्रॅक्ट परिभाषित करते. प्रतिसाद बोलला गेला आहे, कुजबुजला गेला आहे किंवा मोनोस्पेस फॉन्टमध्ये रेंडर केला आहे, याची त्याला पर्वा नसावी. या रनटाइमच्या गोष्टी आहेत. व्हॉइस फॉरमॅटिंग APX मध्ये ठेवून, आम्ही APC ची पोर्टेबिलिटी जपतो. तुम्ही APC प्रोजेक्टची व्याख्या घेऊन ती व्हॉइस-विशिष्ट फॉरमॅटिंग गृहितके किंवा स्पीच-ऑप्टिमायझेशनचा अनावश्यक भार न ओढता पूर्णपणे नवीन रनटाइम वातावरणात वापरू शकता. सीमा कायम राहते आणि प्रोजेक्टचा अर्थ स्थिर राहतो.

डेस्कटॉपवरील पुरावा

आमचा स्वतःचा डेस्कटॉप मार्ग दैनंदिन वापरामध्ये हे सिद्ध करतो. डेस्कटॉप हे सरफेस आहे. जेव्हा वापरकर्ता स्पीच सक्षम करतो, तेव्हा सिस्टम तेच डेस्कटॉप सरफेस व्हॉइस मोडमध्ये चालवते. व्हॉइस हे मोड लेयरमध्ये असल्याने, डेस्कटॉप चॅनेल त्याचा पूर्ण कॉन्टेक्स्ट आणि वर्तन कायम ठेवतो. ते वेगळ्या नियमांसह एक वेगळे उत्पादन बनत नाही. प्रॉम्प्ट बिल्डर फक्त फ्लॅग लक्षात घेतो आणि केवळ आवश्यक असेल तेव्हाच व्हॉइस सूचना जोडतो. जेव्हा वापरकर्ता पुन्हा टेक्स्टवर स्विच करतो, तेव्हा त्या सूचना पूर्णपणे नाहीशा होतात. मूळ प्रोजेक्ट कॉन्टेक्स्ट कधीही बदलला नाही. डेस्कटॉप नेहमी डेस्कटॉपच होता.

मुख्य निष्कर्ष

मूळ कल्पना साधी आहे. APC स्थिर प्रोजेक्ट अर्थाचे वर्णन करते. APX रनटाइम एक्झिक्यूशनचे वर्णन करते. व्हॉइस हे सरफेसवरील एक मॉडिफायर आहे, त्याचे रिप्लेसमेंट नाही. त्याप्रमाणे वागा, आणि तुमचे प्रॉम्प्ट्स लहान राहतील. तुमचे लॉग्स स्पष्ट राहतील. तुमचे