अनुमतियाँ, स्वीकृतियाँ और ड्राफ़्ट

ElevenAgents Architect आपकी ओर से कैसे काम करता है, कब स्वीकृति मांगता है और लाइव कॉलर तक पहुँचने से पहले बदलावों को कैसे चरणबद्ध किया जाता है।

ElevenAgents Architect कैसे ऑथेंटिकेट करता है

Architect अलग service account का इस्तेमाल नहीं करता या किसी अलग identity के रूप में काम नहीं करता। ElevenLabs डैशबोर्ड में, इसके टूल आपके ब्राउज़र में, आपके signed-in session के भीतर चलते हैं। एजेंट का configuration पाने से लेकर branch बनाने तक, यह जो भी read या write करता है, वह आपके workspace permissions के तहत, आपकी ओर से किया गया सामान्य request होता है।

इसके तीन नतीजे होते हैं:

Architect सिर्फ़ वही कर सकता है जो आप कर सकते हैं। अगर आप किसी एजेंट को edit नहीं कर सकते, तो Architect उसे पढ़ सकता है, लेकिन उसमें बदलाव stage नहीं कर सकता। अगर आपकी role protected branch में merge करने की अनुमति नहीं देती, तो Architect भी उसमें merge नहीं कर सकता।
इसका काम आपके नाम से रिकॉर्ड होता है। आपके publish किए गए versions, branches और Architect के बनाए merge proposals में आप author के रूप में दिखते हैं। इनमें कहीं भी यह नहीं दिखता कि इन्हें Architect ने बनाया है।
अलग-अलग यूज़र्स को अलग नतीजे मिलते हैं। अगर दो teammates Architect से एक ही बदलाव करने को कहें, तो उनकी roles अलग होने पर नतीजे भी अलग हो सकते हैं।

यह पेज ElevenLabs डैशबोर्ड में Architect के बारे में बताता है, जो फ़िलहाल Architect चलाने की एकमात्र जगह है। Architect दूसरे माध्यमों, जैसे Slack, में भी आ रहा है, लेकिन वह अभी उपलब्ध नहीं है। हर माध्यम पर Architect का मॉडल एक जैसा रहेगा: यह जिस व्यक्ति से बात कर रहा है, उसी के रूप में ऑथेंटिकेट करेगा और उसी व्यक्ति की permissions के साथ काम करेगा।

हर role से क्या अनुमति मिलती है

एजेंट access roles Architect पर ठीक उसी तरह लागू होती हैं जैसे डैशबोर्ड में आप पर होती हैं।

एजेंट के लिए आपका access	Architect आपके लिए क्या कर सकता है
Viewer	configuration, conversations, tests, branches और proposals पढ़ सकता है। बदलावों की जाँच और सुझाव दे सकता है, लेकिन उन्हें stage नहीं कर सकता।
Editor	Viewer की सभी क्षमताओं के साथ drafts में बदलाव stage कर सकता है, branches बना सकता है, tests लिख और चला सकता है, merge proposals खोल सकता है, और unprotected branches में merge कर सकता है।
Workspace admin	Editor की सभी क्षमताओं के साथ protected branches में merge कर सकता है और protected branches का traffic share बदल सकता है।

Workspace-level resources, जैसे tools, knowledge base documents और tests, अपनी sharing permissions के अनुसार काम करते हैं। एजेंट पर कौन-सी actions लागू होती हैं और workspace पर कौन-सी, यह जानने के लिए Architect क्या बदल सकता है देखें।

Approval modes

हर Architect conversation तीन modes में से किसी एक में चलता है। composer में pill से mode बदलें या इनके बीच जाने के लिए Shift+Tab दबाएं।

Mode	व्यवहार
Approval required (default)	Architect live traffic या shared resources पर असर डालने वाली actions से पहले पूछता है। यह ठीक-ठीक दिखाता है कि क्या बदलेगा और आपके approve या reject करने का इंतज़ार करता है।
Auto-approve	Architect किसी भी action से पहले नहीं पूछता, जिसमें branch merge करना, traffic split बदलना, draft discard करना, एजेंट archive करना या test call करना शामिल है। इसका इस्तेमाल सिर्फ़ उस काम के लिए करें जिसके बारे में आपको पूरा भरोसा हो।
Plan	Architect read-only tools से रिसर्च करता है, plan लिखता है और कुछ भी बदलने से पहले आपके plan approve करने का इंतज़ार करता है। आपके approve करने के बाद, actions को Approval required mode की तरह नियंत्रित किया जाता है।

आपकी mode पसंद आपके ब्राउज़र में याद रखी जाती है। ऐसा कोई workspace setting नहीं है जो सभी के लिए mode लागू करे। किसी live agent में हर बदलाव के लिए review ज़रूरी बनाने हेतु उसकी main branch को protect करें, ताकि बदलाव approved merge proposal के ज़रिए ही हों।

किन actions में पहले पूछा जाता है

Approval required mode में, Architect बिना पूछे एजेंट के configuration में बदलाव आपके draft में stage करता है, क्योंकि draft का live callers पर कभी असर नहीं पड़ता। यह इनसे पहले पूछता है:

ऐसे बदलाव जो live callers के लिए तुरंत लागू होते हैं: branch merge करना और traffic split बदलना।
Shared workspace resources में बदलाव: tools बनाना, update या delete करना, tests update या delete करना, और ज़्यादातर knowledge base बदलाव।
Destructive actions: draft discard करना, procedure delete करना, एजेंट या branch archive करना।
असली दुनिया की actions: test phone call करना।

Reads के लिए कभी नहीं पूछा जाता। Approval prompt उन deletes को Permanent label से चिह्नित करता है जिन्हें undo नहीं किया जा सकता। पहले पूछे जाने वाली actions की पूरी सूची Architect क्या बदल सकता है में है।

हर mode में, इन तीन steps के लिए हमेशा आपकी ज़रूरत होती है:

Draft publish करना। Architect publish dialog खोलता है और आप Publish चुनते हैं।
Plan mode में plan approve करना।
मौजूदा draft के साथ क्या करना है, यह तय करना। अगर branch में पहले से ऐसा draft है जिसे Architect ने इस chat में नहीं बनाया है, जिसमें editor में unsaved edits भी शामिल हैं, तो Architect रुक जाता है और कुछ भी stage करने से पहले पूछता है कि उसे रखना है या discard करना है।

Session के लिए किसी tool पर भरोसा करना

Approval prompt में Trust these tools this session checkbox होता है। इसे चुनने पर, उस session में उन्हीं tools के बाद के calls बिना पूछे चलेंगे। नया conversation शुरू करने पर यह भरोसा खत्म हो जाता है। अगर आप करीब दो मिनट में approval prompt का जवाब नहीं देते, तो request expire हो जाता है और Architect action नहीं चलाता।

Drafts, versions और branches

Architect, ElevenAgents के बाकी हिस्सों जैसा ही versioning मॉडल इस्तेमाल करता है।

Concept	यह क्या है	Architect इसका कैसे इस्तेमाल करता है
Draft	एक branch पर आपके unpublished बदलाव। हर user का हर branch के लिए अपना draft होता है।	Architect के किए हर configuration edit को यहाँ stage किया जाता है। Chat में Review & publish के साथ staged changes panel दिखता है।
Version	Draft publish होने पर बना immutable snapshot।	आप publish करते हैं। Architect नहीं कर सकता। Protected branch पर dialog इसके बजाय नई branch पर publish करने का विकल्प देता है।
Branch	Versions की एक named line। Live traffic प्रतिशत के आधार पर branches पर route होता है।	Architect उन बदलावों के लिए branch बनाता है जिन्हें review चाहिए, ताकि branch merge होने तक `main` पर असर न पड़े।

“आपके approval के बिना कुछ भी live नहीं होता” का एक सटीक मतलब है:

एजेंट के configuration में बदलाव draft में stage होते हैं और traffic serve करने वाली branch पर आपके publish करने के बाद ही live callers तक पहुँचते हैं।
Approval required mode में, live traffic या shared resources पर असर डालने वाली actions आपके approval का इंतज़ार करती हैं।
Auto-approve mode में भी Architect publish नहीं कर सकता, लेकिन आपकी permissions के दायरे में यह बिना पूछे branches merge कर सकता है और traffic splits बदल सकता है।

एजेंट configuration के बाहर किए गए कुछ बदलाव workspace में बनते ही लागू हो जाते हैं, जैसे tool या knowledge base document बनाना। वे एजेंट के व्यवहार पर तब तक असर नहीं डालते जब तक एजेंट उनका इस्तेमाल न करे, जो तब होता है जब आप उन्हें attach करने वाला draft publish करते हैं। Live agents से पहले से जुड़े workspace resources इसका अपवाद हैं: जिस tool का live agent इस्तेमाल करता है, उसे update करने से उस एजेंट पर तुरंत असर पड़ता है। Approval required mode में Architect tools update करने से पहले पूछता है।

Version history और revert करना

हर published version में क्या बदला और किसने publish किया, यह रिकॉर्ड होता है।

क्या बदला, देखें: Version Control > Branches में किसी branch की Version history खोलें। किसी भी version की तुलना पिछले version या live version से करें। या Architect से पूछें, जैसे “पिछले हफ़्ते main में क्या बदला?” यह आपके लिए branch history पढ़ता है और versions का diff करता है।
किसने बदला, देखें: हर version में उसे publish करने वाला user दिखता है। Architect द्वारा किया गया बदलाव उस user के नाम से दिखता है जो उससे बात कर रहा था।
Revert: version history में Revert to this version चुनें। Revert करने से history हटती नहीं है। यह पुराने configuration को नए version के रूप में publish करता है। आप /rollback का इस्तेमाल करके भी Architect से हाल के बदलावों की समीक्षा करवा सकते हैं और अपने publish करने के लिए revert stage करवा सकते हैं।