हर कंपनी Slack, ईमेल, दस्तावेज़ और मीटिंग्स को एक ऐसे "ब्रेन" से जोड़ रही है जो हर किसी को कंपनी की सारी जानकारी तक पहुंच देता है।
लेकिन असल में कोई भी यह नहीं चाहता।
आप ऑल-हैंड्स मीटिंग में मज़ाक करते हैं कि रोडमैप डक्ट टेप से जोड़कर रखा गया है, और पूरा कमरा हंस पड़ता है। आठ महीने बाद एक नया कर्मचारी ब्रेन से पूछता है कि क्या रोडमैप सही राह पर है, और उसे आपका वही कोटेशन मिलता है — बिना उस हंसी के।
एक कस्टमर आपके अकाउंट एग्ज़ीक्यूटिव को निजी ईमेल में बताता है कि ऑनबोर्डिंग की वजह से वे लगभग चर्न (सेवा छोड़कर जाना) कर ही चुके थे। प्रोडक्ट टीम को यह जानना ज़रूरी है, लेकिन कोई उन्हें पूरा इनबॉक्स सौंपना नहीं चाहता।
एक एजेंट मैट के लिखे तीन प्रपोज़ल पढ़ता है और निष्कर्ष निकालता है कि वह मोनोलिथ आर्किटेक्चर पसंद करता है। यह सही भी हो सकता है, लेकिन इसका मतलब यह नहीं कि एजेंट को किसी से यह कहने का अधिकार मिल जाए कि "मैट ने कहा था कि हमें मोनोलिथ इस्तेमाल करना चाहिए।" उसने ऐसा कभी नहीं कहा।
आज के समय में मानक अनुमति मॉडल सरल है: अगर मैं कोई Slack मैसेज देख सकता हूँ, तो मेरा एजेंट भी उसे देख सकता है। स्रोतों की नकल करो, उनकी अनुमतियाँ इनहेरिट करो, बस। यह तब काम करता है जब सॉफ़्टवेयर मूल स्रोत को ही लौटाता है।
कंपनी ब्रेन कुछ और ही करता है। वह मीटिंग से एक फ़ैसला निकालता है, उसे ईमेल के साथ जोड़ता है, नतीजे को मेमोरी के रूप में स्टोर करता है, उसे किसी और तक पहुँचाता है, और बाद में किसी कस्टमर का जवाब दे रहे एजेंट को दे देता है। तब तक जानकारी अपने मूल स्रोत से कहीं आगे निकल चुकी होती है, और अनुमति मॉडल को भी उसके साथ चलना पड़ता है।
अनुमति की इकाई अब फ़ाइल नहीं रही। अब यह दावा (claim) है: कोई भी संदर्भ जिसे ब्रेन आगे बढ़ाता है। "Acme को सितंबर तक SSO चाहिए।" "माइग्रेशन शायद लेट हो जाएगा क्योंकि लीड इंजीनियर अनुपलब्ध है।" कोई दावा ऐसी बात हो सकती है जो किसी व्यक्ति ने सीधे कही हो या जिसे ब्रेन ने पाँच स्रोतों से जोड़कर बनाया हो। किसी भी तरह, वह अब किसी फ़ाइल के बाहर रहती है, और फ़ाइल की अनुमतियाँ उसका वर्णन नहीं करतीं।
स्रोत अनुमतियाँ आधार हैं
स्रोत अनुमतियाँ अब भी ज़रूरी हैं। अगर कोई व्यक्ति किसी Slack चैनल या Drive फ़ोल्डर तक नहीं पहुँच सकता, तो उसका एजेंट भी अचानक उसे ब्राउज़ नहीं कर पाना चाहिए। गलती यह मान लेना है कि स्रोत का ACL आपको वह सब कुछ बता देता है जो जानकारी के रूपांतरित होने के बाद ज़रूरी है।
एक स्रोत अनुमति केवल एक सीमित सवाल का जवाब देती है: यह चीज़ कौन खोल सकता है? कंपनी ब्रेन को इससे कठिन सवालों के जवाब देने होते हैं। क्या नए सेल्स हायर के एजेंट को पता होना चाहिए कि CEO ने लेऑफ़ (नौकरी से छंटनी) की समय-सीमा के बारे में बोर्ड को क्या बताया था? क्या 1:1 मीटिंग की एक खुली टिप्पणी स्थायी मेमोरी बन जानी चाहिए? क्या कस्टमर ने सच में कहा कि वे चर्न कर रहे हैं, या ब्रेन ने यह अनुमान लगाया है? क्या एजेंट उस अनुमान के आधार पर कार्रवाई कर सकता है?
ये सवाल इसलिए उठते हैं क्योंकि कंपनी ब्रेन सिर्फ़ डेटा निकालने (रिट्रीव) से ज़्यादा करते हैं। वे संश्लेषण (सिंथेसाइज़) करते हैं, और संश्लेषण अनुमति की समस्या को ही बदल देता है।
कभी-कभी ज्ञान को स्रोत से कहीं आगे जाना चाहिए
एक सेल्सपर्सन को कस्टमर के साथ निजी ईमेल में कुछ बहुत ज़रूरी पता चलता है। कस्टमर बताता है कि उन्होंने आख़िर क्यों खरीदा और क्यों एक प्रतिस्पर्धी को ठुकरा दिया। छह महीने बाद प्रोडक्ट टीम उसी मुद्दे पर चर्चा कर रही होती है।
प्रोडक्ट टीम को सबक चाहिए, पूरा इनबॉक्स नहीं।
आज, ये दोनों चीज़ें आपस में जुड़ी हैं: या तो आप स्रोत तक पहुँच सकते हैं या नहीं। कंपनी ब्रेन इन्हें अलग कर सकता है। वह सबक निकाल सकता है, संवेदनशील विवरण हटा सकता है, सबूत तक का एक रेसिप्ट सुरक्षित रख सकता है, और सबक को ज़रूरतमंद लोगों तक पहुँचा सकता है। इनबॉक्स निजी रहता है जबकि ज्ञान संगठन का हिस्सा बन जाता है।
यही बात इंजीनियरिंग में भी होती है। किसी को एक प्रतिबंधित चैनल में कोई कम-ज्ञात वर्कअराउंड मिलता है, और तीन महीने बाद एक और इंजीनियर उसी बग से जूझता है। दूसरे इंजीनियर को पहले वाले के सीखे सबक का फ़ायदा मिलना चाहिए, बिना उस चैनल की हर बातचीत तक पहुंच पाए।
कंपनी उससे कहीं ज़्यादा जानती है जितना कोई भी कर्मचारी देख सकता है। ब्रेन को उपयोगी हिस्से को आगे बढ़ाने में सक्षम होना चाहिए, बिना उसके आसपास की हर चीज़ उजागर किए।
कभी-कभी ज्ञान को स्रोत से कम आगे जाना चाहिए
एक मीटिंग की रिकॉर्डिंग पूरी कंपनी के साथ साझा की जाती है। पहले पाँच मिनट में लोग हाल-चाल पूछ रहे होते हैं। कोई अपना वीकेंड बता रहा होता है, कोई किसी सहकर्मी के बारे में मज़ाक कर रहा होता है, और कोई किसी ऐसे फ़ैसले पर अपनी नाराज़गी जता रहा होता है जिसे वे गलत मानते हैं। फिर मीटिंग शुरू होती है और समूह एक अहम प्रोडक्ट निर्णय लेता है।
हो सकता है कि हर किसी को रिकॉर्डिंग तक पहुंच का अधिकार हो। इसका मतलब यह नहीं कि हर वाक्य स्थायी कंपनी मेमोरी बनने लायक है।
मनुष्य इसे स्वाभाविक रूप से समझते हैं। हम लगातार ऐसी बातें कहते हैं जो कमरे में मौजूद लोगों के लिए उचित होती हैं लेकिन स्थायी संगठनात्मक ज्ञान के रूप में अनुचित होती हैं। आप छह सहकर्मियों को कुछ निजी बात बता सकते हैं बिना यह चाहे कि एक साल बाद कोई नया कर्मचारी उसे खोज निकाले, या आधी-अधूरी राय रख सकते हैं बिना यह चाहे कि उसे आपका अंतिम मत मान लिया जाए। एक मज़ाक का असर बिल्कुल अलग होता है जब उसे उसके लहजे और दर्शकों से अलग कर, महीनों बाद कोई एजेंट उसे सामने लाता है।
स्रोत का ACL इनमें से कुछ भी व्यक्त नहीं कर सकता। ब्रेन को समझना होगा कि कंटेंट का क्या अर्थ है। मीटिंग के कुछ हिस्से स्थायी मेमोरी बनने चाहिए, कुछ केवल रिकॉर्डिंग में उपलब्ध रहने चाहिए, और कुछ को संगठनात्मक मेमोरी से पूरी तरह हटा देना चाहिए।
लोग पहले से ही सावधान हो जाते हैं जब मीटिंग में रिकॉर्डिंग शुरू होती है। अब सोचिए कि हर बातचीत अपने आप स्थायी, खोजने योग्य कंपनी मेमोरी में बदल जाए। लोग कम मज़ाक करेंगे, कम आधी-अधूरी राय रखेंगे, और काम की बातचीत में निजी संदर्भ लाना बंद कर देंगे। कंपनी ज़्यादा शब्द कैप्चर करेगी और कम समझ पाएगी।
चुनिंदा भूलना एक अच्छे कंपनी ब्रेन का हिस्सा है। जो ब्रेन सब कुछ याद रखता है, वह आख़िरकार उन लोगों के व्यवहार को बदल देता है जिन्हें वह समझने की कोशिश कर रहा है।
एजेंट ट्रेस नई मीटिंग रिकॉर्डिंग हैं
एजेंट खुद अब कंपनी संदर्भ का एक ऐसा स्रोत हैं जो कुछ साल पहले शायद ही मौजूद था।
एक इंजीनियर कोडिंग एजेंट के साथ तीन घंटे काम कर सकता है। आख़िर में कंपनी को एक पुल रिक्वेस्ट (PR) मिलती है। लेकिन PR केवल अंतिम परिणाम (आर्टिफैक्ट) है। इस दौरान एजेंट ने फ़ाइलों का निरीक्षण किया, टूल्स का इस्तेमाल किया, कई तरीकों को खारिज किया, बाधाओं की खोज की, इंजीनियर से सुधार लिए और तय किया कि कोड कैसे काम करना चाहिए। इसका अधिकांश संदर्भ गायब हो जाता है।
हमने तय किया कि मीटिंग्स रिकॉर्ड करना उचित है क्योंकि किसी फ़ैसले तक पहुँचने वाली बातचीत में उपयोगी जानकारी होती है। एजेंट ट्रेस मीटिंग रिकॉर्डिंग के समकक्ष है। अंतिम आर्टिफैक्ट बताता है कि क्या बदला। ट्रेस बताता है कि क्यों। इसमें वह कारण हो सकता है जिससे एक डिज़ाइन खारिज हुआ, कोई ऐसी बाधा जो कोडबेस में कहीं नहीं है, कोई कस्टमर आवश्यकता जो इंजीनियर ने बातचीत में पेस्ट की, या कोई सुधार जो अगले महीने फिर मायने रखेगा।
जैसे-जैसे एजेंट ज़्यादा काम करेंगे, कंपनी की अधिकांश तर्क-वितर्क इन्हीं इंटरैक्शन के अंदर होगा। ट्रेस को फेंकने का मतलब है संस्थागत ज्ञान का बढ़ता हुआ हिस्सा फेंकना।
इसका मतलब यह नहीं कि हर टोकन को हमेशा के लिए स्टोर किया जाए। कच्चे ट्रेस में शोर, असफल प्रयास, रहस्य और निजी प्रॉम्प्ट होते हैं। उपयोगी चीज़ निर्णय इतिहास (डिसीज़न हिस्ट्री) है: यह समझने के लिए पर्याप्त सबूत कि क्या हुआ, साथ ही वे हिस्से जो स्थायी मेमोरी बनने लायक हैं।
यह एक नई स्वामित्व समस्या पैदा करता है। अगर जेसिका कंपनी छोड़ देती है, तो क्या उसके कोडिंग एजेंट ने जो कुछ भी सीखा, वह भी उसके साथ चला जाना चाहिए?
शायद नहीं; एजेंट ने यह सीखा हो सकता है कि माइग्रेशन क्यों असफल हुआ, कस्टमर का अपवाद (एक्सेप्शन) कैसे काम करता है, और कौन-सा डिज़ाइन पहले ही दो बार खारिज हो चुका है, और यह ज्ञान कंपनी का है। लेकिन उसी एजेंट में ऐसी बातचीत हो सकती है जहाँ जेसिका ने किसी का परफॉर्मेंस रिव्यू तैयार किया हो या किसी सहकर्मी के साथ टकराव पर बात की हो, और वह साझा संस्थागत मेमोरी नहीं बननी चाहिए।
सिस्टम को संदर्भ बनते समय ही इन दोनों को अलग कर देना चाहिए, क्योंकि ऑफबोर्डिंग के समय तक बहुत देर हो चुकी होती है।
श्रेय (एट्रिब्यूशन) अनुमतियों का हिस्सा है
कंपनी ब्रेन ऐसी जानकारी भी बनाएगा जो किसी ने लिखी नहीं होगी।
मान लीजिए सिस्टम मैट द्वारा लिखे गए तीन प्रपोज़ल पढ़ता है और निष्कर्ष निकालता है कि वह एक विशेष आर्किटेक्चर पसंद करता है। यह उपयोगी संदर्भ हो सकता है। लेकिन सिस्टम को यह नहीं कहना चाहिए:
मैट ने कहा कि हमें यह आर्किटेक्चर इस्तेमाल करना चाहिए
मैट ने ऐसा कभी नहीं कहा; ब्रेन ने यह अनुमान लगाया था।
यह अंतर मायने रखता है क्योंकि "मैट ने X कहा" का वज़न "सिस्टम ने मैट के काम से X का अनुमान लगाया" से कहीं ज़्यादा होता है। पहले कथन के लिए एक सबूत (रेसिप्ट) चाहिए: एक ईमेल, ट्रांसक्रिप्ट या दस्तावेज़ का हिस्सा जहाँ मैट ने वास्तव में वह बात कही हो। नहीं तो सिस्टम को अपनी ही आवाज़ में बोलना होगा:
मैट द्वारा लिखे तीन प्रपोज़ल से अनुमानित
हर अहम दावे की उत्पत्ति (प्रोवेनेंस) ज़रूरी है। यह कहाँ से आया? क्या इसे कहा गया था, अनुमान लगाया गया था, या अज्ञात है? यह कितना ताज़ा है? सिस्टम को कितना भरोसेमंद होना चाहिए?
और यह इतिहास रूपांतरण के बाद भी बचा रहना चाहिए। एक निजी ईमेल केवल इसलिए खुली पहुंच वाली नहीं बन जाती क्योंकि किसी एजेंट ने उसका सारांश बना दिया। एक अनुमान केवल इसलिए कोटेशन नहीं बन जाता क्योंकि उसे तीन बार दोहराया गया। एक भरोसेमंद कंपनी ब्रेन को श्रृंखला सुरक्षित रखनी होती है।
सारांश अनुमतियों की लॉन्ड्रिंग करते हैं। अनुमान श्रेय की लॉन्ड्रिंग करते हैं।
अनुमतियों की एक घड़ी होती है
भले ही सिस्टम जानता हो कि आज किसे कुछ पता होना चाहिए, कल यह जवाब बदल सकता है।
एक टीम नए कर्मचारी लाभ (बेनिफिट) की शुरुआत करने का फ़ैसला करती है। लॉन्च तैयार करने वालों को तुरंत पता होना चाहिए। कस्टमर्स को नहीं पता होना चाहिए। बाकी कंपनी को शुक्रवार की ऑल-हैंड्स मीटिंग में पता चल सकता है। ऐलान के बाद यह जानकारी रिक्रूटिंग, सेल्स और मार्केटिंग तक पहुँच सकती है।
मूल तथ्य में कुछ नहीं बदला, लेकिन उसके उपयुक्त दर्शक बदल गए।
इस तरह का इरादा शायद ही कहीं दर्ज होता है। कोई सोचता है "मैं इसे खुद ऐलान करना चाहता हूँ" और कभी एम्बार्गो फ़्लैग सेट नहीं करता। एक कस्टमर खुश होता है कि उसकी कहानी किसी सेल्सपर्सन की मदद करे, लेकिन उसे LinkedIn पोस्ट में बदलते देख असहज महसूस करता है। कोई फाउंडर आगामी प्रोडक्ट पर आकस्मिक रूप से चर्चा करता है बिना कभी "एम्बार्गो" शब्द बोले।
मनुष्य अपने दिमाग में बहुत सारी अनुमति नीतियाँ रखते हैं। कभी-कभी सिस्टम को पूछना पड़ता है:
आपने अभी-अभी एक बड़ा प्रोडक्ट निर्णय लिया है। क्या मैं इसे कंपनी के साथ साझा करूँ?
असली चुनौती यह जानना है कि कब बीच में टोकना है। जो सिस्टम हर पाँच मिनट में अनुमति माँगता है, वह लोगों को उसे अनदेखा करना सिखा देता है। मानवीय निर्णय उन मामलों के लिए सुरक्षित रखा जाना चाहिए जहाँ जवाब वास्तव में अस्पष्ट हो और परिणाम पलटना मुश्किल हो। एक आंतरिक अवलोकन को एक अतिरिक्त टीममेट के साथ साझा करना पलटा जा सकता है। किसी चीज़ को बाहरी रूप से प्रकाशित करना, कस्टमर को ईमेल भेजना या कोई अपरिवर्तनीय कार्रवाई करना कहीं ज़्यादा ऊँचे मानक की माँग करता है।
सिस्टम को नियमित मामलों को अपने आप हल करना चाहिए, एक रेसिप्ट छोड़नी चाहिए, और मानवीय ध्यान उन कुछ फ़ैसलों के लिए बचाना चाहिए जहाँ समझ-बूझ मायने रखती है।
एक कंपनी आसान मामला है
अधिकांश अनुमति प्रणालियाँ मान लेती हैं कि एक संगठन है और एक एडमिनिस्ट्रेटर है। एजेंट उस धारणा को तोड़ देंगे।
एक खरीदार का एजेंट विक्रेता के एजेंट से बात करेगा। एक कंपनी एजेंट किसी कर्मचारी के निजी एजेंट के साथ काम करेगा। एक सपोर्ट एजेंट आंतरिक ज्ञान को बाहरी जवाब में बदलेगा। आख़िरकार, कंपनी ब्रेन सीधे दूसरे कंपनी ब्रेन के साथ संदर्भ का आदान-प्रदान करेंगे, और दोनों पक्षों को नियंत्रित करने वाली कोई एक अनुमति प्रणाली नहीं होगी।
और "आंतरिक" बनाम "बाहरी" बहुत सरल भेद है। कस्टमर का हस्ताक्षरित अनुबंध किसी आंतरिक CRM फ़ील्ड से अधिक आधिकारिक हो सकता है। किसी दूसरी कंपनी के एजेंट द्वारा अनुमानित दावा शोध के लिए उपयोगी हो सकता है, लेकिन कोई अपरिवर्तनीय कार्रवाई शुरू करने के लायक भरोसेमंद होना दूर की बात है।
संदर्भ को अपना अधिकार अपने साथ रखना होगा। जानकारी का एक टुकड़ा पढ़ने के लिए सुरक्षित हो सकता है, सिफारिश में उपयोग करने के लिए सुरक्षित हो सकता है, और किसी कार्रवाई के एकमात्र आधार के रूप में उपयोग करने के लिए असुरक्षित हो सकता है। यह अंतर तब महत्वपूर्ण हो जाता है जब एजेंट सिर्फ़ सवालों के जवाब देने से ज़्यादा काम कर सकते हैं।
व्यक्ति-स्वामित्व वाले एजेंट इस सीमा को और भी कठिन बनाते हैं। उनकी मेमोरी कई नौकरियों तक फैली हो सकती है। व्यक्ति को अपना निजी इतिहास रखना चाहिए, और नियोक्ता को वह कार्य ज्ञान रखना चाहिए जिसे बनाने के लिए कंपनी ने भुगतान किया था। गोपनीय कंपनी संदर्भ अगली कंपनी में नहीं जाना चाहिए, निजी संदर्भ पुरानी कंपनी में नहीं समा जाना चाहिए, और यह सीमा मेमोरी के अंदर ही मौजूद होनी चाहिए।
अनुमति मॉडल ज्ञान के साथ चलता है
ये आयाम स्वतंत्र हैं। एक कंपनी में सख्त स्रोत सीमाएँ और भारी कंटेंट फ़िल्टरिंग हो सकती है। दूसरी कंपनी उपयोगी ज्ञान को टीमों के बीच तेज़ी से आगे बढ़ने दे सकती है जबकि बहुत कम कच्ची बातचीत बचाए रखती है। एजेंट-निर्मित संदर्भ एक और स्रोत है। मानवीय निर्णय एक एस्केलेशन तंत्र है। श्रेय (एट्रिब्यूशन), समय, दर्शक और कार्रवाई का अधिकार इन सबसे जुड़े होते हैं। सामान्य आधार इकाई दावा (claim) है।
कंपनी ब्रेन का हर स्थायी दावा अपनी नीति खुद रखना चाहिए। कम से कम, ब्रेन को यह जानना चाहिए:
- दावा कहाँ से आया और क्या इसे कहा गया था या अनुमान लगाया गया था
- इसे कौन प्राप्त कर सकता है
- इसका उपयोग किस लिए किया जा सकता है
- यह कितने समय तक मेमोरी में रहना चाहिए
- इसके दर्शक कब बदल सकते हैं
- इसके आधार पर एजेंट कौन-सी कार्रवाइयाँ कर सकता है
- कब किसी मानव को निर्णय लेने की आवश्यकता होती है
स्रोत अनुमति शुरुआती बिंदु है। फिर नीति संदर्भ के साथ यात्रा करती है जब वह सारांशित, संयोजित, स्मरण और साझा किया जाता है। पारंपरिक अनुमतियाँ वस्तुओं (ऑब्जेक्ट्स) को नियंत्रित करती हैं, जबकि कंपनी ब्रेन को जानकारी को उसके प्रवाह के दौरान नियंत्रित करना होता है।
यह ऐसी समस्या नहीं है जिसे बाद में जोड़कर ठीक किया जा सके। जो कंपनी एक साल तक बिना किसी भेदभाव के काम करने वाला ब्रेन चलाती है, उसने एक साल की अपरिवर्तनीय मेमोरी लिख ली है: मज़ाक, नाराज़गी, आधी-अधूरी राय, कोटेशन के रूप में पेश किए गए अनुमान। बदतर, उसने एक साल लोगों को यह सिखाने में बिताया है कि ब्रेन उनकी बातों के साथ क्या करता है। एक बार जब कर्मचारी समझ जाते हैं कि सब कुछ स्थायी और खोजने योग्य बन जाता है, तो वे अलग तरह से बात करने लगते हैं, और जब आप बाद में अनुमति मॉडल ठीक करते हैं तो वह खुलापन (कैंडर) वापस नहीं आता।
समझ बढ़ती है, और अविश्वास भी बढ़ता है। जो कंपनियाँ शुरू से ही अनुमति मॉडल को सही रखती हैं, उनके पास ऐसे ब्रेन होंगे जिनके सामने लोग सच में बोल पाएँगे।
अनुमतियाँ इंटेलिजेंस का हिस्सा हैं
Hyperspell में, हम एक कंपनी ब्रेन बना रहे हैं: एक लगातार अपडेट होने वाला मॉडल जो कंपनी के मैसेज, दस्तावेज़ों, मीटिंग्स, सिस्टम और एजेंट्स के बीच उसके ज्ञान को दर्शाता है।
कनेक्टर सेंसर लेयर हैं। असली कठिन काम तब शुरू होता है जब वह सारा संदर्भ आपस में बातचीत करने लगता है। ब्रेन को तय करना होता है कि किन स्रोतों पर भरोसा करना है, क्या मेमोरी बनने लायक है, कोई निष्कर्ष कहाँ से आया, इसे किसे प्राप्त करना चाहिए, और एजेंट को इसके साथ क्या करने की अनुमति है।
उपयोगी ज्ञान को ज़रूरतमंद लोगों और एजेंट्स तक पहुँचना चाहिए, बिना उसके आसपास की हर चीज़ उजागर किए। आकस्मिक बातचीत को आकस्मिक रहने दिया जाना चाहिए, अनुमान को अनुमान ही रहना चाहिए, और कंपनी का ज्ञान कर्मचारियों के जाने के बाद भी बना रहना चाहिए, बिना उसके आसपास की निजी चीज़ों को सोख लिए। कभी-कभी ब्रेन को इतना समझदार होना चाहिए कि बोलने से पहले पूछ ले।
यह उन मुख्य समस्याओं में से एक है जिन्हें हम Hyperspell में हल कर रहे हैं। अगर आप देखना चाहते हैं कि एक वास्तविक अनुमति मॉडल वाला कंपनी ब्रेन कैसा दिखता है, तो हम आपको पंद्रह मिनट में दिखा सकते हैं।
एक उपयोगी कंपनी ब्रेन जानता है कि कंपनी क्या जानती है।
एक भरोसेमंद ब्रेन यह भी जानता है कि चुप कब रहना है।
