Відсутній шар: Структурування AI-агентів для організаційних ієрархій

Еталонна модель того, як організації структурують свою роботу зі ШІ

Хосе Мартінес · 1 жовтня 2026 · v1.8.1 (виміряно в Claude Code; перевірено за документацією Anthropic 1 жовтня 2026)

У п'яти рядках.

1. Організації — це дерева: компанія, напрямок роботи, проєкт, завдання. Проєкти Claude пласкі: чат має один організаційний блок на 3000 символів, проєкти в чаті та Cowork не вкладаються одне в одне й не успадковуються, а в межах проєкту обліковий запис конектора належить людині або всій організації, але ніколи — окремій гілці.

1. Тому кожен проєкт отримує створену вручну копію правил свого напрямку, ці копії розходяться, і ніхто не бачить, яке саме правило дало відповідь.

1. Anthropic уже двічі побудувала це дерево. Claude Code вкладає інструкції за папками, а з 1 жовтня 2026 року запускає моди організації перед модами користувача. Claude Tag у Slack успадковує інструкції та облікові дані від організації до робочого простору й далі до каналу. Жоден із них не сягає рівня проєкту. Та сама модель може працювати й там: шар напрямку роботи, проєкти, що народжуються з його папок, типізовані завдання, компілятор, який відхиляє конфлікти ще до того, як їх побачить модель, і дозволи для кожного вузла, що діють у Team.

1. Я двічі виміряв це в Claude Code. Правило організації та правило проєкту суперечили одне одному, перебували на різних рівнях CLAUDE.md, і жодне не було позначене як обов'язкове: правило проєкту перемогло 20 разів із 20. Те саме правило організації, позначене як обов'язкове словами: воно перемогло 20 разів із 20. Пріоритет визначався формулюванням, яке може змінити будь-хто, хто редагує будь-який шар, а не структурою.

1. Це вже працює. Створений мною десктопний застосунок запускає Claude Code всередині дерева. Він монтує кожен шар як CLAUDE.md, обмежує Claude тим, що людина може робити на цьому вузлі, відхиляє конфлікт у момент його написання та логує кожну відповідь разом із її правилами, токенами й рецензентом. За вимірами, дерево завантажувало на 20–34% менше токенів інструкцій, ніж пласкі копії.

Організації — це дерева. Компанія задає політику, напрямок роботи — свої стандарти, проєкт застосовує їх до конкретного завдання, а задача видає один результат. Кожна система управління якістю, з якою я працював, побудована саме так, як і дерево папок майже на кожному корпоративному файловому сервері: компанія, напрямок роботи, рік, а потім одна папка на завдання, названа номером, у якому закодовано все це.

ШІ-проєкти пласкі. Я беру Claude як приклад, бо це продукт, у якому я працюю щодня, і тому, що він уже постачає рішення на двох власних поверхнях. У чаті Claude проєкти не можна вкладати, а інструкції організації — це єдиний блок обсягом до 3000 символів, який діє для всіх. В Enterprise адміністратори можуть обмежувати дозволи за групами. У Team ролі застосовуються до всієї організації. Ніщо, задокументоване в чаті чи Cowork, не передає інструкції вниз до відділу чи напрямку роботи, а звідти — до його проєктів. В Enterprise навички та проєкти можна поширювати на групу, але це дистрибуція, а не успадкування.

Саме цього шару бракує: того, що між організацією та проєктом. Ця стаття пояснює, чого не вистачає, чому це важливо, скільки це насправді коштує, і пропонує еталонну модель, яку могла б реалізувати будь-яка платформа, включно з її дозволами та структурою даних.

1. Що існує сьогодні

Перевірено за документацією Anthropic 29 вересня – 1 жовтня 2026. Claude має чотири поверхні, де працює команда, і кожна має власну модель інструкцій:

Дозволи залежать від тарифного плану:

Anthropic побудувала половину дерева для дозволів. В Enterprise кастомні ролі призначаються групам; «кастомні ролі також контролюють, які конектори та які інструменти на цих конекторах може використовувати роль»; по всій платформі, на рівнях організації, ролі та користувача, «перемагає найсуворіший рівень», тоді як кілька ролей учасника додаються; адміністратори можуть «Переглянути ефективну роль» із міткою «Надано», а групи можуть мати власні ліміти витрат. Але це пласкі групи, а не дерево, і жодна з них не сягає інструкцій. Найближче до цього — плагіни: в Enterprise власник може зробити плагін та його навички обов'язковими або встановленими за замовчуванням для однієї групи із зазначеним порядком («налаштування групи, потім налаштування для всієї організації, потім значення маркетплейсу за замовчуванням»). Це стосується групи людей, а не проєкту; між проєктами нічого не успадковується, а навичка все одно завантажується лише тоді, коли Claude вважає її релевантною. Team має ролі для всієї організації та поширення від людини до людини; у налаштуваннях плагінів, за словами документації, «немає налаштувань для групи». І саме Team — план, створений для малого та середнього бізнесу.

Anthropic двічі побудувала повне дерево, але поза проєктами.

У Claude Code — за папками. Claude Code завантажує файли CLAUDE.md із чотирьох рівнів; «усі знайдені файли об'єднуються в контекст, а не перезаписують один одного», у порядку «від кореня файлової системи до вашого робочого каталогу», а файли у підкаталогах «завантажуються на вимогу». Блок організації може надходити як керований файл на кожній машині або як текст із консолі адміністратора (ключ claudeMd). Документація відверто говорить про обмеження: Claude сприймає ці файли «як контекст, а не як примусову конфігурацію», і «якщо дві інструкції суперечать одна одній, Claude може обрати будь-яку довільно».

У Claude Tag — за каналами Slack. Claude Tag — це Claude у Slack команди, доступний у публічній беті для Team та Enterprise. Його налаштування прив'язуються до scope (області дії), і «scope — це місце, де застосовується пакет: стандартний доступ до Slack (кореневий рівень для всієї організації), робочий простір або окремий канал». Три речі, яких вимагає решта цієї статті, тут уже є:

• Інструкції успадковуються. «Кастомні інструкції для кожного scope об'єднуються: спочатку стандартний доступ до Slack, потім робочий простір, потім канал. Інструкції каналу доповнюють, а не замінюють те, що встановлено вище».

• Облікові дані належать гілці. У каналах Claude діє через сервісні облікові записи, які адміністратор прив'язує до scope, і «використовуються облікові дані з найвужчого scope: канал переважає робочий простір, який переважає стандартний доступ до Slack».

• Можна побачити, звідки взявся доступ. Кожен рядок конектора, репозиторію та плагіна має позначку «Успадковано від» ширшого scope або «Прикріплено з» пакета. Витрати обмежуються для організації та окремо для кожного каналу й звітуються поканально.

Обмеження також задокументовані. Дерево має форму Slack: три фіксовані рівні, а канали Slack не вкладаються. Інструкції — це «рекомендації, а не примусовий запобіжник», і документація не описує жодної перевірки на конфлікти між scope. Немає «покрокового журналу кожної дії та того, хто її запросив». І все це зупиняється на межі проєкту: «Проєкти в claude.ai тут не застосовуються; Claude не читає інструкції чи знання проєкту в Slack, і канал не можна спрямувати на проєкт».

Що змінилося 1 жовтня 2026. Claude Code 2.1.287 увімкнув моди, які раніше були в ранньому доступі: функції всередині плагіна, що виконуються в Claude Code і можуть переписати промпт або частину системного промпту, заблокувати чи змінити виклик інструменту, схвалити або відхилити запит на дозвіл і малювати панелі в інтерфейсі. Тут важливі три речі:

• Вони мають оголошений порядок. Спочатку працюють вбудований guard і моди самої організації, а потім — моди, які встановлює людина. «Перший мод є найзовнішнішим: він бачить подію раніше за інші, а результат — після них, і вирішує, чи взагалі запускатимуться інші». Там, де завантажується guard (машина з керованими налаштуваннями або логін Team/Enterprise), мод користувача не може змінити «системний промпт, ваш керований CLAUDE.md та інші керовані інструкції» і не може схвалити виклик інструменту, який блокує deny-правило. Це пріоритет, заданий структурою, — саме те, чого вимагає ця стаття. Це значення за замовчуванням, а не замок: людина, яка запускає Claude Code з --safe-mode, працює без встановлених модів, включно з організаційними, тоді як керовані хуки та deny-правила продовжують діяти.

• У порядку є два власники. Моди організації виконуються перед модами користувача або після них, якщо так вирішить організація. Рівня для напрямку роботи немає. Налаштування з консолі адміністратора «застосовуються однаково до всіх користувачів в організації. Конфігурації для окремих груп поки що не підтримуються». Організація, яка хоче різну політику для різних груп, має два шляхи, обидва через IT: розгорнути різні файли налаштувань на машинах кожної групи або запустити self-hosted gateway, який «надає керовані налаштування для кожної групи IdP».

• Вони не дістаються чату, а в Cowork працюють нерівномірно. «Моди працюють у CLI Claude Code та на вкладці Code застосунку Claude Desktop». Мод постачається у hooks/hooks.json плагіна, а таблиця підтримки плагінів Anthropic позначає цей файл як «Ignored» у чаті. У тій самій таблиці він позначений як «Loads» у Cowork, бо «Cowork у застосунку Claude Desktop запускає свої сесії на Claude Code»; сторінки про моди не згадують Cowork, і я його не тестував. Контроль організації там слабший: у сесії Cowork Claude Code «ніколи не завантажує керовані сервером налаштування з консолі адміністратора claude.ai, навіть якщо користувач увійшов з обліковим записом Team або Enterprise», а віддалені сесії Cowork не мають політики пристрою для читання.

Що зараз розгортається. Cowork зливається з Claude: довідковий центр тепер каже «Claude Cowork — це просто Claude», спершу на Pro та Max, тоді як Team і Enterprise «залишають чат і Claude Cowork такими, якими вони є сьогодні». 6 жовтня 2026 нові завдання Cowork на Pro та Max переходять у хмару. А нова версія проєктів доступна в публічній беті на Pro та Max, починаючи з Claude Code, а чат, Cowork, Team і Enterprise будуть пізніше; у ній «проєкт — це одна розмова», яку Claude розбиває на паралельні гілки. Це все ще один рівень: «Проєкт належить одному користувачу», і «під час бети немає елементів керування проєктами на рівні організації».

Тож дерево — не нова ідея для Anthropic. Воно існує за папками для коду та за каналами для Slack, і в обох випадках організація йде першою. Місце, де компанія зберігає свою роботу — проєкт — не має ні батька, ні вищого рівня над собою. Два інші продукти Anthropic вказують у тому ж напрямку, але виходять за межі цієї статті: Claude for Government узгоджує налаштування через ланцюжок tenant, group та organization, а Claude Desktop у сторонніх провайдерів має політики для груп у беті.

2. Чому це важливо

Проєкти — це не контейнери. Реальне завдання — це контейнер. Воно має ключ (номер завдання), батька (свій напрямок роботи), життєвий цикл (відкрито, закрито, архівовано за роком), папку, клієнта, людей, правила та результати. Проєкт Claude має назву у вигляді довільного тексту, без ключа, без батька й без дітей, а його задокументований життєвий цикл — архівування та видалення. Cowork може прив'язати проєкт до локальної папки, але лише вручну, по одному проєкту, без шаблону ключа та без батька. Напрямок роботи може відкривати сотні завдань на рік. Залишаються два погані варіанти: один створений вручну проєкт Claude на завдання, кожен із власною копією правил, або один проєкт на напрямок роботи, де контекст різних клієнтів лежить поруч.

Ланцюг передачі навантаження рветься. У будівельній механіці кожне навантаження потребує безперервного шляху до фундаменту. Приберіть один елемент — і ніщо над ним не передасться вниз. Правила поводяться так само. Коли між організацією та проєктом немає шару, стандартам, шаблонам і правилам затвердження напрямку роботи ніде жити. Тому кожен проєкт отримує створену вручну копію.

Копії розходяться. Виправили правило в одному проєкті — інші залишаються зі старою версією. Кожен проєкт досі проходить власну локальну перевірку. Невідповідність проявляється лише тоді, коли хтось порівнює проєкти поруч, а в регульованій роботі це зазвичай аудитор. Інфраструктурні команди добре знають цю проблему. У дослідженні Firefly 2026 року близько третини респондентів пов'язали дрейф конфігурацій із дорогими інцидентами на продакшені, а приблизно кожен п'ятий не мав процесу для його виявлення чи виправлення.

Ідентичність теж пласка. Багато людей працюють у кількох організаціях, і кожна потребує власного ізольованого контексту. Всередині будь-якої з них, у чаті та Cowork, обліковий запис конектора належить людині, а не гілці. Ролі Enterprise можуть визначати, які конектори дозволені групі, а адміністратор може авторизувати конектор один раз для всієї організації; кастомний конектор навіть може мати один спільний обліковий запис для всіх (у беті). Так чи інакше, обліковий запис належить людині або організації, але ніколи гілці: консультант, який обслуговує двох клієнтів, не може прив'язати Drive кожного клієнта до проєктів саме цього клієнта. Спільні проєкти загострюють проблему: «Конектори доступні лише в приватних проєктах». Claude Tag показує, що можливий інший дизайн, де сервісний обліковий запис прив'язаний до каналу Slack, і водночас демонструє, де він зупиняється — на проєкті. Сторінка конектора Google від Anthropic описує один підключений обліковий запис Google, а задокументований спосіб його змінити — відключити й підключити заново; три відкриті тікети (нижче) просять більше ніж один обліковий запис. Межа існує лише в голові людини, а це саме той тип ручної межі, який тихо ламається.

Ніхто не бачить, яке правило спрацювало. Claude Enterprise показує адміністраторам «View effective role» для дозволів, а /context у Claude Code перелічує, які файли пам'яті завантажено. Мод Claude Code тепер може малювати власну панель, тож перегляд ефективних інструкцій там може зібрати будь-хто. Claude Tag позначає кожен конектор і репозиторій scope, з якого його успадковано, але для інструкцій документація радить «попросити Claude повторити його адміністративні інструкції». Жодна поверхня не показує, яка інструкція з якого шару дала конкретну відповідь. Без походження немає аудиторського сліду, а без аудиторського сліду немає системи якості.

Люди вже просять частини цього. Відкриті тікети в публічному трекері Anthropic (github.com/anthropics/claude-code), перевірено 2026-10-01:

Сьомий, #47741, просив керований організацією CLAUDE.md і був закритий, бо Claude Code вже його має. У цьому й суть: шари існують у Code та в Slack, а тікети просять їх там, де живуть проєкти.

3. Скільки це коштує і що приховує токен

3.1 Токени — не бар'єр

Більше шарів могло б означати більше контексту з кожним повідомленням, а ШІ тарифікується за токени. Це пояснення правильне лише частково. На планах Enterprise із оплатою за використання, споживання тарифікується за ставками API, тож більше контексту означає більше доходу, а не менше. У Team місця мають фіксовану ціну, якщо не ввімкнено додаткове використання, а додаткові токени проявляються як швидше досягнення учасниками тижневого ліміту. І Claude Code, який тарифікується за тими ж токенами, уже постачає чотирирівневий каскад. Якби токени були бар'єром, його б не існувало. За вимірами з розділу 3.2, власний системний промпт та інструменти Claude Code складали близько 30 200 токенів ще до будь-якої нашої інструкції; повні інструкції проєкту додавали до цього 3,5–5,2%.

3.2 Розібраний приклад

Позначки на кожному зображенні: REAL = виміряно або перевірено за документацією Anthropic між 29 вересня та 1 жовтня 2026; EST = змодельовано; IND = ілюстративно.

Спершу вимірювання. Я поставив те саме запитання в Claude Code (claude -p, Claude Sonnet 5.5) для одного демо-проєкту, по п'ять разів на кожну умову, і взяв вхідні токени, які повідомив сам Claude Code. Я запускав це на Claude Code 2.1.286 30 вересня і знову на 2.1.287 1 жовтня; кількість інструкцій була ідентичною. Якщо відняти прогон без жодних інструкцій проєкту, залишиться вартість кожного макета:

Дві речі, яких симуляція нижче не змогла показати. Каскад коштує на 224 токени більше, ніж скомпільований файл для тих самих правил: кожен додатковий файл несе накладні витрати, тут це власний маркер і заголовок застосунку у файлі кожного рівня плюс обрамлення, яке Claude Code додає навколо кожного завантаженого файлу. Більше рівнів — більше накладних витрат. І Claude Code фактично завантажив на 21–26% більше, ніж оцінив публічний токенізатор, навіть із множником × 1,30; частина цієї різниці — ті самі накладні витрати на файл. Пропорції це витримують, абсолютні суми в доларах — ні, тому сприймайте долари з симуляції як занижені.

Потім симуляція в масштабах компанії. Я змодельовав місяць токенів інструкцій для ілюстративної компанії: 40 людей у трьох напрямках роботи, 250 активних проєктів, шість типів звітів на напрямок, 35 повідомлень на людину за робочий день у сесіях по п'ять, загалом 29 400 повідомлень. Розміри токенів підраховано на зразках текстів інструкцій публічним legacy-токенізатором Anthropic (який сама Anthropic називає «дуже грубим наближенням» для Claude 3 і новіших) і масштабовано на 1,30 для токенізатора Claude 4.7+. Блок організації екстрапольовано зі зразка на 597 символів до ліміту в 3000 символів, а посібник напрямку — це три зразки по 953 символи. Ціни — прайсові для Claude Sonnet 5.5 (вхід $2, запис кешу на 5 хвилин $2,50, читання кешу $0,20 за мільйон токенів). Кеш промпту живе п'ять хвилин і оновлюється при кожному зверненні.

• Плаский (сьогоднішній обхідний шлях): блок організації, потім власна копія посібника напрямку для кожного проєкту, усі шість шаблонів звітів і специфіка проєкту.

• Дерево: організація, напрямок, лише той шаблон звіту, що використовується, потім специфіка проєкту, скомпільовані від найбільш спільного.

Розміри за таблицею: блок організації 830 токенів (3000 символів), посібник напрямку 729, один шаблон звіту 147, специфіка проєкту 98 (округлено; підсумки обчислено до округлення). Симуляція ігнорує власний системний промпт Claude, який стоїть перед блоком організації.

Два чесні застереження. По-перше, дерево саме по собі не економить токени. −29% дають типизовані завдання: завантажується лише шаблон того звіту, що пишеться, а не всі шість. −62% здебільшого дає компіляція найспільніших шарів першими, тож сотні проєктів ділять один байт-ідентичний префікс: лише впорядкування, коли всі шість шаблонів усе ще завантажуються, знижує вартість спільного кешу з $36 до $18 (−51%), а типізовані завдання додають решту. Ця друга економія існує лише тоді, коли кеш спільний між користувачами. В API Claude кеші ізольовані між організаціями, а всередині однієї — між робочими просторами, тож ідентичні префікси повторно використовуються в межах простору; для claude.ai це не задокументовано. У коробковому Claude Code цього не відбувається: там «кеш фактично обмежений однією машиною та каталогом», тож двоє людей у двох папках проєктів не бачать кешу одне одного. Сприймайте останній стовпець як те, що міг би дати нативний шар у чаті, а не як щось доступне сьогодні. Справедливе заперечення: Skills уже завантажуються на вимогу, тож плаский робочий простір, який перенесе свої шаблони в Skills, отримає частину від −29% уже сьогодні. Чого Skills бракує в чаті та Cowork — це scope та успадкування: навичка не може належати одному напрямку й спускатися до проєктів цього напрямку. (У 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% оплачених токенів виводу припадало на thinking, проти 16% за простого промпту. Англійською читач бачить 447 токенів, а платить за 711.

• Іспанська коштувала у 1,2 раза більше видимих токенів, ніж англійська для відповідей, що відрізнялися за довжиною в словах не більше ніж на 4%. Виміряні так само, правила компанії потребували у 1,53 раза більше вхідних токенів, коли були написані іспанською.

• За той самий висновок виставляли рахунок від 317 до 953 токенів — утричі більше за найдовшу відповідь, ніж за найкоротшу. Оплата за токени не відрізняє суворість від води. Критерії приймання — відрізняють.

Ці пропорції коливаються між серіями по п'ять. Екранне співвідношення для правил компанії становило 1,43–1,52 у першій серії та 1,27–1,31 у другій; співвідношення в рахунку — 1,78–1,82, а потім 1,70–2,05; іспанське співвідношення — 1,29–1,38, а потім 1,14–1,18. Напрямок ніколи не змінювався. Порядок величини точний до однієї значущої цифри.

Метод: Claude Code 2.1.286 на 2026-09-30 та 2.1.287 на 2026-10-01, claude -p --output-format json, Claude Sonnet 5.5. Усі інструменти були заборонені, а особисті файли ~/.claude виключені, тож між умовами відрізнялися лише зазначені інструкції. Підрахунки токенів — це власний звіт про використання Claude Code, включно з thinking_tokens; місячна вартість застосовує $10 за мільйон токенів виводу для Sonnet 5.5 до середнього оплаченого значення. Скрипт вимірювання, обидві серії, зведені цифри та всі відповіді зберігаються в автора й доступні на запит. Перша версія цієї статті оцінювала ці числа за допомогою сабагентів і публічного токенізатора; ті оцінки застаріли.

3.4 Коли правила конфліктують, вирішують слова

Документація Anthropic визнає, що суперечливі інструкції можуть вирішуватися «довільно». Я перевірив один конфлікт такого типу, який створює відсутній шар напрямку. Правило організації казало використовувати американську систему мір; правило проєкту — звітувати щільність у SI. Я розмістив їх так, як це зробило б дерево: правило організації в CLAUDE.md у корені сховища, правило проєкту в CLAUDE.md у папці проєкту, обидва завантажені власним каскадом Claude Code. Потім я запустив ту саму схему, де правило організації було позначене як обов'язкове, лише словами: тег ENFORCED у назві та одне додане речення: «This rule is enforced: no line or project rule may override it.» Кожна схема запускалася десять разів 30 вересня і ще десять 1 жовтня.

Це не було довільно. Без жодних декларацій Claude щоразу обирав ближче, специфічніше правило. Чотирнадцять із двадцяти відповідей пояснили чому («це правило більш специфічне, ніж загальнокорпоративне правило U.S. customary», або що воно перевизначає правило компанії); п'ять посилалися лише на правило проєкту й жодного разу не згадали, що правило компанії суперечило йому. Коли обов'язковість була оголошена словами, правило організації перемагало щоразу, і кожна відповідь казала, що примусове правило компанії має пріоритет. Друга серія відтворила одиниці виміру, 10 з 10 щоразу, і різниця між двома рядками далеко за межами випадковості (точний тест Фішера, p < 0,0001). Пояснення трималися гірше: дев'ять із десяти відповідей сказали, чому перемогло правило проєкту, у першій серії, і п'ять із десяти — у другій.

Це добра новина для моделі й погана — для робочого простору. Пріоритетність існує, але вона закладена у формулюваннях правил, які може змінити будь-хто, хто редагує будь-який рівень, і які ніхто не перевіряє саме як рішення про пріоритет. А коли перемагало нижче правило, чверть відповідей не повідомляла користувачу, що вище правило було проігноровано. Пілотний тест у першій версії цієї статті, де обидва правила були в одному промпті замість каскаду, також показав зміну результату лише через зміну їхнього порядку (правило організації першим: SI 5 із 5; правило організації останнім: SI 2 із 5, а 3 із 5 видали обидві одиниці або запитували, яку застосовувати).

Жодній моделі не варто доручати розв'язувати конфлікт, який організація могла б виявити ще на етапі написання правила. У Claude Code є дві часткові відповіді. /doctor prompt-audit просить Claude знайти файли інструкцій, що суперечать одне одному, коли людина запускає цю команду. А з 1 жовтня мод може примусово задавати порядок у коді: моди організації виконуються перед модами людини, а там, де завантажується вбудований захист, правила заборони (deny) переважають моди людини. Жоден із цих механізмів не стосується тексту інструкцій. Файли інструкцій досі конкатенуються, і документація описує результат трьома способами: Claude «може обрати одне довільно»; коли правило користувача та правило проєкту конфліктують, «Claude може слідувати будь-якому з них»; і «коли інструкції конфліктують, Claude використовує власне судження, щоб їх узгодити». Результат «двадцять із двадцяти» — це те, як це судження спрацювало тут. Claude Tag декларує порядок для своїх трьох областей дії (scopes) і називає результат «рекомендацією, а не примусовим обмеженням». Перевірка в еталонній реалізації відхиляє саме таку зміну: «R-22 sets units.density=SI; R-01 (org:firm) enforces US», ще до того, як щось потрапить до Claude, причому enforced — це поле в правилі, а не речення в ньому.

Щільність інструкцій лише погіршує ситуацію. У бенчмарку IFScale (2025) точність Claude Sonnet 4 впала зі 100% при 10 одночасних інструкціях до 42,9% при 500.

3.5 Чи були б обчислення або енергія справедливішою одиницею?

Токен — це прийнятний замінник обчислень у межах однієї моделі: більше токенів справді означають більше роботи для обладнання. Саме тому ціна на основі обчислень чи енергії не усуне мовний штраф. Іспанська коштує дорожче, бо токенайзер стискає її гірше, і ці додаткові токени — це реальні обчислення. Ліки від цього — кращий токенайзер або тарифікація, нормалізована за обсягом контенту.

Нормалізована одиниця обчислень все одно допомогла б у трьох аспектах. Вона дозволяє порівнювати різні моделі та вендорів. Вона фізична і підзвітна, наприклад, для звітів про сталий розвиток. І якщо коефіцієнт зафіксовано відносно еталонного обладнання, вендор залишає собі вигоду від власної ефективності, що є правильним стимулом. Прецеденти є: хмарні провайдери колись продавали нормалізовані одиниці, такі як EC2 Compute Unit.

Але є й реальні проблеми. Клієнт не зможе це перевірити без стандарту та аудитора. Фактичне споживання енергії залежить від обладнання, ефективності дата-центру, пакетної обробки та електромережі. Anthropic не публікує дані про енергію на запит; я знайшов лише сторонні оцінки. Найголовніше — обчислення все одно залишаються вхідним ресурсом. Вони не кажуть, чи була відповідь правильною.

Мій висновок — три окремі рівні:

1. Тарифікуйте в токенах або нормалізованих одиницях обчислень.

1. Розкривайте витрати енергії на задачу та на вузол.

1. Управляйте за вартістю підтвердженого результату.

Для Team мінімальний крок — публікувати тижневий ліміт у заявлених одиницях. Ліміт на сесію подано як «1,25x від ліміту використання на сесію плану Pro»; тижневий ліміт взагалі не має опублікованого числа. Ні те, ні інше неможливо бюджетувати.

Як каже FinOps Foundation, «токен — це одиниця тарифікації, а не одиниця цінності». Саме ієрархія робить цінність визначеною, бо в ній можуть жити критерії приймання.

3.6 Більш імовірні причини, чому це ще не побудували

1. Неявна пріоритетність. Сама документація Anthropic визнає, що прямі суперечності в інструкціях можуть призводити до різної поведінки, а розділ 3.4 показує, що пріоритет визначається тим, що написано в правилах. Нашарування рівнів множить конфлікти, а здатність слідувати інструкціям падає зі зростанням їхньої щільності: у бенчмарку IFScale (2025) навіть найкращі протестовані моделі досягли лише 68% точності при 500 одночасних ключових інструкціях (бенчмарк згадується в розділі 3.4).

1. Успадкування дозволів. Якщо знання успадковуються вниз по дереву, доступ теж має успадковуватися. Це означає перебудову моделі дозволів під кожним рівнем.

1. Перевага пам'яті та пошуку над статичними рівнями.

1. Простота для споживчого ринку. Інструменти для коду безкоштовно отримують дерево від файлової системи. Чат-продуктам доводиться його винаходити.

Anthropic публічно не пояснювала, чому в чаті Claude та Cowork немає ієрархії. Усе в цьому розділі — висновки з того, що вже випущено.

4. Еталонна модель

Дизайн запозичений із систем, які вже розв'язали цю проблему: ієрархії хмарних ресурсів (AWS Organizations, Google Cloud Org Policy, групи керування Azure), політики каталогів (Active Directory Group Policy) та власний каскад CLAUDE.md у Claude Code. Зв'язки між вузлами описуються п'ятьма словами: contains (містить), inherits (успадковує), uses (використовує), sealed (запечатаний) і shared (спільний).

4.1 Підключіть дерево, яке організація вже має

Не змушуйте людей перебудовувати свою організацію всередині AI-робочого простору. Файловий сервер або система документів уже є єдиним джерелом правди. Оберіть один шлях:

Номер завдання 26GT301 уже кодує дерево: рік, напрямок роботи, порядковий номер. Робочий простір має монтувати цю структуру, а не копіювати її.

4.2 Вузли з правилами, вузли групування, проєкти та задачі

• Вузли з правилами: організація, напрямок роботи, проєкт, задача. Кожен несе ті самі три речі: контекст (інструкції та знання), політику (які інструменти, дані та конектори дозволені) та ідентичності (облікові записи конекторів, прив'язані до нього).

• Вузли групування: серія, рік, регіон. Вони не містять правил. Вони існують для навігації, зберігання та життєвого циклу. Їхнє відокремлення тримає дерево правил неглибоким — три-чотири рівні, як рекомендує власна настанова Microsoft для груп керування («не більше трьох-чотирьох рівнів»).

• Проєкт — це контейнер із ключем. Він створюється автоматично: коли з'являється папка, що відповідає шаблону ключа напрямку (наприклад, {YY}GT{NNN}_{Name} у корені напрямку), створюється вузол проєкту, який успадковує налаштування від свого напрямку й отримує доступ через конектор лише до цієї папки. Він містить лише те, що відрізняється від напрямку: учасників, клієнта, специфікації. Він переходить зі стану «відкритий» у «закритий», а потім в «архівний» (Діаграма 2).

• Задача типізована. Її тип береться з каталогу напрямку (звіт про щільність, журнал буріння). Тип несе шаблон і критерії приймання. Результат повертається в папку проєкту відповідно до стандартів іменування компанії, і рецензент його приймає. Skills (навички) — це найближчий аналог типів задач, який сьогодні є в Claude. На плані Enterprise ними можна ділитися з групою, але це поширення, а не успадкування: ніщо не тече вниз по гілці.

Рекурсія тут навмисна. Модель життєздатної системи Стаффорда Біра каже прямо: «У рекурсивній організаційній структурі будь-яка життєздатна система містить у собі життєздатну систему і сама міститься в ній».

4.3 Один основний батьківський вузол плюс накладання

Крістофер Александер у 1965 році стверджував, що «місто — не дерево». Реальні структури перетинаються. Клієнт, специфікація агенції або тип задачі може охоплювати кілька напрямків роботи. Тому кожен вузол має одного основного батька, а наскрізні набори правил прикріплюються як накладання (uses). Конфлікти щоразу вирішуються однаково: заборона (deny) перемагає, інакше перемагає найближчий вузол.

4.4 Два канали, дві семантики

Це ядро дизайну, і саме тут більшість ієрархій дають збій.

• Контекст конкатенується. Інструкції та знання зливаються від кореня вниз, як це робить CLAUDE.md.

• Політика працює за принципом «заборонено за замовчуванням». Інструмент чи конектор дозволено, лише якщо дозвіл (allow) існує на всьому шляху від кореня, а явна заборона (deny) будь-де вище перемагає, як у AWS Service Control Policies. Батьківський вузол може позначити правило як примусове (enforced), і жоден дочірній не зможе його заблокувати, як у Group Policy.

Змішування цих двох речей — класична помилка. Рекомендаційний контекст має змішуватися. Примусове виконання — ні.

4.5 Компілюйте до того, як модель це прочитає

Сьогодні конфліктні інструкції розв'язує модель у момент генерації відповіді. Рішення — компілятор ефективних інструкцій, який працює до того, як модель щось побачить:

1. Злити контекст від кореня до листа.

1. Застосувати політику: deny перемагає, а allow має діяти на всьому шляху.

1. Врахувати примусові правила від батьківських вузлів.

1. Позначити кожне правило ID та його рівнем.

1. Впорядкувати блок за тим, наскільки широко використовується кожна частина, і застосувати бюджет токенів на рівень.

Конфлікти ніколи не доходять до цього етапу: вони відхиляються раніше, під час написання правила, а затверджує їх хтось інший, а не автор (Діаграма 3, нижній ряд).

Оскільки конфлікти вирішуються на етапі компіляції, результат можна впорядкувати за широтою використання кожної частини, а не суворо за глибиною: організація, напрямок, шаблон типу задачі, а потім специфіка проєкту. Такий порядок максимізує влучання в кеш (розділ 3.2). Він накладається на чотири точки розбиття кешу Anthropic із бюджетом токенів на рівень, хоча на практиці одна точка може знадобитися для самої розмови.

4.6 Ідентичності прив'язані до гілок, а не до людей

Ідентичність конектора (обліковий запис, тенант, scope) прив'язується до вузла, а не до людини. Claude Tag уже працює так для каналів Slack: адміністратор прив'язує сервісний обліковий запис до області дії, і перемагають облікові дані найвужчої області. Ця модель вимагає того самого на рівень нижче — для напрямку роботи та його проєктів. Людина, яка працює в двох організаціях, має два запечатані дерева; вона перемикає дерева, а не облікові записи. Ніщо не перетинається між ними, якщо власники обох явно цим не поділяться. Технічний примітив уже існує: специфікація авторизації MCP використовує OAuth-токени, прив'язані до аудиторії (індикатори ресурсів RFC 8707, метадані захищених ресурсів RFC 9728), і вимагає, щоб сервери «НЕ ПОВИННІ приймати чи передавати будь-які інші токени» (версія специфікації 2026-07-28).

4.7 Дозволи слідують за деревом

Суб'єкти: люди, групи, сервісні облікові записи, зовнішні гості (наприклад, клієнт) і сам агент.

Агент ніколи не перевищує повноважень людини чи вузла. Claude діє з дозволами користувача, який його викликав, перетнутими з політикою вузла. Він не може змінювати правила чи дозволи; він може лише пропонувати зміни. (Сьогодні Claude може самостійно оновлювати інструкції папок у Cowork. У цій моделі це стає пропозицією, яку хтось затверджує.)

Оцінка. Надання доступу тече лише вниз, ніколи вгору чи вбік. Ефективний дозвіл на вузлі — це те, що надають ролі на його шляху, в межах того, що дозволяє політика на всьому шляху, мінус будь-які заборони (deny) вище. Накладання надає доступ лише до власного вмісту: читання специфікації не відкриває проєкти, що її використовують.

Життєвий цикл.

• Відкрито: ролі діють як надано.

• Закрито: нові задачі не створюються, але незавершені перевірки можна закінчити.

• Архівовано: лише для читання всіма; відновити може тільки власник, і відновлення логується.

• Запечатане дерево: ніщо не перетинає межі без явного надання доступу.

Винятки та делегування. Винятки обмежені в часі, обґрунтовані, і їх затверджує хтось інший, а не ініціатор. Вони автоматично закінчуються і підраховуються, бо кожне перевизначення — це острівець постійного обслуговування; обмеження SharePoint щодо порушеного успадкування — повчальний приклад. Делегування ніколи не може надати більше, ніж має той, хто делегує. Доступ власника «на випадок аварії» (break-glass) існує, завжди логується і перевіряється постфактум.

На плані Team це працює без груп: дозвіл живе на вузлі, тому організація з чотирма ролями все одно отримує дозволи для кожної гілки.

4.8 Як взаємодіють рівні

Дерево варто будувати лише тоді, коли зміни проходять крізь нього. Три взаємодії виконують більшу частину роботи (Діаграма 5):

• Проштовхування вниз. Керівник напрямку публікує нову версію правила. Кожен проєкт у напрямку зчитує її під час наступної компіляції. Затверджений виняток зберігає стару версію до закінчення його дії, а вже збережені артефакти залишаються з тією версією, з якою були створені.

• Підтягування вгору. Учасник покращує шаблон в одному проєкті та пропонує його. Керівник напрямку, а не автор пропозиції, затверджує її, і сусідні проєкти її успадковують. Сьогодні таке покращення залишається в тому проєкті, де воно з'явилося.

• По горизонталі. Специфікація агенції змінюється один раз. Проєкти в трьох напрямках перекомпільовуються з нею, а самі напрямки не змінюються. Конфлікт із правилом напрямку відхиляється ще під час написання оновлення.

Один запит демонструє всі рівні одночасно (Діаграма 6): дерево перевіряє дозвіл учасника та стан проєкту, компілятор будує блок, Claude читає дані полів через ідентичність, обмежену папкою цього проєкту, повертає типізований артефакт назад у папку, а рецензент, який його не писав, приймає його. Кожен крок потрапляє в лог, а вартість списується на ключ проєкту.

4.9 Структура даних

Провіжинінг керований подіями: нова папка, що відповідає key_pattern у storage_root напрямку, створює вузол проєкту. answer_log забезпечує походження для кожної відповіді та вартість на вузол.

4.10 Вимірюйте результати, а не токени

Кожен тип задачі має критерії приймання: визначення готовності. З ними стає вимірною краща одиниця AI-роботи:

вартість підтвердженого результату = (вартість токенів + час перевірки) ÷ прийняті результати

Оскільки кожна відповідь логується щодо вузла, вартість AI можна списувати на ключ проєкту так само, як працю та матеріали. Окремі елементи цього вже існують: Claude Tag звітує та обмежує витрати на канал, а телеметрію Claude Code можна вручну тегувати за відділом, центром витрат або репозиторієм. Але жоден не прив'язаний до ключа проєкту, і жоден не ділить на прийняті результати. Для компанії, яка виставляє рахунки за номерами замовлень, AI стає прямою вартістю замовлення, а не накладними витратами. В інженерії ви платите за перевірений, запечатаний результат, а не за грифель для олівця. AI-роботу слід вимірювати так само.

4.11 Відповіді на заперечення

«Skills і плагіни вже це роблять.» Навичка завантажується, коли Claude вважає її релевантною, а це лише релевантність, а не гарантія. Провіжинінг дає навичку всім; на плані Enterprise плагін, що її несе, може бути обов'язковим для однієї групи. Це найближчий аналог напрямку роботи в чаті та Cowork сьогодні, але він програє у трьох аспектах: він лише для Enterprise, він орієнтований на людей, а не на проєкти, і ніщо не тече вниз від напрямку до його проєктів. Правило, яке має завжди діяти в одному напрямку, не може залежати від виявлення релевантності.

«Моди вже це роблять.» У Claude Code — частково, з 1 жовтня 2026 року. Мод може переписати системний промпт, відхилити виклик інструменту та намалювати панель, а моди організації виконуються перед модами людини. Тож компілятор, перевірка під час запису та перегляд ефективних інструкцій із цієї статті сьогодні можна було б реалізувати як мод, і розділ 6 про це говорить. Але залишаються три обмеження. Моди не працюють у чаті Claude, а в Cowork не діють налаштування консолі організації. Їхній порядок має двох власників — організацію та людину — без напрямку роботи між ними; на плані Enterprise плагін, обов'язковий для однієї групи, може принести мод цій групі, але він виконується як один із власних модів людини, без пріоритету. І мод — це код без пісочниці: щоб працювати перед модами людей, мод організації має лежати в каталозі на кожній машині, а налаштування з адмін-консолі «не можуть розмістити каталог на машині». Компанія без управління пристроями може розгорнути мод для всіх, але він працюватиме серед модів людей, а не перед ними. Компанія не повинна писати TypeScript, щоб сказати, що один відділ звітує в інших одиницях.

«Пам'ять вивчить правила.» Пам'ять здебільшого записує Claude для однієї людини чи одного проєкту, і власник не може читати чи редагувати спогади учасника. Аудитору потрібні правила, написані людиною, версіоновані, затверджені та простежувані до кожної відповіді. Anthropic уже тричі це реалізовувала: для дозволів — через «View effective role» та мітку «Granted by»; для навичок і плагінів — через історію версій і етап перевірки, де «ви не можете затвердити власне»; і для доступу Claude Tag — через мітки «Inherited from». Інструкції в проєкті не мають жодного з цих трьох.

«Claude Tag уже це робить.» Для каналів Slack — значною мірою так, і розділ 1 про це каже. Але трьох речей досі бракує. Канал — не проєкт: у нього немає папки, ключа, життєвого циклу, і «канал не можна прив'язати до Project». Дерево має три фіксовані рівні, тому компанії з напрямками роботи та сотнями замовлень доводиться сплющувати два свої рівні в назви каналів. І документація не описує жодної перевірки на конфлікт під час написання інструкції; області дії конкатенуються, а їх узгодження залишається на модель. Якщо на те пішло, Claude Tag — найсильніший доказ на користь дизайну цієї статті: та сама компанія обрала успадкування, облікові дані, прив'язані до області дії, та мітку походження, коли будувала продукт для команд.

«Ієрархії додають складності.» Лише якщо їхня глибина необмежена. Власна настанова Microsoft для груп керування — «не більше трьох-чотирьох рівнів». Ця модель фіксує чотири рівні з правилами, а папки групування, такі як серія та рік, взагалі не несуть правил.

«Успадкування — це ризик для безпеки.» Так, якщо доступ успадковується недбало. Хмарна відповідь працює: дозвіл (allow) має існувати на кожному рівні, заборона (deny) будь-де перемагає, Claude діє від імені користувача, перетнутого з вузлом, а власні зміни правил від Claude стають пропозиціями.

«Більше рівнів — більше токенів.» Розділ 3.2 показав протилежне в Claude Code: на 20% менше токенів інструкцій у вигляді каскаду, на 34% менше після компіляції, порівняно з плоскими копіями. Кожен додатковий файл трохи збільшує накладні витрати, тому компіляція краща за каскад. Типізовані задачі відкидають шаблони, що не використовуються, а скомпільовані префікси байт-в-байт ідентичні між проєктами, тому кешування промптів може їх перевикористовувати. В API Claude кеші ізольовані для кожного робочого простору, тому окремий workspace на організацію відповідає кореню дерева. Claude Code сьогодні цього не має: його кеш обмежений однією машиною та каталогом.

«Команди можуть просто вести власні проєкти.» Це сьогоднішній обхідний шлях, і прототип у розділі 5 виміряв, що він дає: дві з шести вставлених копій виявилися застарілими в невеликому демо.

5. Це працює вже сьогодні: еталонна реалізація

Щоб показати, що цю модель можна побудувати, а не лише обговорювати, я створив Worktree — невеликий десктопний застосунок (Node та Electron, 24 тести, що проходять на Windows і Linux), організований подібно до Claude Desktop. Відео вище — реальний запуск, скорочений лише там, де працював Claude. Це окремий застосунок, який керує Claude Code ззовні, а не мод. Він не викликає власну модель. Кожен чат запускає Claude Code, уже встановлений на комп'ютері (claude -p), з тим самим логіном, що є в Claude Code: підписка Claude або API-ключ. Я запустив його на вигаданій компанії з трьома напрямками роботи та шістьма проєктами. Коли хтось надсилає повідомлення:

• Дозвіл. Людина, що діє, потребує дозволу на проєкт або вище, а проєкт має бути відкритим. Адміна без дозволу на рівні напрямку було зупинено ще до запуску Claude.

• Перевірка. Спочатку працює перевірка під час запису. Правило SI з розділу 3.4 відхиляється як конфлікт із примусовим правилом компанії, тому воно ніколи не потрапляє до CLAUDE.md.

• Монтування. Дерево записується в реальні папки проєктів як один CLAUDE.md на рівень (організація в корені сховища, потім напрямок, потім проєкт), і власний каскад Claude Code їх завантажує. Скомпільований режим натомість записує один файл на проєкт. Файли без маркера застосунку ніколи не перезаписуються.

• Запуск. Шаблон задачі йде в --append-system-prompt-file. Те, що може робити Claude, контролюється Claude Code, а не CLAUDE.md: --allowedTools — це роль людини, перетнута з політикою кожного рівня, запис обмежений папкою проєкту, а --permission-mode dontAsk відхиляє все інше. У реальних запусках веб-пошук було відхилено, бо політика напрямку не дозволяє web, а запис поза папкою проєкту було заблоковано та залогировано.

• Логування та перевірка. Кожна відповідь логується разом із людиною, вузлом, усіма тегами правил, правилами, на які послався Claude, та токенами вводу, кешу й виводу, які повідомив Claude Code. Рецензент, який не писав відповідь, приймає або повертає її. Реальний запуск звіту про щільність у демо зайняв близько 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. На моїй машині це зменшило контекст запуску з 29,6 тис. до 21,4 тис. токенів. Очевидна альтернатива, --setting-sources project,local, зробила протилежне до того, що було потрібно в Claude Code 2.1.284 на Windows: вона залишила особистий файл і відкинула файли CLAUDE.md із батьківських папок, які несуть організацію та напрямок.

1. Моди людини теж витікають. Моди з'явилися наступного дня після створення застосунку, тому я їх протестував. Я встановив мод з одним хуком у власному користувацькому scope, який додає рядок до кожного промпту. Він дістався до запусків застосунку: завантажилися три правила організації, а також мій особистий рядок, і відповідь йому підкорилася. Додавання disableAllHooks до налаштувань запуску відсікло його і залишило три рівні CLAUDE.md недоторканими; тепер застосунок робить це автоматично. --safe-mode не є заміною: він прибрав мод і весь каскад CLAUDE.md разом із ним. Згідно з документацією, disableAllHooks в особистих налаштуваннях людини залишає працювати те, чим керує організація.

1. CLAUDE.md — це контекст, примусове виконання — це конфігурація. Документація Anthropic каже саме так: «Правила налаштувань примусово виконуються клієнтом незалежно від того, що вирішить зробити Claude. Інструкції CLAUDE.md формують поведінку Claude, але не є жорстким рівнем примусу». Застосунок на це покладається. Усе, що правило має гарантувати, відображається в дозволах інструментів; усе в CLAUDE.md — це рекомендація з тегом.

Це працює на сьогоднішньому Claude Code, а скомпільований текст можна вставити в чат або в інструкції проєкту Cowork на будь-якому плані. Одна залежність має термін придатності: застосунок покладається на те, що claude -p завантажує файли CLAUDE.md, а документація Anthropic каже, що --bare, який їх пропускає, «стане стандартним для -p у майбутньому релізі». Коли це станеться, застосунку доведеться передавати дерево іншим способом; скомпільований режим і --append-system-prompt-file уже це вміють. Це робоча специфікація для нативної версії, а не межа безпеки: «діяти як» — це демо-перемикач, а не вхід в обліковий запис.

6. Шлях від того, що вже випущено

У Claude Code — вже зараз. Починаючи з 1 жовтня дерево можна постачати як мод: скомпілювати правила вузла в розділ системного промпту, блокувати виклики інструментів, заборонені політикою вузла, і відображати діючі інструкції в окремій панелі. Організація зможе запускати такий мод до будь-чого, що встановлює користувач. Я цього не реалізовував; це перший пункт у дорожній карті еталонної реалізації. Це охопило б Claude Code і, можливо, сесії Cowork на машині користувача, які працюють на тому самому рушії. Але не чат.

30-денна версія для чату та Cowork. У Anthropic є всі складові. Дозвольте проєкту вказувати батьківський проєкт, чиї інструкції він успадковує — так само, як канал Slack успадковує налаштування свого робочого простору в Claude Tag. Скомпілюйте їх послідовно, додавши тег до кожного правила, і розмістіть панель «Переглянути діючі інструкції» поруч із наявною «Переглянути діючу роль». Лише це дасть кожному напрямку роботи єдине місце для зберігання правил.

Після цього кожен наступний крок буде корисним сам по собі, починаючи з того, що допоможе тарифам Team:

1. Вузли напрямків роботи та автоматичне надання ключових шаблонів, з повторним використанням семантики CLAUDE.md, яка вже працює в коді. У самому Claude Code етап зіставлення стає рівнем для групи між модами організації та модами користувача, а також керованими налаштуваннями для кожної групи.

1. Типи завдань як навички, обмежені рамками одного напрямку, з критеріями приймання.

1. Перевірка конфліктів під час запису, щоб суперечності відхилялися деревом, а не вирішувалися моделлю.

1. Дозволи (grants) на вузлах, які працюватимуть у Team без груп і розширюватимуть кастомні ролі Enterprise.

1. Ідентифікатори конекторів, прив'язані до гілок, для проєктів — так само, як Claude Tag уже прив'язує сервісний акаунт до каналу Slack.

1. Облік на рівні вузлів, прив'язаний до проєкту, як Claude Tag уже звітує по кожному каналу; опублікований тижневий ліміт у визначених одиницях; та розкриття інформації про витрати енергії на кожне завдання.

7. Обмеження

• Охоплення. 1 жовтня 2026 року повні покажчики сторінок code.claude.com/docs та claude.com/docs були відсортовані за назвами (466 сторінок), і близько 150 сторінок було прочитано разом із цитованими тут статтями довідкового центру. Попередні версії цієї статті взагалі пропустили Claude Tag; ця може пропустити щось інше. Claude for Government та Claude Desktop на сторонніх платформах згадуються, але не аналізуються.

• Функції платформи змінюються щомісяця, і одна змінилася просто під час написання цього тексту. Кожне твердження про продукт тут датоване 29 вересня – 1 жовтня 2026 року, і його слід перевірити заново, перш ніж на нього спиратися. Модам лише один день; я прочитав їхню документацію і протестував один випадок, але не використовував їх у продакшені.

• Виміряні показники в розділах 3.1–3.4 взяті зі звітів про використання самого Claude Code у двох партіях: Claude Code 2.1.286 від 2026-09-30 та 2.1.287 від 2026-10-01, обидві на Claude Sonnet 5.5. Скрипт, обидві партії та кожна відповідь зберігаються автором і доступні на запит. Вони включають власний промпт Claude Code (близько 30 200 токенів), який claude.ai та Cowork не використовують, і стосуються однієї моделі, одного демо-проєкту та одного запитання. Вибірки невеликі: десять відповідей для кожної умови щодо довжини відповіді, двадцять для кожної умови в тесті на конфлікти. Співвідношення довжини відповідей змінилися між двома партіями (розділ 3.3); дві партії з різницею в один день також відрізняються версією Claude Code, і я не можу відокремити цей фактор від випадковості.

• Час виконання, вартість та розміри контексту в розділі 5 взяті з власного журналу відповідей додатка за три демонстраційні запуски та один ручний тест ізоляції, які є особистими записами автора.

• Відповіді на конфлікти кодувалися автором без осліплення, шляхом прочитання кожної відповіді (чи повідомлялися одиниці; чи вказувала відповідь, яке правило перемогло і чому; чи ставила вона уточнювальні запитання). Усі сорок доступні на запит для перекодування. У тесті використовувалося одне формулювання слова «enforced»; інші формулювання, моделі та пари правил можуть поводитися інакше.

• Тест модів у розділі 5 — це один мод з одним хуком на одній машині Linux, з Claude Haiku, авторизацією через підписку та без керованих налаштувань. Я не тестував мод політики організації, вбудований захист при вході в Team або Enterprise, чи десктопний додаток.

• Модель вартості в розділі 3.2 — це симуляція ілюстративної компанії, а не фактичні виміряні рахунки. Вона враховує лише токени інструкцій; історія розмови, вивід та мислення зазвичай формують основну частину реальних рахунків. Розміри токенів використовують публічний legacy-токенайзер Anthropic × 1.30; під час вимірювань Claude Code завантажував на 21–26% більше за цю оцінку, тому суми в доларах виглядають заниженими. Відсотки є співвідношеннями і залишаються коректними. Патерни сесій та спільне використання кешу — це припущення.

• Чи застосовуються ціни API-кешу до використання чату на Enterprise і чи спільний кеш між користувачами на claude.ai, не задокументовано. Cowork запускає свої сесії на Claude Code, і хуки плагінів завантажуються там, але на сторінках модів Cowork не згадується, і я його не тестував; станом на 1 жовтня десктопний додаток все ще містив Claude Code 2.1.286 — версію, що передувала увімкненню модів. Керована політика пристрою поширюється на сесії Cowork на машині користувача, якщо тільки організація не запускає їх у повноцінній пісочниці VM. Дві сторінки суперечать одна одній щодо того, чи потрапляють власні файли ~/.claude користувача в Cowork, тому ця стаття не робить жодних заяв із цього приводу. Я також не перевіряв, чи завантажуються файли CLAUDE.md із батьківських папок у сесії Cowork; якщо так, то змонтоване дерево еталонної реалізації вже сьогодні досягало б Cowork на машині користувача. На тарифах Pro та Max це вікно звузиться 6 жовтня 2026 року, коли нові завдання Cowork перейдуть у хмару.

• Мотиви є висновками. Anthropic публічно не пояснювала, чому чат Claude та Cowork мають плоску структуру.

• Код і необроблені дані не публікуються разом із цією статтею. Читач не зможе відтворити вимірювання лише на основі статті; відео показує роботу додатка, а не те, як він побудований.

• Еталонна реалізація працює на вигаданій компанії. Вона не інтегрована з claude.ai чи Cowork, а «діяти як» — це демо-перемикач, а не вхід в акаунт. Дозволи забезпечуються списками інструментів Claude Code, а не самим додатком. Ізоляція вимикає власні хуки та моди користувача на час запуску; моди, вбудовані в Claude Code, продовжують працювати, а назви персональних агентів все одно можуть з'являтися в контексті. Додаток залежить від того, що claude -p завантажує CLAUDE.md, хоча Anthropic заявляє, що це перестане бути поведінкою за замовчуванням. Витік із персональних файлів та результат --setting-sources тестувалися на Windows; вимірювання та тест модів проводилися на Linux.

Джерела

• 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? (нова версія проєктів, бета)

• Anthropic, Get started with Claude Cowork (глобальні інструкції та інструкції для папок)

• 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 (бета нових проєктів) · 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 (без конфігурації для окремих груп) · Manage plugins for your organization (доступність плагінів за групами на Enterprise) · Plugin feature support across platforms (хуки ігноруються в чаті, завантажуються в Cowork) · Deploy managed settings (Cowork запускає свої сесії на Claude Code)

• Anthropic, Pricing (тарифи Sonnet 5.5, примітка про токенайзер) · Prompt caching (кеші ізольовані для кожної організації та кожного робочого простору в API)

• Anthropic, @anthropic-ai/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)

• Еталонна реалізація та дані: додаток Worktree, його тести, скрипт вимірювань, обидві партії результатів та кожна відповідь зберігаються автором і доступні на запит.