अनुपस्थित परत: संगठनात्मक पदानुक्रमों के लिए AI एजेंट्स को संरचित करना

संगठन AI के साथ अपने काम को कैसे व्यवस्थित करते हैं, इसके लिए एक रेफरेंस मॉडल

Jose Martinez · 1 October 2026 · v1.8.1 (Claude Code में मापा गया; 1 October 2026 को Anthropic के दस्तावेज़ों से दोबारा जाँचा गया)

पाँच पंक्तियों में।

1. संगठन पेड़ (trees) की तरह होते हैं: फर्म, कार्य-क्षेत्र (line of work), प्रोजेक्ट, टास्क। Claude के प्रोजेक्ट्स सपाट (flat) होते हैं: चैट में सिर्फ़ एक 3,000-कैरेक्टर का ऑर्गनाइज़ेशन ब्लॉक होता है, चैट और Cowork में प्रोजेक्ट्स न तो नेस्ट होते हैं और न ही इनहेरिट करते हैं, और किसी प्रोजेक्ट में कनेक्टर अकाउंट या तो किसी व्यक्ति का होता है या पूरे संगठन का, कभी भी किसी ब्रांच का नहीं।

1. इसलिए हर प्रोजेक्ट को अपनी लाइन के नियमों की हाथ से बनाई गई कॉपी मिलती है, ये कॉपियाँ समय के साथ बदल जाती हैं, और कोई यह नहीं देख पाता कि कौन सा नियम किस जवाब को जन्म दिया।

1. Anthropic इस पेड़ को पहले ही दो बार बना चुका है। Claude Code निर्देशों को फोल्डर के हिसाब से नेस्ट करता है, और 1 October 2026 से यह किसी व्यक्ति के mods से पहले संगठन के mods चलाता है। Slack में मौजूद Claude Tag, निर्देशों और क्रेडेंशियल्स को ऑर्गनाइज़ेशन से वर्कस्पेस और फिर चैनल तक इनहेरिट करता है। लेकिन इनमें से कोई भी प्रोजेक्ट तक नहीं पहुँचता। यही मॉडल ऐसा कर सकता है: कार्य-क्षेत्र की एक लेयर, उनके फोल्डर्स से पैदा होने वाले प्रोजेक्ट्स, टाइप किए गए टास्क, एक कंपाइलर जो मॉडल के देखने से पहले ही विरोधाभासों को खारिज कर दे, और Team पर काम करने वाली प्रति-नोड अनुमतियाँ।

1. मैंने इसे Claude Code में दो बार मापा। एक संगठन नियम और एक प्रोजेक्ट नियम जो आपस में मेल नहीं खाते थे, अलग-अलग CLAUDE.md स्तरों पर थे और दोनों में से किसी को भी बाध्यकारी (binding) नहीं बताया गया था: प्रोजेक्ट नियम 20 में से 20 बार जीता। वही संगठन नियम जब शब्दों में लागू (enforced) बताया गया: वह 20 में से 20 बार जीता। प्राथमिकता संरचना से तय नहीं हुई, बल्कि उस शब्दावली से तय हुई जिसे किसी भी लेयर को एडिट करने वाला कोई भी व्यक्ति बदल सकता है।

1. यह आज ही चल रहा है। मेरे द्वारा बनाया गया एक डेस्कटॉप ऐप पेड़ (tree) के अंदर Claude Code चलाता है। यह हर लेयर को CLAUDE.md के रूप में माउंट करता है, Claude को सीमित करता है कि वह उस नोड पर व्यक्ति क्या कर सकता है, लिखे जाने पर विरोधाभास को खारिज कर देता है, और हर जवाब को उसके नियमों, उसके टोकन्स और उसके समीक्षक के साथ लॉग करता है। मापने पर, पेड़ ने सपाट कॉपियों की तुलना में 20–34% कम इंस्ट्रक्शन टोकन्स लोड किए।

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

AI प्रोजेक्ट्स सपाट होते हैं। मैं मामले के तौर पर Claude का इस्तेमाल इसलिए करता हूँ क्योंकि यही वह प्रोडक्ट है जिसमें मैं रोज़ काम करता हूँ, और क्योंकि यह पहले से ही अपने दो सरफेस में इसका जवाब देता है। Claude चैट में, प्रोजेक्ट्स को नेस्ट नहीं किया जा सकता, और संगठन निर्देश अधिकतम 3,000 कैरेक्टर का एक ही ब्लॉक होता है जो सभी पर लागू होता है। Enterprise पर, एडमिन permissions को ग्रुप के अनुसार सीमित कर सकते हैं। Team पर, भूमिकाएँ (roles) पूरे संगठन पर लागू होती हैं। चैट या Cowork में दस्तावेज़ित कुछ भी instructions को किसी विभाग या कार्य-क्षेत्र तक और वहाँ से उसके प्रोजेक्ट्स तक नहीं ले जाता। Enterprise पर, स्किल्स और प्रोजेक्ट्स को किसी ग्रुप के साथ शेयर किया जा सकता है, लेकिन वह वितरण (distribution) है, इनहेरिटेंस नहीं।

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

1. आज क्या मौजूद है

29 September–1 October 2026 को Anthropic के दस्तावेज़ों से जाँचा गया। Claude के चार सरफेस हैं जहाँ किसी टीम का काम चलता है, और हर एक का अपना इंस्ट्रक्शन मॉडल है:

अनुमतियाँ प्लान पर निर्भर करती हैं:

Anthropic ने अनुमतियों के लिए आधा पेड़ बना लिया है। Enterprise पर, कस्टम रोल्स ग्रुप्स को दिए जाते हैं; “कस्टम रोल्स यह भी नियंत्रित करते हैं कि कोई रोल किन कनेक्टर्स और उन कनेक्टर्स पर किन टूल्स का उपयोग कर सकता है”; पूरे प्लेटफॉर्म पर, संगठन, रोल और यूज़र स्तरों में “सबसे प्रतिबंधात्मक स्तर जीतता है”, जबकि किसी सदस्य की कई भूमिकाएँ जुड़ जाती हैं; एडमिन “View effective role” देख सकते हैं, जिसमें “Granted by” लेबल होता है; और ग्रुप्स की अपनी खर्च सीमाएँ हो सकती हैं। लेकिन ये सपाट ग्रुप्स हैं, पेड़ नहीं, और इनमें से कोई भी निर्देशों तक नहीं पहुँचता। सबसे करीबी चीज़ प्लगइन्स हैं: Enterprise पर, कोई ओनर किसी प्लगइन और उसकी स्किल्स को एक ग्रुप के लिए आवश्यक या डिफ़ॉल्ट रूप से इंस्टॉल कर सकता है, जिसका एक तय क्रम होता है (“ग्रुप सेटिंग, फिर संगठन-व्यापी सेटिंग, फिर मार्केटप्लेस डिफ़ॉल्ट”)। यह लोगों के एक ग्रुप को लक्षित करता है, किसी प्रोजेक्ट को नहीं, प्रोजेक्ट्स के बीच कुछ भी इनहेरिट नहीं होता, और कोई स्किल तभी लोड होती है जब Claude उसे प्रासंगिक मानता है। Team में पूरे संगठन के लिए रोल्स और व्यक्ति-दर-व्यक्ति शेयरिंग होती है; दस्तावेज़ों के शब्दों में, इसकी प्लगइन सेटिंग्स में “कोई ग्रुप सेटिंग नहीं” है। और Team छोटी और मध्यम आकार की फर्मों के लिए बनाया गया प्लान है।

Anthropic ने पूरा पेड़ दो बार बनाया है, प्रोजेक्ट्स के बाहर।

Claude Code में, फोल्डर के हिसाब से। Claude Code चार स्तरों से CLAUDE.md फाइलें लोड करता है; “खोजी गई सभी फाइलें एक-दूसरे को ओवरराइड करने के बजाय संदर्भ (context) में जोड़ दी जाती हैं”, जिसका क्रम “फाइलसिस्टम रूट से लेकर आपकी वर्किंग डायरेक्टरी तक” होता है, और सबडायरेक्टरीज़ की फाइलें “माँग पर लोड” होती हैं। किसी संगठन का ब्लॉक हर मशीन पर मैनेज्ड फाइल के रूप में या एडमिन कंसोल (claudeMd कुंजी) से टेक्स्ट के रूप में आ सकता है। दस्तावेज़ इस सीमा के बारे में स्पष्ट हैं: Claude इन फाइलों को “लागू किए गए कॉन्फ़िगरेशन के रूप में नहीं, बल्कि संदर्भ के रूप में” मानता है, और “अगर दो निर्देश एक-दूसरे का खंडन करते हैं, तो Claude मनमाने ढंग से किसी एक को चुन सकता है।”

Claude Tag में, Slack चैनल के हिसाब से। Claude Tag किसी टीम के Slack में मौजूद Claude है, जो Team और Enterprise पर पब्लिक बीटा में है। इसकी सेटिंग्स एक स्कोप से जुड़ी होती हैं, और “स्कोप वह जगह है जहाँ कोई बंडल लागू होता है: Default Slack access (संगठन-व्यापी रूट), एक वर्कस्पेस, या एक सिंगल चैनल।” इस आर्टिकल के बाकी हिस्से में जिन तीन चीज़ों की माँग की गई है, वे पहले से मौजूद हैं:

• निर्देश इनहेरिट होते हैं। “प्रति-स्कोप कस्टम निर्देश जोड़े जाते हैं, पहले Default Slack access, फिर वर्कस्पेस, फिर चैनल। किसी चैनल के निर्देश ऊपर सेट की गई चीज़ों को बदलने के बजाय उनमें जुड़ते हैं।”

• क्रेडेंशियल्स ब्रांच के होते हैं। चैनल्स में, Claude उन सर्विस अकाउंट्स के साथ काम करता है जो कोई एडमिन किसी स्कोप से जोड़ता है, और “सबसे संकरे स्कोप का क्रेडेंशियल इस्तेमाल किया जाता है: चैनल वर्कस्पेस को हराता है, जो Default Slack access को हराता है।”

• आप देख सकते हैं कि एक्सेस कहाँ से आया। हर कनेक्टर, रिपॉज़िटरी और प्लगइन पंक्ति बताती है कि यह किसी बड़े स्कोप से “Inherited from” है या किसी बंडल से “Attached from” है। खर्च संगठन और प्रति-चैनल सीमित होता है, और प्रति-चैनल रिपोर्ट किया जाता है।

सीमाएँ भी दस्तावेज़ित हैं। पेड़ का आकार Slack जैसा है: तीन तय स्तर, और Slack चैनल्स नेस्ट नहीं होते। निर्देश “मार्गदर्शन हैं, लागू की गई सुरक्षा-रेखा नहीं”, और दस्तावेज़ स्कोप्स के बीच विरोधाभासों की जाँच का कोई तरीका नहीं बताते। “हर टास्क और उसे किसने माँगा, इसका कोई प्रति-क्रिया लॉग नहीं” है। और यह एक प्रोजेक्ट की सीमा पर रुक जाता है: “claude.ai के प्रोजेक्ट्स यहाँ लागू नहीं होते; Claude Slack में किसी प्रोजेक्ट के निर्देशों या ज्ञान को नहीं पढ़ता, और किसी चैनल को किसी प्रोजेक्ट की ओर निर्देशित नहीं किया जा सकता।”

1 October 2026 को क्या बदला। Claude Code 2.1.287 ने mods चालू कर दिए, जो पहले अर्ली एक्सेस में थे: ये किसी प्लगइन के अंदर ऐसे फंक्शन हैं जो Claude Code के भीतर चलते हैं और किसी प्रॉम्प्ट या सिस्टम प्रॉम्प्ट के किसी हिस्से को फिर से लिख सकते हैं, किसी टूल कॉल को ब्लॉक या फिर से लिख सकते हैं, किसी अनुमति अनुरोध को मंज़ूर या अस्वीकार कर सकते हैं, और इंटरफ़ेस में पेन (panes) बना सकते हैं। इनके बारे में तीन बातें यहाँ मायने रखती हैं:

• इनका एक घोषित क्रम होता है। एक बिल्ट-इन गार्ड और संगठन के अपने mods पहले चलते हैं, फिर वे mods जिन्हें कोई व्यक्ति इंस्टॉल करता है। “पहला mod सबसे बाहरी होता है: यह घटना को दूसरों से पहले और परिणाम को उनके बाद देखता है, और यह तय करता है कि बाकी वाले चलेंगे भी या नहीं।” जहाँ गार्ड लोड होता है (मैनेज्ड सेटिंग्स वाली मशीन, या Team या Enterprise लॉगिन), किसी व्यक्ति का mod “सिस्टम प्रॉम्प्ट, आपकी मैनेज्ड CLAUDE.md और अन्य मैनेज्ड निर्देशों” को नहीं बदल सकता, और यह किसी टूल कॉल को मंज़ूरी नहीं दे सकता जिसे कोई अस्वीकृति नियम (deny rule) मना करता है। यही संरचना द्वारा तय की गई प्राथमिकता है, जिसकी यह आर्टिकल माँग करता है। यह एक डिफ़ॉल्ट है, ताला नहीं: जो व्यक्ति --safe-mode के साथ Claude Code शुरू करता है, वह इंस्टॉल किए गए mods के बिना चलता है, जिसमें संगठन के mods भी शामिल हैं, जबकि मैनेज्ड हुक्स और अस्वीकृति नियम अभी भी लागू रहते हैं।

• इस क्रम के दो मालिक होते हैं। संगठन के mods व्यक्ति के mods से पहले चलते हैं, या अगर संगठन चाहे तो उनके बाद। कार्य-क्षेत्र के लिए कोई स्तर नहीं है। एडमिन कंसोल से दी गई सेटिंग्स “संगठन के सभी यूज़र्स पर एकसमान रूप से लागू होती हैं। प्रति-ग्रुप कॉन्फ़िगरेशन अभी तक समर्थित नहीं हैं।” कोई संगठन जो हर ग्रुप के लिए अलग नीति चाहता है, उसके पास दो रास्ते हैं, दोनों IT के ज़रिए: हर ग्रुप की मशीनों पर अलग सेटिंग्स फाइल तैनात करें, या एक सेल्फ-होस्टेड गेटवे चलाएँ जो “प्रति IdP ग्रुप मैनेज्ड सेटिंग्स देता है”।

• ये चैट तक नहीं पहुँचते, और Cowork तक असमान रूप से पहुँचते हैं। “Mods Claude Code CLI और Claude Desktop ऐप के Code टैब में काम करते हैं।” कोई mod किसी प्लगइन की hooks/hooks.json में आता है, और Anthropic की प्लगइन सपोर्ट तालिका उस फाइल को चैट में “Ignored” बताती है। वही तालिका इसे Cowork में “Loads” बताती है, क्योंकि “Claude Desktop ऐप में Cowork अपने सेशन Claude Code पर चलाता है”; mods पेज Cowork को सूचीबद्ध नहीं करते, और मैंने इसका परीक्षण नहीं किया है। वहाँ संगठन का नियंत्रण कमज़ोर है: Cowork सेशन में, Claude Code “claude.ai एडमिन कंसोल से सर्वर-मैनेज्ड सेटिंग्स कभी नहीं लाता, भले ही यूज़र Team या Enterprise अकाउंट से साइन इन करे”, और रिमोट Cowork सेशन्स में पढ़ने के लिए कोई डिवाइस पॉलिसी नहीं होती।

क्या रोल आउट हो रहा है। Cowork को Claude में मिलाया जा रहा है: हेल्प सेंटर अब कहता है “Claude Cowork अब सिर्फ़ Claude है”, पहले Pro और Max पर, जबकि Team और Enterprise “चैट और Claude Cowork को वैसे ही रखेंगे जैसे वे आज हैं”। 6 October 2026 को, Pro और Max पर नए Cowork टास्क क्लाउड पर चले जाएँगे। और प्रोजेक्ट्स का एक नया वर्ज़न Pro और Max पर पब्लिक बीटा में है, जिसकी शुरुआत Claude Code से हुई है, और बाद में चैट, Cowork, Team और Enterprise आएँगे; इसमें, “एक प्रोजेक्ट एक बातचीत है” जिसे Claude समानांतर थ्रेड्स में बाँट देता है। यह अभी भी एक ही स्तर है: “एक प्रोजेक्ट एक यूज़र का होता है”, और “बीटा के दौरान प्रोजेक्ट्स के लिए संगठन-स्तरीय कोई नियंत्रण नहीं हैं।”

तो पेड़ Anthropic के लिए कोई नया विचार नहीं है। यह कोड के लिए फोल्डर के रूप में और Slack के लिए चैनल के रूप में मौजूद है, और दोनों में संगठन पहले आता है। जिस जगह कोई फर्म अपना काम दर्ज करती है, यानी प्रोजेक्ट, उसका न तो कोई पैरेंट है और न ही उसके ऊपर कोई लाइन। Anthropic के दो अन्य ऑफ़र भी इसी दिशा में इशारा करते हैं और इस आर्टिकल के दायरे से बाहर हैं: Claude for Government सेटिंग्स को टेनेंट, ग्रुप और संगठन श्रृंखला के ज़रिए सुलझाता है, और थर्ड-पार्टी प्रोवाइडर्स पर Claude Desktop में प्रति-ग्रुप नीतियाँ बीटा में हैं।

2. यह क्यों मायने रखता है

प्रोजेक्ट्स कंटेनर नहीं होते। एक असली काम एक कंटेनर होता है। इसमें एक कुंजी (जॉब नंबर), एक पैरेंट (इसका कार्य-क्षेत्र), एक जीवनचक्र (खुला, बंद, साल के हिसाब से आर्काइव किया गया), एक फोल्डर, एक क्लाइंट, लोग, नियम और डिलिवरेबल्स होते हैं। किसी Claude प्रोजेक्ट में फ्री-टेक्स्ट नाम होता है, कोई कुंजी नहीं, कोई पैरेंट नहीं और कोई चिल्ड्रन नहीं, और इसका दस्तावेज़ित जीवनचक्र आर्काइव करना और डिलीट करना है। Cowork किसी प्रोजेक्ट को लोकल फोल्डर से बाँध सकता है, लेकिन वह भी हाथ से, एक बार में एक प्रोजेक्ट, बिना किसी कुंजी पैटर्न और बिना किसी पैरेंट के। कोई कार्य-क्षेत्र साल में सैकड़ों काम खोल सकता है। इससे दो बुरे विकल्प बचते हैं: हर काम के लिए एक हाथ से बनाया गया Claude प्रोजेक्ट, जिसमें नियमों की अपनी अलग कॉपी हो, या हर कार्य-क्षेत्र के लिए एक प्रोजेक्ट, जहाँ अलग-अलग क्लाइंट्स का संदर्भ एक साथ रखा हो।

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

कॉपियाँ भटक जाती हैं। एक प्रोजेक्ट में कोई नियम ठीक करें और बाकी पुराना वर्ज़न रखे रहते हैं। हर प्रोजेक्ट फिर भी अपनी लोकल जाँच पास कर लेता है। यह बेमेलपन तभी सामने आता है जब कोई प्रोजेक्ट्स की एक साथ तुलना करता है, और नियंत्रित (regulated) काम में यह आमतौर पर कोई ऑडिटर होता है। इंफ्रास्ट्रक्चर टीमें इस विफलता को अच्छी तरह जानती हैं। Firefly के 2026 के शोध में, लगभग एक तिहाई उत्तरदाताओं ने कॉन्फ़िगरेशन ड्रिफ्ट को महँगी प्रोडक्शन घटनाओं से जोड़ा, और लगभग पाँच में से एक के पास इसे पहचानने या ठीक करने की कोई प्रक्रिया नहीं थी।

आइडेंटिटी भी सपाट है। कई लोग एक से ज़्यादा संगठनों में काम करते हैं, और हर एक को अपना अलग सील किया हुआ संदर्भ चाहिए। उनमें से किसी एक के अंदर, चैट और Cowork में, कनेक्टर अकाउंट किसी व्यक्ति का होता है, किसी ब्रांच का नहीं। Enterprise रोल्स तय कर सकते हैं कि कोई ग्रुप किन कनेक्टर्स का उपयोग कर सकता है, और कोई एडमिन पूरे संगठन के लिए एक बार किसी कनेक्टर को अधिकृत कर सकता है; एक कस्टम कनेक्टर तो सभी के लिए एक साझा क्रेडेंशियल भी रख सकता है (बीटा में)। दोनों ही स्थितियों में अकाउंट व्यक्ति का या संगठन का होता है, कभी किसी ब्रांच का नहीं: दो क्लाइंट्स की सेवा देने वाला कोई सलाहकार हर क्लाइंट की Drive को उस क्लाइंट के प्रोजेक्ट्स से नहीं बाँध सकता। साझा प्रोजेक्ट्स इसे और तीखा बना देते हैं: “कनेक्टर्स केवल प्राइवेट प्रोजेक्ट्स में उपलब्ध होते हैं।” Claude Tag दिखाता है कि दूसरा डिज़ाइन संभव है, जिसमें कोई सर्विस अकाउंट किसी Slack चैनल से जुड़ा होता है, और यह दिखाता है कि यह कहाँ रुकता है — प्रोजेक्ट पर। Anthropic का Google कनेक्टर पेज एक जुड़े हुए Google अकाउंट का वर्णन करता है, और इसे बदलने का दस्तावेज़ित तरीका है डिस्कनेक्ट करके दोबारा कनेक्ट करना; तीन खुले इश्यू (नीचे) एक से ज़्यादा अकाउंट की माँग करते हैं। यह सीमा व्यक्ति के दिमाग में रहती है, और यह ठीक उसी तरह की मैन्युअल सीमा है जो बिना शोर मचाए विफल हो जाती है।

कोई नहीं देख सकता कि कौन सा नियम लागू हुआ। Claude Enterprise एडमिन्स को अनुमतियों के लिए “View effective role” दिखाता है, और Claude Code का /context बताता है कि कौन सी मेमोरी फाइलें लोड हुईं। कोई Claude Code mod अब अपना खुद का पेन बना सकता है, इसलिए effective-instructions व्यू ऐसी चीज़ है जिसे कोई भी वहाँ बना सकता है। Claude Tag हर कनेक्टर और रिपॉज़िटरी को उस स्कोप के साथ लेबल करता है जिससे उसे इनहेरिट किया गया था, लेकिन निर्देशों के लिए इसके दस्तावेज़ कहते हैं कि “Claude से उसके एडमिन निर्देशों को दोहराने के लिए कहें”। कोई भी सरफेस यह नहीं दिखाता कि किसी दिए गए जवाब के लिए कौन सा निर्देश किस लेयर से आया। स्रोत जानकारी (provenance) के बिना कोई ऑडिट ट्रेल नहीं होता, और ऑडिट ट्रेल के बिना कोई क्वालिटी सिस्टम नहीं होता।

लोग इसके कुछ हिस्सों की माँग कर रहे हैं। Anthropic के पब्लिक इश्यू ट्रैकर (github.com/anthropics/claude-code) में खुले इश्यू, 2026-10-01 को जाँचे गए:

एक सातवाँ, #47741, संगठन-प्रबंधित CLAUDE.md की माँग करता था और इसे बंद कर दिया गया क्योंकि Claude Code में यह पहले से है। बात यही है: लेयर्स Code और Slack में मौजूद हैं, और इश्यू उनकी माँग वहाँ कर रहे हैं जहाँ प्रोजेक्ट्स हैं।

3. इसकी कीमत क्या है, और टोकन क्या छिपाता है

3.1 टोकन बाधा नहीं हैं

ज़्यादा लेयर्स का मतलब हर संदेश के साथ ज़्यादा संदर्भ हो सकता है, और AI की बिलिंग टोकन के हिसाब से होती है। यह व्याख्या केवल आंशिक रूप से सही है। उपयोग-आधारित Enterprise प्लान्स पर, उपयोग की बिलिंग API दरों पर होती है, इसलिए ज़्यादा संदर्भ का मतलब ज़्यादा राजस्व है, कम नहीं। Team पर, सीटें तय होती हैं जब तक कि अतिरिक्त उपयोग चालू न किया जाए, और अतिरिक्त टोकन इस रूप में दिखते हैं कि सदस्य अपनी साप्ताहिक सीमा तक जल्दी पहुँच जाते हैं। और Claude Code, जिसकी बिलिंग उन्हीं टोकन्स पर होती है, पहले से ही चार-स्तरीय कैस्केड देता है। अगर टोकन बाधा होते, तो यह मौजूद ही नहीं होता। सेक्शन 3.2 में मापने पर, हमारे किसी भी निर्देश से पहले Claude Code का अपना सिस्टम प्रॉम्प्ट और टूल्स लगभग 30,200 टोकन्स तक पहुँचे; किसी प्रोजेक्ट के पूरे निर्देशों ने इसमें 3.5–5.2% जोड़ा।

3.2 एक व्यावहारिक उदाहरण

हर छवि पर टैग: REAL = मापा गया, या 29 September और 1 October 2026 के बीच Anthropic के दस्तावेज़ों से जाँचा गया; EST = सिमुलेटेड; IND = उदाहरण के लिए।

पहले मापा गया। मैंने एक डेमो प्रोजेक्ट पर Claude Code (claude -p, Claude Sonnet 5.5) में एक ही सवाल हर शर्त के तहत पाँच बार चलाया, और वे इनपुट टोकन्स लिए जो Claude Code ने खुद रिपोर्ट किए। मैंने इसे 30 September को Claude Code 2.1.286 पर और 1 October को 2.1.287 पर चलाया; निर्देशों की संख्या एकसमान थी। बिना किसी प्रोजेक्ट निर्देश वाले रन को घटाने पर पता चलता है कि हर लेआउट की क्या कीमत है:

दो चीज़ें जो नीचे दिया गया सिमुलेशन नहीं दिखा सका। समान नियमों के लिए कैस्केड, कंपाइल की गई फाइल से 224 टोकन ज़्यादा खर्च करता है: हर अतिरिक्त फाइल में ओवरहेड होता है, यहाँ हर स्तर की फाइल पर ऐप का अपना मार्कर और हेडिंग, साथ ही Claude Code द्वारा लोड की गई हर फाइल के आसपास की फ्रेमिंग। ज़्यादा स्तर का मतलब ज़्यादा ओवरहेड। और Claude Code ने वास्तव में पब्लिक टोकनाइज़र के अनुमान से 21–26% ज़्यादा लोड किया, यहाँ तक कि × 1.30 के साथ भी; इस अंतर का कुछ हिस्सा वही प्रति-फाइल ओवरहेड है। अनुपात इसे झेल लेते हैं; पूर्ण डॉलर के आँकड़े नहीं, इसलिए सिमुलेशन के डॉलर को कम मानकर पढ़ें।

फिर फर्म के स्तर पर सिमुलेट किया गया। मैंने एक उदाहरण फर्म के लिए एक महीने के इंस्ट्रक्शन टोकन्स सिमुलेट किए: तीन कार्य-क्षेत्रों में 40 लोग, 250 सक्रिय प्रोजेक्ट्स, प्रति लाइन छह रिपोर्ट प्रकार, प्रति व्यक्ति प्रति कार्यदिवस पाँच के सेशन्स में 35 संदेश, कुल 29,400 संदेश। टोकन आकार नमूना निर्देश टेक्स्ट पर Anthropic के पब्लिक लेगेसी टोकनाइज़र (जिसे Anthropic खुद Claude 3 और बाद के लिए “बहुत मोटा अनुमान” कहता है) से गिने गए और Claude 4.7+ टोकनाइज़र के लिए 1.30 से बढ़ाए गए। संगठन ब्लॉक को 597-कैरेक्टर के नमूने से 3,000-कैरेक्टर की सीमा तक एक्सट्रापोलेट किया गया है, और लाइन मैनुअल 953-कैरेक्टर के नमूने का तीन गुना है। कीमतें Claude Sonnet 5.5 की सूची कीमतें हैं (इनपुट $2, 5-मिनट कैश राइट $2.50, कैश रीड $0.20 प्रति मिलियन टोकन)। प्रॉम्प्ट कैश पाँच मिनट तक रहता है और हर हिट पर रिफ्रेश होता है।

• सपाट (आज का जुगाड़): संगठन ब्लॉक, फिर हर प्रोजेक्ट की लाइन मैनुअल की अपनी कॉपी, सभी छह रिपोर्ट टेम्प्लेट्स और प्रोजेक्ट की विशिष्टताएँ।

• पेड़: संगठन, लाइन, केवल उपयोग में आ रहा रिपोर्ट टेम्प्लेट, फिर प्रोजेक्ट की विशिष्टताएँ, सबसे ज़्यादा साझा किए गए को पहले कंपाइल करते हुए।

तालिका के पीछे के आकार: संगठन ब्लॉक 830 टोकन (3,000 कैरेक्टर), लाइन मैनुअल 729, एक रिपोर्ट टेम्प्लेट 147, प्रोजेक्ट विशिष्टताएँ 98 (राउंडेड; कुल राउंडिंग से पहले गिने गए थे)। सिमुलेशन Claude के अपने सिस्टम प्रॉम्प्ट को नज़रअंदाज़ करता है, जो संगठन ब्लॉक से पहले आता है।

दो ईमानदार चेतावनियाँ। पहली, पेड़ अपने आप में टोकन नहीं बचाता। −29% टाइप किए गए टास्क से आता है: केवल लिखी जा रही रिपोर्ट का टेम्प्लेट लोड होता है, सभी छह नहीं। −62% ज़्यादातर सबसे ज़्यादा साझा की गई लेयर्स को पहले कंपाइल करने से आता है, ताकि सैकड़ों प्रोजेक्ट्स एक बाइट-समान प्रीफ़िक्स साझा करें: केवल क्रम बदलने से, जबकि सभी छह टेम्प्लेट अभी भी लोड हो रहे हैं, साझा-कैश की लागत $36 से $18 (−51%) हो जाती है, और टाइप किए गए टास्क बाकी बचाते हैं। यह दूसरी बचत तभी मौजूद है जब कैश यूज़र्स के बीच साझा हो। Claude API पर, कैश संगठनों के बीच अलग होते हैं और एक के भीतर प्रति-वर्कस्पेस, इसलिए एक वर्कस्पेस के भीतर अनुरोधों में समान प्रीफ़िक्स दोबारा इस्तेमाल होते हैं; claude.ai के लिए यह दस्तावेज़ित नहीं है। यह Claude Code में वैसे नहीं होता जैसे वह मिलता है: वहाँ “कैश प्रभावी रूप से एक मशीन और डायरेक्टरी तक सीमित होता है”, इसलिए दो प्रोजेक्ट फोल्डर्स में दो लोग एक-दूसरे के कैश से चूक जाते हैं। आखिरी कॉलम को यह समझें कि चैट में कोई नेटिव लेयर क्या हासिल कर सकती है, न कि यह कि आज कुछ उपलब्ध है। एक उचित आपत्ति: Skills पहले से ही माँग पर लोड होती हैं, इसलिए कोई सपाट वर्कस्पेस जो अपने टेम्प्लेट्स को Skills में ले जाता है, वह आज ही −29% का कुछ हिस्सा पा लेता है। चैट और Cowork में Skills में जो कमी है वह है स्कोप और इनहेरिटेंस: कोई स्किल एक लाइन की नहीं हो सकती और उस लाइन के प्रोजेक्ट्स तक नहीं बह सकती। (Claude Code में, किसी सबफोल्डर की स्किल उन सेशन्स के लिए लोड होती है जो उसमें या उसके नीचे शुरू होते हैं।) दूसरी, ये केवल इंस्ट्रक्शन टोकन्स हैं, और इस स्तर पर कैशिंग के आधार पर इनकी लागत $14 से $149 प्रति माह तक होती है। असली बिल में बातचीत का इतिहास और आउटपुट हावी होते हैं। पेड़ के पक्ष में मज़बूत तर्क सटीकता है और, Team पर, क्षमता। यह बिल नहीं है।

ऊपर दिया गया मापन, माने गए आकारों के बजाय, Claude Code में एक असली पेड़ पर टाइप किए गए टास्क प्रभाव को दोहराता है: कैस्केड के रूप में −20% और कंपाइल किए गए रूप में −34%, जबकि सिमुलेशन में −29% था। एक ही टास्क प्रकार वाली लाइन टाइप किए गए टास्क से कुछ नहीं बचाएगी।

3.3 असली Claude से वही जवाब

मैंने Claude Code से एक ही सवाल चालीस बार पूछा: चार शर्तों में से हर एक के तहत दस स्वतंत्र जवाब, एक दिन के अंतर पर पाँच-पाँच के दो बैच में। सवाल यह था कि सबग्रेड पर फील्ड डेंसिटी टेस्ट पास होता है या नहीं, 112.3 pcf बनाम 115.8 pcf अधिकतम शुष्क घनत्व और 98% आवश्यकता के साथ। निर्देश या तो फर्म के छह नियम थे या एक-पंक्ति वाला “helpful assistant” प्रॉम्प्ट, और भाषा अंग्रेज़ी या स्पेनिश थी। सभी चालीस जवाबों ने एक ही फैसला दिया: 97.0%, फेल।

Claude Code दो आउटपुट संख्याएँ रिपोर्ट करता है: बिल किए गए टोकन, और उनमें से कितने सोचने (thinking) में लगे जिन्हें पाठक कभी नहीं देखता।

चार निष्कर्ष:

• फर्म के नियमों ने जवाबों को स्क्रीन पर 1.4 गुना और बिल पर 1.8–1.9 गुना लंबा कर दिया। दिखने वाला अतिरिक्त हिस्सा वे flags, standards और limitations सेक्शन थे जिनकी नियमों ने माँग की थी। किसी क्वालिटी सिस्टम में, यही वह हिस्सा है जो कीमती है।

• फर्म के नियमों के तहत, बिल किए गए आउटपुट का एक तिहाई से ज़्यादा हिस्सा अदृश्य था। बिल किए गए आउटपुट टोकन्स में से 37% सोचने में लगे, जबकि सादे प्रॉम्प्ट के तहत यह 16% था। अंग्रेज़ी में, पाठक 447 टोकन देखता है और 711 के लिए भुगतान करता है।

• स्पेनिश की लागत अंग्रेज़ी के दिखने वाले टोकन्स की 1.2 गुना थी, जबकि जवाब शब्दों में 4% के भीतर समान लंबाई के थे। इसी तरह मापने पर, फर्म के नियमों ने स्पेनिश में लिखे जाने पर 1.53 गुना इनपुट टोकन लिए।

• एक ही फैसले के लिए 317 से 953 टोकन तक बिल किया गया, सबसे लंबे जवाब के लिए सबसे छोटे की तुलना में तीन गुना ज़्यादा। प्रति-टोकन बिलिंग सख्ती और भराव में फर्क नहीं बता सकती। स्वीकृति मानदंड (Acceptance criteria) बता सकते हैं।

ये अनुपात पाँच-पाँच के बैच के बीच बदलते हैं। फर्म के नियमों के लिए ऑन-स्क्रीन अनुपात पहले बैच में 1.43–1.52 और दूसरे में 1.27–1.31 था; बिल किया गया अनुपात 1.78–1.82 और फिर 1.70–2.05 था; स्पेनिश अनुपात 1.29–1.38 और फिर 1.14–1.18 था। दिशा कभी नहीं बदली। यह आकार एक सार्थक अंक (significant figure) तक सही है।

विधि: 2026-09-30 को Claude Code 2.1.286 और 2026-10-01 को 2.1.287, claude -p --output-format json, Claude Sonnet 5.5। हर टूल को अस्वीकृत किया गया और व्यक्तिगत ~/.claude फाइलों को बाहर रखा गया, ताकि शर्तों के बीच केवल बताए गए निर्देश ही अलग हों। टोकन गिनती Claude Code की अपनी उपयोग रिपोर्ट है, जिसमें thinking_tokens शामिल हैं; मासिक लागत बिल किए गए औसत पर Sonnet 5.5 के $10 प्रति मिलियन आउटपुट टोकन लागू करती है। मापन स्क्रिप्ट, दोनों बैच, संयुक्त आँकड़े और हर जवाब लेखक के पास रखे गए हैं और अनुरोध पर उपलब्ध हैं। इस आर्टिकल के पहले वर्ज़न ने इन संख्याओं का अनुमान सबएजेंट्स और पब्लिक टोकनाइज़र से लगाया था; वे अनुमान अब अप्रचलित हैं।

3.4 जब नियम टकराते हैं, तो शब्दावली फैसला करती है

Anthropic के दस्तावेज़ मानते हैं कि विरोधाभासी निर्देशों को “मनमाने ढंग से” सुलझाया जा सकता है। मैंने उस तरह के एक विरोधाभास का परीक्षण किया जो किसी गायब लाइन लेयर से पैदा होता है। संगठन नियम ने U.S. customary units का उपयोग करने को कहा; एक प्रोजेक्ट नियम ने SI में घनत्व रिपोर्ट करने को कहा। मैंने उन्हें वैसे रखा जैसे कोई पेड़ रखता: संगठन नियम को स्टोरेज रूट पर CLAUDE.md में, प्रोजेक्ट नियम को प्रोजेक्ट फोल्डर में CLAUDE.md में, दोनों को Claude Code के अपने कैस्केड ने लोड किया। फिर मैंने वही सेटअप चलाया जिसमें संगठन नियम को केवल शब्दों में लागू (enforced) बताया गया: उसके लेबल में ENFORCED टैग और एक जोड़ा गया वाक्य, “यह नियम लागू है: कोई लाइन या प्रोजेक्ट नियम इसे ओवरराइड नहीं कर सकता।” हर सेटअप 30 September को दस बार और 1 October को दस बार और चलाया गया।

यह मनमाना नहीं था। कुछ भी घोषित न होने पर, Claude ने हर बार निकटतर, अधिक विशिष्ट नियम को चुना। बीस में से चौदह जवाबों ने कारण बताया (“वह नियम फर्म-व्यापी U.S. customary नियम से अधिक विशिष्ट है”, या कि यह फर्म के नियम को ओवरराइड करता है); पाँच ने केवल प्रोजेक्ट नियम का हवाला दिया और कभी यह नहीं बताया कि फर्म का नियम इससे असहमत था। जब बाध्यकारी होने की घोषणा शब्दों में की गई, तो संगठन नियम हर बार जीता, और हर जवाब ने कहा कि लागू किया गया फर्म नियम प्राथमिकता लेता है। दूसरे बैच ने इकाइयों को दोहराया, हर बार 10 में से 10, और दोनों पंक्तियों के बीच का अंतर संयोग से कहीं ज़्यादा है (Fisher’s exact test, p < 0.0001)। व्याख्याएँ उतनी अच्छी नहीं रहीं: पहले बैच में दस में से नौ जवाबों ने बताया कि प्रोजेक्ट नियम क्यों जीता, दूसरे में दस में से पाँच ने।

यह मॉडल के लिए अच्छी खबर है और वर्कस्पेस के लिए बुरी। प्राथमिकता (precedence) मौजूद तो है, लेकिन वह नियमों की शब्दावली में छिपी होती है — जिसे कोई भी व्यक्ति किसी भी लेयर को एडिट करते समय बदल सकता है, और जिसे कोई भी प्राथमिकता के फैसले के तौर पर रिव्यू नहीं करता। और जब निचला नियम जीता, तो एक-चौथाई जवाबों ने पाठक को यह बताया ही नहीं कि किसी ऊपरी नियम को दरकिनार कर दिया गया था। इस आर्टिकल के पहले वर्ज़न में किए गए एक पायलट रन में, जहाँ कैस्केड की जगह दोनों नियम एक ही प्रॉम्प्ट में थे, नतीजे सिर्फ उनके क्रम बदलने से भी बदल गए (org rule पहले: 5 में से 5 SI; org rule आखिर में: 5 में से 2 SI, और 5 में से 3 ने दोनों यूनिट दे दिए या पूछ लिया कि कौन सा लागू करना है)।

किसी भी मॉडल से ऐसे विवाद का निपटारा करने की उम्मीद नहीं रखनी चाहिए जिसे संगठन ने नियम लिखते वक्त ही पकड़ लिया होता। Claude Code के पास दो आधे-अधूरे समाधान हैं। /doctor prompt-audit Claude से कहता है कि वह उन इंस्ट्रक्शन फाइलों को ढूँढे जो एक-दूसरे से टकराती हैं, जब कोई इंसान इसे चलाता है। और 1 अक्टूबर से एक mod कोड में क्रम लागू कर सकता है: संगठन के mods किसी व्यक्ति के mods से पहले चलते हैं, और जहाँ बिल्ट-इन गार्ड लोड होता है, वहाँ deny नियम व्यक्ति के mod पर भारी पड़ते हैं। इनमें से कोई भी इंस्ट्रक्शन टेक्स्ट को कवर नहीं करता। इंस्ट्रक्शन फाइलें अब भी आपस में जोड़ी जाती हैं, और डॉक्युमेंटेशन इसके नतीजे को तीन तरीकों से बताता है: Claude “शायद मनमाने ढंग से कोई एक चुन ले”; जब कोई यूज़र नियम और प्रोजेक्ट नियम टकराते हैं, “Claude दोनों में से किसी एक का पालन कर सकता है”; और “जब इंस्ट्रक्शन्स आपस में टकराते हैं, तो Claude उन्हें सुलझाने के लिए अपने विवेक का इस्तेमाल करता है।” यहाँ उसी विवेक का नतीजा बीस में से बीस बार जो दिखा, वही है। Claude Tag अपने तीनों स्कोप्स के लिए एक क्रम तय करता है, और नतीजे को “गाइडेंस, कोई सख्त गार्डरेल नहीं” कहता है। रेफरेंस इम्प्लीमेंटेशन का चेक ठीक इसी बदलाव को रिजेक्ट कर देता है, “R-22 sets units.density=SI; R-01 (org:firm) enforces US”, इससे पहले कि कुछ भी Claude तक पहुँचे, और enforced नियम का एक फील्ड है, उसके अंदर लिखा कोई वाक्य नहीं।

इंस्ट्रक्शन डेंसिटी इसे और बिगाड़ देती है। IFScale बेंचमार्क (2025) में, Claude Sonnet 4 की सटीकता 10 साथ-साथ चलने वाले इंस्ट्रक्शन्स पर 100% से गिरकर 500 पर 42.9% रह गई।

3.5 क्या कंप्यूट या एनर्जी ज्यादा सही यूनिट होगी?

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

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

इसमें असली दिक्कतें भी हैं। ग्राहक बिना किसी स्टैंडर्ड और ऑडिटर के इसे वेरिफाई नहीं कर सकता। असली एनर्जी हार्डवेयर, डेटा-सेंटर की एफिशिएंसी, बैचिंग और ग्रिड पर निर्भर करती है। और Anthropic हर रिक्वेस्ट की एनर्जी पब्लिश नहीं करता; मुझे सिर्फ थर्ड-पार्टी अनुमान मिले। सबसे अहम बात, कंप्यूट अभी भी एक इनपुट है। यह नहीं बताता कि जवाब सही था या नहीं।

मेरा निष्कर्ष तीन अलग-अलग लेयर्स का है:

1. टोकन या नॉर्मलाइज़्ड कंप्यूट यूनिट में बिल करें।

1. हर टास्क और हर नोड की एनर्जी जाहिर करें।

1. हर वेरिफाइड नतीजे की लागत के हिसाब से मैनेज करें।

Team के लिए, न्यूनतम कदम है साप्ताहिक सीमा को किसी तय यूनिट में पब्लिश करना। प्रति-सेशन अलाउंस “Pro plan के प्रति-सेशन उपयोग अलाउंस का 1.25x” बताया गया है; साप्ताहिक सीमा के लिए कोई संख्या पब्लिश ही नहीं की गई है। इनमें से किसी का भी बजट नहीं बन सकता।

जैसा FinOps Foundation कहता है, “टोकन बिलिंग यूनिट है, वैल्यू यूनिट नहीं।” वैल्यू को परिभाषित करने लायक एक हाइरार्की ही बनाती है, क्योंकि वहीं स्वीकृति मानदंड (acceptance criteria) रह सकते हैं।

3.6 इसके न बन पाने के ज्यादा संभावित कारण

1. अंतर्निहित प्राथमिकता (Implicit precedence)। Anthropic की अपनी डॉक्युमेंटेशन मानती है कि सीधे तौर पर टकराने वाले इंस्ट्रक्शन्स अलग-अलग व्यवहार पैदा कर सकते हैं, और सेक्शन 3.4 दिखाता है कि प्राथमिकता वही तय होती है जो नियमों की शब्दावली कहती है। लेयर्स को एक के ऊपर एक रखने से विवाद कई गुना बढ़ जाते हैं, और डेंसिटी बढ़ने पर इंस्ट्रक्शन-फॉलोइंग बिगड़ती है: IFScale बेंचमार्क (2025) में, टेस्ट किए गए सबसे बेहतरीन मॉडल्स भी 500 साथ-साथ चलने वाले कीवर्ड इंस्ट्रक्शन्स पर सिर्फ 68% सटीकता तक पहुँच पाए (सेक्शन 3.4 में उद्धृत बेंचमार्क)।

1. परमिशन इनहेरिटेंस। अगर नॉलेज किसी ट्री में नीचे की ओर जाता है, तो एक्सेस को भी जाना होगा। इसका मतलब है हर लेयर के नीचे परमिशन मॉडल को दोबारा बनाना।

1. स्थिर लेयर्स की बजाय मेमोरी और रिट्रीवल को तरजीह देना।

1. कंज्यूमर-फर्स्ट सरलता। कोड टूल्स को फाइलसिस्टम से एक ट्री मुफ्त में मिल जाती है। चैट प्रोडक्ट्स को इसे खुद गढ़ना पड़ता है।

Anthropic ने सार्वजनिक रूप से नहीं बताया है कि Claude chat और Cowork में हाइरार्की क्यों नहीं है। इस सेक्शन की हर बात उन चीज़ों से निकाला गया अनुमान है जो शिप हो चुकी हैं।

4. रेफरेंस मॉडल

यह डिज़ाइन उन सिस्टम्स से उधार लिया गया है जिन्होंने यह समस्या पहले ही सुलझा ली है: क्लाउड रिसोर्स हाइरार्की (AWS Organizations, Google Cloud Org Policy, Azure management groups), डायरेक्टरी पॉलिसी (Active Directory Group Policy), और Claude Code का अपना CLAUDE.md कैस्केड। नोड्स के बीच के रिश्तों को पाँच शब्दों से समझाया गया है: contains, inherits, uses, sealed और shared।

4.1 वह ट्री माउंट करें जो संगठन के पास पहले से है

लोगों को AI वर्कस्पेस के अंदर अपना संगठन दोबारा बनाने पर मजबूर न करें। फाइल सर्वर या डॉक्युमेंट सिस्टम पहले से ही सच्चाई का स्रोत (source of truth) है। एक रास्ता अपनाएँ:

जॉब नंबर 26GT301 पहले से ही ट्री को एनकोड करता है: साल, काम की लाइन, क्रम। वर्कस्पेस को यह स्ट्रक्चर माउंट करना चाहिए, कॉपी नहीं।

4.2 नियम वाले नोड, ग्रुपिंग नोड, प्रोजेक्ट और टास्क

• नियम वाले नोड: संगठन, काम की लाइन, प्रोजेक्ट, टास्क। हर एक में वही तीन चीज़ें होती हैं: context (इंस्ट्रक्शन्स और नॉलेज), policy (कौन से टूल्स, डेटा और कनेक्टर की अनुमति है), और identities (इससे जुड़े कनेक्टर अकाउंट्स)।

• ग्रुपिंग नोड: सीरीज़, साल, क्षेत्र। इनमें कोई नियम नहीं होते। ये नेविगेशन, रिटेंशन और लाइफसाइकिल के लिए होते हैं। इन्हें अलग रखने से नियमों की ट्री छोटी रहती है, तीन से चार लेवल, जैसा Microsoft की मैनेजमेंट ग्रुप्स के लिए अपनी गाइडेंस में सलाह है (“तीन से चार लेवल से ज़्यादा नहीं”)।

• प्रोजेक्ट एक की-आधारित कंटेनर है। यह अपने आप बनता है: जब लाइन के की पैटर्न से मेल खाता कोई फोल्डर आता है (जैसे लाइन के रूट के नीचे {YY}GT{NNN}_{Name}), तो एक प्रोजेक्ट नोड बनता है, अपनी लाइन से इनहेरिट करता है, और उसे सिर्फ उसी फोल्डर तक सीमित कनेक्टर एक्सेस मिलता है। इसमें सिर्फ वही होता है जो उसकी लाइन से अलग है: सदस्य, क्लाइंट, स्पेसिफिकेशन्स। यह open से closed और फिर archived में जाता है (डायग्राम 2)।

• टास्क टाइप्ड होता है। इसका प्रकार लाइन के कैटलॉग से आता है (एक डेंसिटी रिपोर्ट, एक बोरिंग लॉग)। इस प्रकार में एक टेम्पलेट और स्वीकृति मानदंड होते हैं। आउटपुट फर्म के नामकरण नियम के तहत वापस प्रोजेक्ट फोल्डर में रख दिया जाता है, और एक रिव्यूअर इसे स्वीकार करता है। आज Skills वह सबसे करीबी चीज़ है जो Claude के पास टास्क प्रकारों के रूप में है। Enterprise पर इन्हें किसी ग्रुप के साथ शेयर किया जा सकता है, लेकिन वह बाँटना है, इनहेरिटेंस नहीं: किसी ब्रांच से नीचे कुछ नहीं बहता।

यह पुनरावृत्ति (recursion) सोच-समझकर रखी गई है। Stafford Beer का Viable System Model इसे सीधे कहता है: “एक पुनरावर्ती संगठनात्मक संरचना में, कोई भी व्यवहार्य सिस्टम एक व्यवहार्य सिस्टम को अपने अंदर रखता है, और खुद किसी व्यवहार्य सिस्टम के अंदर होता है।”

4.3 एक मुख्य पैरेंट, साथ में ओवरले

Christopher Alexander ने 1965 में तर्क दिया था कि “शहर कोई पेड़ नहीं है।” असली संरचनाएँ एक-दूसरे पर चढ़ती हैं। कोई क्लाइंट, किसी एजेंसी का स्पेसिफिकेशन या कोई टास्क प्रकार कई काम की लाइनों में फैल सकता है। इसलिए हर नोड का एक मुख्य पैरेंट होता है, और आड़ा-तिरछा जाने वाले नियम सेट ओवरले (uses) के रूप में जुड़ते हैं। विवाद हर बार एक ही तरीके से सुलझते हैं: deny जीतता है, अन्यथा सबसे नज़दीकी नोड जीतता है।

4.4 दो चैनल, दो अर्थ

यह डिज़ाइन का दिल है, और यहीं ज़्यादातर हाइरार्की गलत हो जाती हैं।

• Context जुड़ता है। इंस्ट्रक्शन्स और नॉलेज को रूट से नीचे तक मिलाया जाता है, जैसा CLAUDE.md करता है।

• Policy डिफॉल्ट रूप से deny होती है। किसी टूल या कनेक्टर की अनुमति तभी है जब रूट से लेकर पूरे रास्ते में allow मौजूद हो, और ऊपर कहीं भी स्पष्ट deny हो तो वही जीतती है, जैसा AWS Service Control Policies में होता है। कोई पैरेंट किसी नियम को enforced मार्क कर सकता है, और कोई चाइल्ड उसे रोक नहीं सकता, जैसा Group Policy में होता है।

इन दोनों को मिलाना एक क्लासिक गलती है। सलाह देने वाला context घुलना चाहिए। लागू होने वाली policy नहीं।

4.5 मॉडल के पढ़ने से पहले कंपाइल करें

आज, टकराने वाले इंस्ट्रक्शन्स को मॉडल जवाब देते वक्त सुलझाता है। समाधान एक effective-instructions compiler है जो मॉडल के कुछ भी देखने से पहले चलता है:

1. रूट से लीफ तक context मिलाएँ।

1. policy लागू करें: deny जीतता है, और allow को पूरे रास्ते पर मान्य होना चाहिए।

1. पैरेंट्स के enforced नियमों का सम्मान करें।

1. हर नियम पर एक ID और उसकी लेयर की मोहर लगाएँ।

1. ब्लॉक को इस आधार पर क्रमबद्ध करें कि हर हिस्सा कितना व्यापक रूप से शेयर किया गया है, और हर लेयर के लिए एक टोकन बजट लागू करें।

विवाद इस स्टेज तक पहुँचते ही नहीं: उन्हें पहले ही रिजेक्ट कर दिया जाता है, जब कोई नियम लिखा जाता है, और मंजूरी लेखक के अलावा किसी और से आती है (डायग्राम 3, निचला लेन)।

चूँकि विवाद कंपाइल टाइम पर सुलझ जाते हैं, आउटपुट को गहराई के बजाय इस आधार पर क्रमबद्ध किया जा सकता है कि हर हिस्सा कितना व्यापक रूप से शेयर किया गया है: संगठन, लाइन, टास्क-प्रकार का टेम्पलेट, फिर प्रोजेक्ट की खास बातें। यह क्रम कैश हिट्स को अधिकतम करता है (सेक्शन 3.2)। यह Anthropic के चार कैश ब्रेकपॉइंट्स पर बैठता है, जिसमें हर लेयर का एक टोकन बजट होता है, हालाँकि व्यवहार में एक ब्रेकपॉइंट खुद बातचीत के लिए चाहिए हो सकता है।

4.6 लोगों से नहीं, ब्रांच से जुड़ी पहचान

कनेक्टर की पहचान (अकाउंट, टेनेंट, स्कोप) किसी व्यक्ति से नहीं, बल्कि किसी नोड से जुड़ती है। Claude Tag Slack चैनल्स के लिए पहले से ऐसा ही करता है: एक एडमिन किसी स्कोप से एक सर्विस अकाउंट जोड़ता है, और सबसे संकरे स्कोप का क्रेडेंशियल जीतता है। यहाँ का मॉडल ठीक यही चीज़ एक लेवल नीचे माँगता है, काम की लाइन और उसके प्रोजेक्ट्स पर। दो संगठनों में काम करने वाले व्यक्ति के पास दो sealed ट्री होती हैं; वह अकाउंट नहीं, ट्री बदलता है। जब तक दोनों के मालिक स्पष्ट रूप से शेयर न करें, उनके बीच कुछ नहीं जाता। तकनीकी आधार पहले से मौजूद है: MCP ऑथराइज़ेशन स्पेसिफिकेशन audience-bound OAuth टोकन (RFC 8707 resource indicators, RFC 9728 protected resource metadata) का इस्तेमाल करता है और माँग करता है कि सर्वर “किसी अन्य टोकन को स्वीकार या ट्रांज़िट बिल्कुल न करें” (स्पेसिफिकेशन वर्ज़न 2026-07-28)।

4.7 परमिशन्स ट्री का अनुसरण करते हैं

प्रिंसिपल्स: लोग, ग्रुप्स, सर्विस अकाउंट्स, बाहरी गेस्ट (जैसे कोई क्लाइंट), और खुद एजेंट।

एजेंट कभी व्यक्ति या नोड से आगे नहीं जाता। Claude उस यूज़र की परमिशन्स के साथ काम करता है जिसने उसे बुलाया है, जो नोड की policy के साथ मिलाई जाती हैं। यह नियम या परमिशन्स नहीं बदल सकता; सिर्फ बदलाव सुझा सकता है। (आज, Claude Cowork फोल्डर इंस्ट्रक्शन्स को खुद अपडेट कर सकता है। इस मॉडल में, वह एक प्रस्ताव बन जाता है जिसे कोई मंजूर करता है।)

मूल्यांकन। ग्रांट्स सिर्फ नीचे की ओर बहते हैं, कभी ऊपर या बगल में नहीं। किसी नोड पर प्रभावी परमिशन वही है जो उसके रास्ते के रोल देते हैं, पूरी पथ पर policy जो अनुमति देती है उसके अंदर, और ऊपर के किसी भी deny को घटाकर। कोई ओवरले सिर्फ अपने कंटेंट तक एक्सेस देता है: किसी स्पेसिफिकेशन को पढ़ने से वे प्रोजेक्ट नहीं खुल जाते जो उसका इस्तेमाल करते हैं।

लाइफसाइकिल।

• Open: रोल वैसे ही लागू होते हैं जैसे दिए गए हैं।

• Closed: कोई नया टास्क नहीं, लेकिन लंबित रिव्यू पूरे हो सकते हैं।

• Archived: सबके लिए read-only; सिर्फ मालिक रीस्टोर कर सकता है, और रीस्टोर लॉग होता है।

• Sealed tree: स्पष्ट शेयर के बिना कुछ भी आर-पार नहीं जाता।

अपवाद और प्रतिनिधिमंडल (delegation)। अपवाद समय-सीमा वाले और उचित कारण सहित होते हैं, और अनुरोधकर्ता के अलावा कोई और उन्हें मंजूर करता है। वे अपने आप खत्म हो जाते हैं और उनकी गिनती होती है, क्योंकि हर ओवरराइड एक स्थायी रखरखाव द्वीप है; SharePoint की टूटी हुई इनहेरिटेंस सीमाएँ इसकी चेतावनी भरी कहानी हैं। प्रतिनिधिमंडल कभी उससे ज़्यादा नहीं दे सकता जो प्रतिनिधि के पास है। मालिक का break-glass एक्सेस मौजूद है, हमेशा लॉग होता है, और बाद में उसका रिव्यू होता है।

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

4.8 लेयर्स आपस में कैसे काम करती हैं

ट्री बनाने का फायदा तभी है जब बदलाव उसमें से गुज़रें। तीन इंटरैक्शन ज़्यादातर काम संभालते हैं (डायग्राम 5):

• नीचे धकेलना (Push down)। कोई लाइन लीड किसी नियम का नया वर्ज़न पब्लिश करता है। लाइन का हर प्रोजेक्ट अगले कंपाइल पर उसे पढ़ता है। कोई मंजूर अपवाद पुराने वर्ज़न को तब तक बनाए रखता है जब तक वह खत्म न हो जाए, और पहले से फाइल किए गए आर्टिफैक्ट्स उसी वर्ज़न पर रहते हैं जिसके साथ बने थे।

• ऊपर खींचना (Pull up)। कोई सदस्य एक प्रोजेक्ट के अंदर टेम्पलेट सुधारता है और उसे प्रस्तावित करता है। प्रस्तावक नहीं, बल्कि लाइन लीड उसे मंजूर करता है, और सहयोगी प्रोजेक्ट्स उसे इनहेरिट कर लेते हैं। आज वह सुधार उसी प्रोजेक्ट में रह जाता है जहाँ हुआ था।

• आड़ा-तिरछा (Across)। किसी एजेंसी का स्पेसिफिकेशन एक बार बदलता है। तीन लाइनों के प्रोजेक्ट्स उसके साथ रीकंपाइल होते हैं, और खुद लाइनें नहीं बदलतीं। किसी लाइन नियम से टकराव को तभी रिजेक्ट कर दिया जाता है जब अपडेट लिखा जाता है।

एक रिक्वेस्ट सारी लेयर्स को एक साथ दिखा देती है (डायग्राम 6): ट्री सदस्य के ग्रांट और प्रोजेक्ट की स्थिति जाँचती है, कंपाइलर ब्लॉक बनाता है, Claude उस प्रोजेक्ट के फोल्डर तक सीमित पहचान के ज़रिए फील्ड डेटा पढ़ता है, एक टाइप्ड आर्टिफैक्ट वापस फोल्डर में रखता है, और एक रिव्यूअर जिसे इसे लिखने वाले ने नहीं लिखा, उसे स्वीकार करता है। हर कदम लॉग में दर्ज होता है, और लागत प्रोजेक्ट की पर चार्ज होती है।

4.9 डेटा स्ट्रक्चर

प्रोविज़निंग इवेंट-ड्रिवन है: किसी लाइन के storage_root के नीचे key_pattern से मेल खाता नया फोल्डर प्रोजेक्ट नोड बनाता है। answer_log हर जवाब की उत्पत्ति और प्रति नोड लागत बताता है।

4.10 टोकन नहीं, नतीजे नापें

हर टास्क प्रकार में स्वीकृति मानदंड होते हैं: काम पूरा होने की परिभाषा। इनके होने से, AI काम की बेहतर यूनिट नापी जा सकती है:

प्रति वेरिफाइड नतीजा लागत = (टोकन लागत + रिव्यू का समय) ÷ स्वीकृत डिलिवरेबल्स

चूँकि हर जवाब किसी नोड के खिलाफ लॉग होता है, AI लागत को प्रोजेक्ट की पर उसी तरह चार्ज किया जा सकता है जैसे श्रम और सामग्री को। इसके कुछ हिस्से मौजूद हैं: Claude Tag प्रति चैनल खर्च की रिपोर्ट देता है और उसे सीमित करता है, और Claude Code की टेलीमेट्री को विभाग, कॉस्ट सेंटर या रिपॉज़िटरी के हिसाब से हाथ से टैग किया जा सकता है। लेकिन कोई भी प्रोजेक्ट की से नहीं जुड़ा, और कोई भी स्वीकृत डिलिवरेबल्स से भाग नहीं देता। ऐसी फर्म के लिए जो जॉब नंबर से बिल करती है, AI ओवरहेड की बजाय सीधी जॉब लागत बन जाती है। इंजीनियरिंग में, आप चेक किए गए, सील किए गए डिलिवरेबल के पैसे देते हैं, पेंसिल की लीड के नहीं। AI काम को भी इसी तरह नापा जाना चाहिए।

4.11 आपत्तियाँ और उनके जवाब

“Skills और plugins पहले से यही करते हैं।” कोई skill तब लोड होता है जब Claude उसे प्रासंगिक मानता है, जो प्रासंगिकता है, गारंटी नहीं। प्रोविज़निंग skill सबको देता है; Enterprise पर, इसे ले जाने वाले plugin को किसी एक ग्रुप के लिए अनिवार्य किया जा सकता है। आज chat और Cowork में काम की लाइन के सबसे करीब यही है, और यह तीन मामलों में कम पड़ता है: यह सिर्फ Enterprise के लिए है, यह प्रोजेक्ट्स की बजाय लोगों को टारगेट करता है, और किसी लाइन से उसके प्रोजेक्ट्स में नीचे कुछ नहीं बहता। ऐसा नियम जो किसी एक लाइन में हमेशा लागू होना चाहिए, वह प्रासंगिकता पहचानने पर निर्भर नहीं रह सकता।

“Mods पहले से यही करते हैं।” Claude Code में, आंशिक रूप से, 1 अक्टूबर 2026 से। कोई mod सिस्टम प्रॉम्प्ट को फिर से लिख सकता है, किसी टूल कॉल से मना कर सकता है और एक पैनल खींच सकता है, और संगठन के mods व्यक्ति के mods से पहले चलते हैं। तो इस आर्टिकल का कंपाइलर, राइट-टाइम चेक और effective-instructions व्यू आज एक mod के रूप में बनाया जा सकता है, और सेक्शन 6 यही कहता है। तीन सीमाएँ अभी भी हैं। Mods Claude chat में नहीं चलते, और Cowork में संगठन की कंसोल सेटिंग्स लागू नहीं होतीं। उनके क्रम के दो मालिक हैं, संगठन और व्यक्ति, और उनके बीच काम की कोई लाइन नहीं; Enterprise पर, किसी एक ग्रुप के लिए अनिवार्य plugin उस ग्रुप तक एक mod ले जा सकता है, लेकिन वह व्यक्ति के अपने mods में से एक की तरह चलता है, बिना किसी प्राथमिकता के। और एक mod अनसैंडबॉक्स्ड कोड है: लोगों के mods से आगे चलने के लिए, संगठन के mod को हर मशीन की किसी डायरेक्टरी में होना चाहिए, और एडमिन कंसोल से दी गई सेटिंग्स “मशीन पर डायरेक्टरी नहीं रख सकतीं।” बिना डिवाइस मैनेजमेंट वाली फर्म सबको एक mod भेज सकती है, लेकिन वह लोगों के अपने mods के बीच चलेगा, उनसे आगे नहीं। किसी फर्म को यह कहने के लिए TypeScript नहीं लिखना पड़ना चाहिए कि एक विभाग अलग यूनिट्स में रिपोर्ट करता है।

“Memory नियम सीख लेगी।” Memory ज़्यादातर Claude द्वारा, किसी एक व्यक्ति या एक प्रोजेक्ट के लिए लिखी जाती है, और कोई मालिक किसी सदस्य की memories पढ़ या एडिट नहीं सकता। किसी ऑडिटर को ऐसे नियम चाहिए जो किसी व्यक्ति ने लिखे हों, जिनके वर्ज़न हों, मंजूर हों और हर जवाब से ट्रैस किए जा सकें। Anthropic यह तीन बार पहले ही बना चुका है: परमिशन्स के लिए, “View effective role” और उसके “Granted by” लेबल के साथ; skills और plugins के लिए, वर्ज़न हिस्ट्री और एक रिव्यू स्टेप के साथ जहाँ “आप खुद को मंजूर नहीं कर सकते”; और Claude Tag के एक्सेस के लिए, उसके “Inherited from” लेबल्स के साथ। किसी प्रोजेक्ट के इंस्ट्रक्शन्स में इन तीनों में से कुछ नहीं है।

“Claude Tag पहले से यही करता है।” Slack चैनल्स के लिए, काफी हद तक हाँ, और सेक्शन 1 यही कहता है। तीन चीज़ें अभी भी गायब हैं। चैनल प्रोजेक्ट नहीं है: इसका कोई फोल्डर नहीं, कोई की नहीं, कोई लाइफसाइकिल नहीं, और “किसी चैनल को किसी Project की ओर इशारा नहीं कराया जा सकता”। ट्री तीन तय लेवल की है, इसलिए काम की लाइनों और सैकड़ों जॉब्स वाली फर्म को अपने दो लेवल चैनल नामों में चपटा करना पड़ता है। और डॉक्युमेंटेशन यह नहीं बताती कि जब कोई इंस्ट्रक्शन लिखा जाए तो टकराव की जाँच कैसे हो; स्कोप्स जोड़ दिए जाते हैं और उन्हें सुलझाने का काम मॉडल पर छोड़ दिया जाता है। अगर कुछ है, तो Claude Tag इस आर्टिकल के डिज़ाइन का सबसे मजबूत सबूत है: उसी कंपनी ने टीमों के लिए बनाते समय इनहेरिटेंस, स्कोप-बाउंड क्रेडेंशियल्स और ओरिजिन लेबल चुना।

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

“इनहेरिटेंस सुरक्षा जोखिम है।” यह है, अगर एक्सेस लापरवाही से इनहेरिट किया जाए। क्लाउड वाला जवाब यहाँ लागू होता है: allow हर लेवल पर होना चाहिए, कहीं भी deny हो तो वही जीते, Claude यूज़र और नोड के प्रतिच्छेदन (intersection) के रूप में काम करे, और Claude के अपने नियम बदलाव प्रस्ताव बन जाएँ।

“ज़्यादा लेयर्स का मतलब ज़्यादा टोकन।” सेक्शन 3.2 ने Claude Code में ठीक उल्टा नापा: फ्लैट कॉपी के मुकाबले कैस्केड के रूप में 20% कम इंस्ट्रक्शन टोकन, कंपाइल होने पर 34% कम। हर अतिरिक्त फाइल थोड़ा ओवरहेड जोड़ती है, इसलिए कंपाइल करना कैस्केड से बेहतर है। टाइप्ड टास्क उन टेम्पलेट्स को हटा देते हैं जो इस्तेमाल में नहीं हैं, और कंपाइल किए गए प्रीफिक्स प्रोजेक्ट्स में बाइट-स्तर पर एक जैसे होते हैं, इसलिए प्रॉम्प्ट कैशिंग उन्हें दोबारा इस्तेमाल कर सकती है। Claude API पर, कैश प्रति वर्कस्पेस अलग होते हैं, इसलिए प्रति संगठन एक वर्कस्पेस ट्री के रूट पर बैठता है। Claude Code को आज यह नहीं मिलता: इसका कैश एक मशीन और डायरेक्टरी तक सीमित है।

“टीमें अपने प्रोजेक्ट खुद संभाल सकती हैं।” यही आज का जुगाड़ है, और सेक्शन 5 के प्रोटोटाइप ने नापा कि इससे क्या निकलता है: एक छोटे डेमो में छह में से दो पेस्ट की गई कॉपी पुरानी थीं।

5. यह आज चलता है: एक रेफरेंस इम्प्लीमेंटेशन

यह दिखाने के लिए कि यह मॉडल सिर्फ बहस करने लायक नहीं, बल्कि बनाने लायक है, मैंने Worktree बनाया — एक छोटा डेस्कटॉप ऐप (Node और Electron, Windows और Linux पर 24 पासिंग टेस्ट) जिसे Claude Desktop की तरह सजाया गया है। ऊपर का वीडियो इसका असली रन है, जिसे सिर्फ वहाँ छोटा किया गया है जहाँ Claude काम कर रहा था। यह एक अलग ऐप है जो Claude Code को बाहर से चलाता है, कोई mod नहीं। यह अपना कोई मॉडल नहीं बुलाता। हर चैट कंप्यूटर पर पहले से इंस्टॉल Claude Code (claude -p) को चलाती है, Claude Code के पास जो भी लॉगिन हो: कोई Claude सब्सक्रिप्शन या API key। मैंने इसे एक काल्पनिक फर्म पर चलाया जिसमें काम की तीन लाइनें और छह प्रोजेक्ट थे। जब कोई मैसेज भेजता है:

• Permit. काम करने वाले व्यक्ति को प्रोजेक्ट या उससे ऊपर ग्रांट चाहिए, और प्रोजेक्ट open होना चाहिए। लाइन पर बिना ग्रांट वाले एडमिन को Claude शुरू होने से पहले ही रोक दिया गया।

• Check. राइट-टाइम चेक पहले चलता है। सेक्शन 3.4 का SI नियम एक enforced फर्म नियम से टकराव के रूप में रिजेक्ट हो जाता है, इसलिए वह कभी CLAUDE.md तक नहीं पहुँचता।

• Mount. ट्री को असली प्रोजेक्ट फोल्डरों में हर लेवल पर एक CLAUDE.md के रूप में लिखा जाता है (storage root पर संगठन, फिर लाइन, फिर प्रोजेक्ट), और Claude Code का अपना कैस्केड इन्हें लोड करता है। कंपाइल्ड मोड इसके बजाय प्रति प्रोजेक्ट एक फाइल लिखता है। ऐप के मार्कर के बिना वाली फाइलें कभी ओवरराइट नहीं होतीं।

• Run. टास्क टेम्पलेट --append-system-prompt-file में जाता है। Claude क्या कर सकता है, यह CLAUDE.md नहीं बल्कि Claude Code लागू करता है: --allowedTools व्यक्ति का रोल है जिसे हर लेवल की policy से मिलाया गया है, राइटिंग प्रोजेक्ट फोल्डर तक सीमित है, और --permission-mode dontAsk बाकी सब कुछ मना कर देता है। असली रन में, एक वेब सर्च से मना कर दिया गया क्योंकि लाइन की policy वेब की अनुमति नहीं देती, और प्रोजेक्ट फोल्डर के बाहर राइटिंग को रोका गया और लॉग किया गया।

• Log and review. हर जवाब व्यक्ति, नोड, हर नियम टैग, Claude द्वारा उद्धृत नियमों, और Claude Code द्वारा बताए गए इनपुट, कैश और आउटपुट टोकन के साथ लॉग होता है। एक रिव्यूअर जिसने जवाब नहीं लिखा, उसे स्वीकार या लौटाता है। डेमो पर एक असली density-report रन में लगभग 30 सेकंड लगे; तीन रन में, Claude Code ने लिस्ट प्राइस पर प्रति जवाब $0.08–0.22 बताया। Claude ने उन नियमों का हवाला दिया जो उसने लागू किए, स्वीकृति सीमा के करीब वाले नतीजों को फ्लैग किया, और इंजीनियर के फील्ड खाली छोड़ दिए।

• Drift. हर माउंट किए गए CLAUDE.md की ट्री से तुलना होती है और हाथ से किए गए बदलाव फ्लैग होते हैं। एक पुराने कमांड-लाइन प्रोटोटाइप ने फ्लैट प्रोजेक्ट्स में पेस्ट की गई कॉपी पर यही तुलना चलाई और पाया कि छह में से दो पुरानी थीं: एक अभी भी R-07 v3 पर, और एक जहाँ कोई नियम हाथ से हटा दिया गया था।

इसे बनाने से तीन बातें निकलीं, जो Claude Code पर इंस्ट्रक्शन्स की लेयरिंग करने वाले किसी भी व्यक्ति के लिए प्रासंगिक हैं:

1. आपके निजी इंस्ट्रक्शन्स संगठन के रन में रिस जाते हैं। डिफॉल्ट रूप से, हर रन ने मेरा निजी ~/.claude/CLAUDE.md, नियम, एजेंट और MCP सर्वर भी लोड किए। ऐप अब इन्हें claudeMdExcludes सेटिंग और --strict-mcp-config से बाहर रखता है। मेरी मशीन पर, इसने एक रन का context 29.6k से घटाकर 21.4k टोकन कर दिया। साफ विकल्प, --setting-sources project,local, ने Windows पर Claude Code 2.1.284 में ज़रूरत के ठीक उल्टा किया: इसने निजी फाइल रखी और पैरेंट-फोल्डर की CLAUDE.md फाइलें हटा दीं जो संगठन और लाइन को ले जाती हैं।

1. किसी व्यक्ति के mods भी रिस जाते हैं। ऐप बनने के अगले दिन mods आए, इसलिए मैंने इसे टेस्ट किया। मैंने अपने यूज़र स्कोप में एक one-hook mod इंस्टॉल किया जो हर प्रॉम्प्ट में एक लाइन जोड़ता है। यह ऐप के रन तक पहुँच गया: संगठन के तीन नियम लोड हुए, मेरी निजी लाइन भी, और जवाब ने उसका पालन किया। रन की सेटिंग्स में disableAllHooks जोड़ने से यह बाहर रहा और CLAUDE.md के तीनों लेवल बरकरार रहे; ऐप अब यही करता है। --safe-mode इसका विकल्प नहीं है: इसने mod को हटाया और उसके साथ पूरा CLAUDE.md कैस्केड भी। डॉक्युमेंटेशन के अनुसार, किसी व्यक्ति की अपनी सेटिंग्स में disableAllHooks उस चीज़ को चलने देता है जिसे संगठन मैनेज करता है।

1. CLAUDE.md context है, enforcement configuration है। Anthropic की डॉक्युमेंटेशन यही कहती है: “सेटिंग्स के नियम क्लाइंट द्वारा लागू किए जाते हैं, चाहे Claude कुछ भी करने का फैसला करे। CLAUDE.md इंस्ट्रक्शन्स Claude के व्यवहार को आकार देते हैं लेकिन सख्त enforcement लेयर नहीं हैं।” ऐप इसी पर निर्भर है। जो कुछ भी किसी नियम को गारंटी देनी है, वह टूल परमिशन्स में मैप हो जाता है; CLAUDE.md में हर चीज़ एक टैग के साथ मार्गदर्शन है।

यह आज के Claude Code पर काम करता है, और कंपाइल किया गया टेक्स्ट किसी भी प्लान पर चैट या Cowork प्रोजेक्ट के इंस्ट्रक्शन्स में पेस्ट किया जा सकता है। एक निर्भरता पुरानी है: ऐप इस पर निर्भर करता है कि claude -p CLAUDE.md फाइलें लोड करे, और Anthropic की डॉक्युमेंटेशन कहती है कि --bare, जो इन्हें छोड़ देता है, “भविष्य के रिलीज़ में -p के लिए डिफॉल्ट बन जाएगा”। जब ऐसा होगा, ऐप को ट्री किसी और तरीके से पास करनी होगी; कंपाइल्ड मोड और --append-system-prompt-file यह पहले से कर सकते हैं। यह नेटिव वर्ज़न के लिए एक काम करने वाला स्पेसिफिकेशन है, कोई सुरक्षा सीमा नहीं: “acting as” एक डेमो स्विच है, साइन-इन नहीं।

6. जो पहले से शिप हो चुका है, उससे आगे का रास्ता

अब Claude Code में। 1 अक्टूबर से यह ट्री एक mod के रूप में शिप हो सकता है: नोड के नियमों को system prompt के एक हिस्से में कंपाइल करें, उन tool calls को रिजेक्ट करें जिन्हें नोड की पॉलिसी मना करती है, और प्रभावी निर्देशों को एक पेन में दिखाएं। कोई भी संगठन (organization) उस mod को किसी व्यक्ति द्वारा इंस्टॉल की गई चीज़ से पहले चला सकता है। मैंने इसे बनाया नहीं है; यह रेफरेंस इम्प्लीमेंटेशन के रोडमैप का पहला आइटम है। यह Claude Code को कवर करेगा, और संभवतः यूज़र की मशीन पर चलने वाले Cowork सेशन्स को भी, जो उसी इंजन पर काम करते हैं। यह chat को कवर नहीं करेगा।

30-दिन वाला वर्ज़न, chat और Cowork के लिए। Anthropic के पास इसके सभी हिस्से मौजूद हैं। किसी प्रोजेक्ट को एक पैरेंट प्रोजेक्ट का नाम तय करने दें जिसके निर्देश वह इनहेरिट करता है, ठीक वैसे ही जैसे Slack चैनल Claude Tag में अपने workspace से इनहेरिट करता है। दोनों को क्रम से कंपाइल करें, हर नियम पर एक tag लगाएं, और मौजूदा “View effective role” के बगल में एक “View effective instructions” पैनल जोड़ दें। सिर्फ इतना करने से हर लाइन-ऑफ-वर्क को अपने नियम रखने के लिए एक जगह मिल जाती है।

इसके बाद, हर कदम अपने आप में उपयोगी है, शुरुआत उन चीज़ों से जो Team plans की मदद करती हैं:

1. लाइन-ऑफ-वर्क नोड्स और की-पैटर्न प्रोविज़निंग, जो CLAUDE.md सेमैंटिक्स का दोबारा इस्तेमाल करती है और पहले से ही कोड में काम करती है। खुद Claude Code में, मैचिंग स्टेप संगठन के mods और व्यक्ति के mods के बीच किसी ग्रुप के लिए एक tier होता है, साथ ही प्रति-ग्रुप मैनेज्ड सेटिंग्स होती हैं।

1. टास्क टाइप्स स्किल्स के रूप में जो एक लाइन तक सीमित हों, और जिनमें acceptance criteria शामिल हों।

1. राइट-टाइम कॉन्फ्लिक्ट चेक, ताकि विरोधाभासों को ट्री द्वारा रिजेक्ट किया जाए, न कि मॉडल द्वारा सुलझाया जाए।

1. नोड्स पर ग्रांट्स, जो बिना ग्रुप्स वाले Team पर काम करते हैं और Enterprise के कस्टम roles को आगे बढ़ाते हैं।

1. प्रोजेक्ट्स के लिए ब्रांच-बाउंड कनेक्टर आइडेंटिटीज़, ठीक वैसे ही जैसे Claude Tag पहले से ही किसी Slack चैनल को एक सर्विस अकाउंट से बाइंड करता है।

1. प्रति-नोड अकाउंटिंग जो प्रोजेक्ट से जुड़ी हो, जैसे Claude Tag पहले से ही प्रति चैनल रिपोर्ट करता है; एक तय यूनिट में प्रकाशित साप्ताहिक लिमिट; और प्रति टास्क एनर्जी डिस्क्लोज़र।

7. सीमाएँ (Limitations)

• कवरेज। 1 अक्टूबर 2026 को code.claude.com/docs और claude.com/docs के पूरे पेज इंडेक्स को टाइटल के आधार पर छांटा गया (466 पेज) और लगभग 150 पेज पढ़े गए, साथ ही यहाँ उद्धृत हेल्प-सेंटर आर्टिकल्स का इस्तेमाल किया गया। इस आर्टिकल के पुराने वर्ज़न्स ने Claude Tag को पूरी तरह मिस कर दिया था; यह वर्ज़न कुछ और मिस कर सकता है। Claude for Government और थर्ड-पार्टी प्रोवाइडर्स पर Claude Desktop का ज़िक्र किया गया है लेकिन उनका विश्लेषण नहीं किया गया।

• प्लेटफ़ॉर्म फीचर्स हर महीने बदलते हैं, और यह लिखे जाने के दौरान भी एक फीचर बदल गया। यहाँ दिया गया हर प्रोडक्ट दावा 29 सितंबर–1 अक्टूबर 2026 की तारीख का है और इस पर भरोसा करने से पहले इसे दोबारा जाँच लेना चाहिए। Mods को आए अभी एक दिन हुआ है; मैंने उनकी डॉक्यूमेंटेशन पढ़ी है और एक केस टेस्ट किया है, इन्हें प्रोडक्शन में इस्तेमाल नहीं किया है।

• सेक्शन 3.1–3.4 में दिए गए मापे गए आंकड़े Claude Code की अपनी usage reports से आए हैं, दो बैच में: 2026-09-30 को Claude Code 2.1.286 और 2026-10-01 को 2.1.287, दोनों Claude Sonnet 5.5 पर। स्क्रिप्ट, दोनों बैच और हर जवाब लेखक के पास सुरक्षित हैं और माँगने पर उपलब्ध कराए जा सकते हैं। इनमें Claude Code का अपना prompt (लगभग 30,200 tokens) शामिल है, जिसे claude.ai और Cowork शेयर नहीं करते, और ये सिर्फ एक मॉडल, एक डेमो प्रोजेक्ट और एक सवाल को कवर करते हैं। सैंपल्स छोटे हैं: जवाब की लंबाई के लिए हर कंडीशन में दस जवाब, कॉन्फ्लिक्ट टेस्ट के लिए हर कंडीशन में बीस। दोनों बैच के बीच जवाब-लंबाई अनुपात बदल गए (सेक्शन 3.3); एक दिन के अंतर वाले दो बैच Claude Code वर्ज़न के हिसाब से भी अलग होते हैं, और मैं इसे संयोग से अलग नहीं कर सकता।

• सेक्शन 5 में रन टाइम, लागत और context sizes ऐप के अपने answer log से आए हैं, जिसमें तीन डेमो रन और एक मैनुअल आइसोलेशन टेस्ट शामिल है, जो लेखक के अपने रिकॉर्ड हैं।

• कॉन्फ्लिक्ट वाले जवाबों को लेखक ने अनब्लाइंडेड तरीके से कोड किया, हर जवाब को पढ़कर (रिपोर्ट की गई यूनिट्स; क्या जवाब ने बताया कि कौन सा नियम जीता और क्यों; क्या उसने सवाल पूछा)। सभी चालीस जवाब रीकोडिंग के लिए माँगने पर उपलब्ध हैं। टेस्ट में “enforced” का एक ही वाक्यांश इस्तेमाल किया गया; अन्य वाक्यांश, मॉडल और नियमों के जोड़े अलग तरह से व्यवहार कर सकते हैं।

• सेक्शन 5 में mod test एक mod है जिसमें एक hook है, एक Linux मशीन पर, Claude Haiku के साथ, सब्सक्रिप्शन से साइन इन और बिना किसी मैनेज्ड सेटिंग के। मैंने किसी संगठन के policy mod, Team या Enterprise लॉगिन पर बिल्ट-इन गार्ड, या Desktop ऐप को टेस्ट नहीं किया।

• सेक्शन 3.2 में कॉस्ट मॉडल एक उदाहरण के तौर पर दी गई फर्म का सिमुलेशन है, मापी गई बिलिंग नहीं। यह सिर्फ instruction tokens को कवर करता है; असली बिल में आमतौर पर conversation history, output और thinking हावी रहते हैं। इसके token sizes Anthropic के public legacy tokenizer × 1.30 का इस्तेमाल करते हैं; माप में, Claude Code ने उस अनुमान से 21–26% ज़्यादा लोड किया, इसलिए इसके डॉलर के आंकड़े कम दिखते हैं। इसके प्रतिशत अनुपात हैं और सही बैठते हैं। Session patterns और cache sharing मान्यताएँ (assumptions) हैं।

• क्या Enterprise पर chat usage को API cache pricing मिलती है और क्या claude.ai पर caches यूज़र्स के बीच शेयर होते हैं, यह डॉक्यूमेंट नहीं किया गया है। Cowork अपने सेशन्स Claude Code पर चलाता है, और plugin hooks वहीं लोड होते हैं, लेकिन mods पेज Cowork को लिस्ट नहीं करते और मैंने इसे टेस्ट नहीं किया; 1 अक्टूबर को desktop ऐप में अभी भी Claude Code 2.1.286 बंडल था, जो mods चालू होने से एक वर्ज़न पुराना था। किसी डिवाइस की मैनेज्ड पॉलिसी यूज़र की मशीन पर Cowork सेशन्स तक पहुँचती है, जब तक कि संगठन उन्हें full VM sandbox में न चला रहा हो। दो पेज इस बात पर असहमत हैं कि किसी व्यक्ति की अपनी ~/.claude फाइलें Cowork तक पहुँचती हैं या नहीं, इसलिए यह आर्टिकल किसी भी पक्ष में कोई दावा नहीं करता। मैंने यह भी टेस्ट नहीं किया कि पैरेंट फोल्डर्स की CLAUDE.md फाइलें Cowork सेशन में लोड होती हैं या नहीं; अगर होती हैं, तो रेफरेंस इम्प्लीमेंटेशन का mounted tree आज ही यूज़र की मशीन पर Cowork तक पहुँच जाएगा। Pro और Max पर यह खिड़की 6 अक्टूबर 2026 को और सिकुड़ जाएगी, जब नए Cowork tasks cloud पर चले जाएंगे।

• इरादों का अनुमान लगाया गया है। Anthropic ने सार्वजनिक रूप से यह नहीं बताया है कि Claude chat और Cowork flat क्यों हैं।

• कोड और raw data इस आर्टिकल के साथ प्रकाशित नहीं किए गए हैं। पाठक सिर्फ इस आर्टिकल से मापों को दोहरा नहीं सकता; वीडियो दिखाता है कि ऐप कैसे काम करता है, यह नहीं कि उसे कैसे बनाया गया है।

• रेफरेंस इम्प्लीमेंटेशन एक काल्पनिक फर्म पर चलता है। यह claude.ai या Cowork के साथ इंटीग्रेट नहीं है, और “acting as” एक डेमो स्विच है, साइन-इन नहीं। Permissions ऐप द्वारा नहीं, बल्कि Claude Code की tool lists द्वारा लागू की जाती हैं। Isolation रन के दौरान व्यक्ति के अपने hooks और mods को बंद कर देता है; Claude Code में बिल्ट-इन mods चलते रहते हैं, और personal agents के नाम अभी भी context में दिख सकते हैं। ऐप claude -p द्वारा CLAUDE.md लोड करने पर निर्भर करता है, जिसके बारे में Anthropic कहता है कि यह अब डिफ़ॉल्ट नहीं रहेगा। Personal-file leak और --setting-sources परिणाम Windows पर टेस्ट किए गए; माप और mod test Linux पर चलाए गए।

स्रोत (Sources)

• Anthropic, Set organization instructions

• Anthropic, Roles and permissions

• Anthropic, What is the Team plan? · Plans and pricing

• Anthropic, Manage custom roles on Enterprise plans

• Anthropic, Organize your tasks with projects in Claude Cowork

• Anthropic, Use Google Workspace connectors

• Anthropic, Manage groups and group spend limits on Enterprise plans

• Anthropic, What are projects? (projects का नया वर्ज़न, beta)

• Anthropic, Get started with Claude Cowork(global और folder instructions)

• Anthropic, How Claude remembers your project (CLAUDE.md) · All settings (claudeMdExcludes, disableAllHooks)

• Anthropic, Customize Claude Code with mods (1 अक्टूबर 2026) · Mods overview · Manage mods for your organization · React to events with a mod · Mods reference

• Anthropic, Claude Tag: What is Claude Tag? · Configure per-channel access · Customize Claude Tag · How agent identity works · Audit · Set a spend limit

• Anthropic, Projects in Claude Code (new projects beta) · Projects in Cowork · How Claude Code uses prompt caching · Run Claude Code programmatically (--bare) · Extend Claude Code · Manage project visibility and sharing · Use connectors · Authorize MCP connectors for your entire organization · Provision and manage skills

• Anthropic, Configure server-managed settings (कोई per-group configuration नहीं) · Manage plugins for your organization (Enterprise पर ग्रुप के अनुसार plugin availability) · Plugin feature support across platforms (chat में hooks को नज़रअंदाज़ किया जाता है, Cowork में लोड होते हैं) · Deploy managed settings (Cowork अपने सेशन्स Claude Code पर चलाता है)

• Anthropic, Pricing (Sonnet 5.5 rates, tokenizer note) · Prompt caching (API पर प्रति संगठन और प्रति workspace isolated caches)

• Anthropic, @anthropic-ai/tokenizer(गिनती के लिए इस्तेमाल किया गया public tokenizer)

• Microsoft, Management groups · Landing-zone management group design

• AWS, SCP evaluation · Google Cloud, Hierarchy evaluation

• Microsoft, Group Policy processing · SharePoint fine-grained permissions

• FinOps Foundation, Token economics

• Jaroslawicz et al., How Many Instructions Can LLMs Follow at Once? (IFScale)

• Firefly, 2026 State of IaC research

• MCP, Authorization specification, version 2026-07-28

• GitHub, anthropics/claude-code issues #68262, #14467, #30554, #27567, #30250, #27302, #47741

• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), “A City is Not a Tree,” Architectural Forum; Simon, H. (1962), “The Architecture of Complexity,” Proc. Am. Phil. Soc.106(6)

• Reference implementation और data: Worktree ऐप, उसके tests, measurement script, दोनों result batches और हर जवाब लेखक के पास सुरक्षित हैं और माँगने पर उपलब्ध कराए जा सकते हैं।