Недостающее звено: Структурирование ИИ-агентов для организационных иерархий

Эталонная модель того, как компании выстраивают работу с ИИ

Хосе Мартинес · 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), а «область действия — это место, где применяется пакет: доступ к Slack по умолчанию (корень на уровне организации), рабочее пространство или отдельный канал». Три вещи, о которых просит остальная часть этой статьи, здесь уже есть:

• Инструкции наследуются. «Кастомные инструкции для каждой области действия объединяются: сначала доступ к Slack по умолчанию, затем рабочее пространство, затем канал. Инструкции канала дополняют, а не заменяют то, что задано уровнем выше».

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

• Видно, откуда взялся доступ. В каждой строке коннектора, репозитория и плагина указано «Унаследовано от» более широкой области или «Привязано из» пакета. Лимиты расходов задаются для организации и для каждого канала отдельно, отчетность тоже ведется по каналам.

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

Что изменилось 1 октября 2026 г. В Claude Code 2.1.287 включили моды, ранее находившиеся в раннем доступе: это функции внутри плагина, которые работают прямо в Claude Code и могут переписать промпт или часть системного промпта, заблокировать или изменить вызов инструмента, одобрить или отклонить запрос прав доступа, а также рисовать собственные панели в интерфейсе. Здесь важны три момента:

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

• У порядка два владельца. Моды организации выполняются до пользовательских, или после них, если так решит организация. Слоя для направления работы нет. Настройки из консоли администратора «применяются одинаково ко всем пользователям в организации. Конфигурации для отдельных групп пока не поддерживаются». Если компания хочет разную политику для разных групп, есть два пути, и оба идут через IT: развернуть свой файл настроек на машинах каждой группы или запустить собственный шлюз, который «предоставляет управляемые настройки для каждой группы IdP».

• Они не доходят до чата и работают в Cowork неравномерно. «Моды работают в CLI Claude Code и на вкладке Code приложения Claude Desktop». Мод поставляется в файле hooks/hooks.json плагина, а таблица поддержки плагинов Anthropic помечает этот файл как «Игнорируется» в чате. В той же таблице для 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 применяет настройки через цепочку «тенант — группа — организация», а Claude Desktop у сторонних провайдеров тестирует политики для отдельных групп в бета-режиме.

2. Почему это важно

Проекты — не контейнеры. Настоящая задача — это контейнер. У нее есть ключ (номер задачи), родитель (направление работы), жизненный цикл (открыта, закрыта, архивирована по году), папка, клиент, люди, правила и результаты. У проекта в Claude есть только название в свободной форме, нет ключа, нет родителя и потомков, а его задокументированный жизненный цикл сводится к архивации и удалению. Cowork может привязать проект к локальной папке, но только вручную, по одному проекту за раз, без шаблона ключа и без родителя. Одно направление работы может открывать сотни задач в год. Остается два плохих варианта: либо по рукотворному проекту Claude на каждую задачу, каждый со своей копией правил, либо один проект на направление работы, где контекст разных клиентов лежит вперемешку.

Цепочка передачи нагрузки рвется. В строительной механике любая нагрузка должна иметь непрерывный путь до фундамента. Уберите один элемент — и всё, что над ним, перестанет передаваться вниз. С правилами всё точно так же. Когда между организацией и проектом нет промежуточного слоя, стандартам, шаблонам и правилам согласования направления работы просто негде жить. Поэтому каждый проект получает рукописную копию.

Копии расходятся. Исправили правило в одном проекте — остальные остались со старой версией. Каждый проект по-прежнему проходит собственную локальную проверку. Несовпадение всплывает, только когда кто-то сравнивает проекты рядом, а в регулируемых отраслях этим «кем-то» обычно оказывается аудитор. Инфраструктурные команды прекрасно знают этот сбой. По данным исследования Firefly 2026 года, около трети респондентов связали дрейф конфигураций с дорогостоящими инцидентами на проде, а примерно каждый пятый вообще не имел процесса для его обнаружения или исправления.

Идентичность тоже плоская. Многие люди работают сразу в нескольких организациях, и каждой нужен свой изолированный контекст. Внутри любой из них, в чате и Cowork, аккаунт коннектора принадлежит человеку, а не ветке. Роли Enterprise могут определять, какие коннекторы разрешены группе, а администратор может авторизовать коннектор один раз для всей организации; кастомный коннектор даже может использовать одни общие учетные данные для всех (в бете). Но в любом случае аккаунт принадлежит либо человеку, либо организации, и никогда — ветке: консультант, ведущий двух клиентов, не может привязать Drive каждого клиента к проектам этого клиента. Общие проекты делают проблему острее: «Коннекторы доступны только в приватных проектах». Claude Tag показывает, что возможен и другой подход, когда сервисный аккаунт привязан к каналу Slack, но и он упирается в границу проекта. На странице коннектора Google от Anthropic описан только один подключенный аккаунт, а задокументированный способ его смены — отключить и подключить заново; три открытых тикета (ниже) требуют поддержки нескольких аккаунтов. Граница существует только в голове человека, а это как раз тот тип ручного контроля, который незаметно дает сбой.

Никто не видит, какое правило сработало. Claude Enterprise показывает администраторам «Просмотр эффективной роли» для прав доступа, а команда /context в Claude Code перечисляет загруженные файлы памяти. Мод в Claude Code теперь может рисовать собственную панель, так что представление эффективных инструкций там может собрать кто угодно. В Claude Tag каждый коннектор и репозиторий помечены областью, от которой они унаследованы, но для инструкций документация советует «попросить Claude повторить его административные инструкции». Ни один интерфейс не показывает, какая инструкция для конкретного ответа пришла с какого уровня. Нет происхождения — нет аудиторского следа, нет аудиторского следа — нет системы качества.

Люди уже просят элементы этого решения. Открытые тикеты в публичном трекере задач Anthropic (github.com/anthropics/claude-code), проверено 01.10.2026:

Седьмой тикет, #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 % уже сейчас. Чего навыкам не хватает в чате и Cowork, так это области действия и наследования: навык не может принадлежать одному направлению и спускаться в проекты этого направления. (В Claude Code навык из подпапки действительно загружается для сессий, запущенных в ней или ниже). Во-вторых, это только токены инструкций, и в таком масштабе они обходятся от $14 до $149 в месяц в зависимости от кэширования. Основную долю реальных счетов составляют история диалога и выходные токены. Главный аргумент в пользу дерева — корректность, а на тарифе Team еще и пропускная способность. А не сумма в инвойсе.

Приведенные выше замеры воспроизводят эффект типизированных задач на реальном дереве в Claude Code, вместо предполагаемых размеров: −20 % для каскада и −34 % для скомпилированного варианта против −29 % в симуляции. Для направления с единственным типом задач типизация не даст никакой экономии.

3.3 Тот же ответ от реального Claude

Я задал Claude Code один и тот же вопрос сорок раз: десять независимых ответов для каждого из четырех условий, двумя партиями по пять штук с разницей в день. Вопрос заключался в том, проходит ли тест плотности грунта основания при 112,3 pcf относительно максимальной сухой плотности 115,8 pcf при требуемых 98 %. Инструкциями служили либо шесть правил компании, либо однострочный промпт «полезного ассистента», а языком — английский или испанский. Все сорок ответов пришли к одному вердикту: 97,0 %, не проходит.

Claude Code выдает два показателя вывода: оплачиваемые токены и то, сколько из них ушло на «размышления», которые пользователь никогда не видит.

Четыре вывода:

• Правила компании сделали ответы в 1,4 раза длиннее на экране и в 1,8–1,9 раза длиннее в счете. Видимая прибавка — это разделы с флагами, стандартами и ограничениями, которые требовали правила. В системе качества именно они представляют ценность.

• При использовании правил компании более трети оплаченного вывода было невидимым. 37 % оплаченных выходных токенов ушло на размышления, против 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 от 30.09.2026 и 2.1.287 от 01.10.2026, claude -p --output-format json, Claude Sonnet 5.5. Все инструменты были запрещены, а личные файлы ~/.claude исключены, поэтому между условиями различались только заявленные инструкции. Подсчет токенов взят из собственного отчета об использовании Claude Code, включая thinking_tokens; месячная стоимость рассчитана по тарифу Sonnet 5.5 ($10 за миллион выходных токенов), примененному к среднему оплаченному значению. Скрипт замеров, обе партии, сводные цифры и все ответы сохранены автором и предоставляются по запросу. В первой версии этой статьи эти числа оценивались с помощью сабагентов и публичного токенизатора; те оценки заменены новыми.

3.4 Когда правила конфликтуют, решает формулировка

Документация Anthropic признает, что противоречащие друг другу инструкции могут разрешаться «произвольно». Я протестировал конфликт того типа, который порождает отсутствие слоя направления. Правило организации требовало использовать американскую систему мер; правило проекта — указывать плотность в СИ. Я разместил их так, как это сделало бы дерево: правило организации в CLAUDE.md в корне хранилища, правило проекта в CLAUDE.md в папке проекта, и оба загружались собственным каскадом Claude Code. Затем я запустил ту же схему, но правило организации было помечено как обязательное исключительно словами: тег ENFORCED в названии и одна добавленная фраза: «Это правило обязательно: никакое правило направления или проекта не может его переопределить». Каждая схема прогонялась десять раз 30 сентября и еще десять раз 1 октября.

Ничего произвольного не произошло. Без явных указаний Claude каждый раз выбирал более близкое и конкретное правило. Четырнадцать из двадцати ответов объяснили почему («это правило более конкретно, чем общекорпоративное правило американской системы мер», или что оно переопределяет правило компании); пять сослались только на правило проекта, даже не упомянув, что правило компании ему противоречило. Когда обязательность была прописана словами, правило организации побеждало всегда, и каждый ответ указывал, что приоритет у обязательного корпоративного правила. Вторая партия воспроизвела единицы измерения в 10 случаях из 10 каждый раз, и разница между двумя строками далеко за пределами случайности (точный тест Фишера, p < 0,0001). Объяснения работали хуже: девять из десяти ответов объяснили победу правила проекта в первой партии, и лишь пять из десяти — во второй.

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

Ни одна модель не должна разрешать конфликты, которые организация могла поймать ещё на этапе написания правила. У Claude Code есть два частичных ответа. Команда /doctor prompt-audit просит Claude искать файлы инструкций, противоречащие друг другу, но только если её запускает человек. А с 1 октября моды могут задавать порядок на уровне кода: моды организации выполняются раньше пользовательских, а там, где загружается встроенная защита, запрещающие правила перебивают пользовательские моды. Но ни то, ни другое не касается текста инструкций. Файлы инструкций по-прежнему просто склеиваются, и документация описывает итог тремя способами: Claude «может выбрать одно произвольно»; при конфликте пользовательского и проектного правила «Claude может следовать любому из них»; и «когда инструкции конфликтуют, Claude использует собственное суждение, чтобы их согласовать». Результат «двадцать из двадцати» — это как раз то, как выглядело такое суждение в нашем случае. Claude Tag объявляет порядок для своих трёх областей видимости и называет результат «рекомендацией, а не принудительным ограничителем». Проверка в эталонной реализации отклоняет именно такое изменение — «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 the Pro plan’s per-session usage allowance», а у недельного лимита нет вообще никакой опубликованной цифры. Ни то, ни другое невозможно заложить в бюджет.

Как говорит 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). Конфликты всегда решаются одинаково: запрет побеждает, иначе побеждает ближайший узел.

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

Это ядро дизайна, и именно здесь большинство иерархий дают сбой.

• Контекст склеивается. Инструкции и знания сливаются от корня вниз, как это делает CLAUDE.md.

• Политика работает по принципу «запрещено по умолчанию». Инструмент или коннектор разрешён, только если разрешение есть на всём пути от корня, а явный запрет на любом уровне выше побеждает — как в AWS Service Control Policies. Родитель может пометить правило как enforced (принудительное), и ни один дочерний узел не сможет его заблокировать, как в Group Policy.

Смешивать эти два режима — классическая ошибка. Рекомендательный контекст должен смешиваться. Принудительный — нет.

4.5 Компилируйте до того, как это прочтёт модель

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

1. Слить контекст от корня к листу.

1. Применить политику: запрет побеждает, а разрешение должно действовать на всём пути.

1. Учесть принудительные (enforced) правила родителей.

1. Проставить каждому правилу ID и слой.

1. Упорядочить блок по широте использования каждой части и задать бюджет токенов на слой.

Конфликты никогда не доходят до этого шага: они отсекаются раньше, при написании правила, а согласовывает их кто-то другой, а не автор (Схема 3, нижняя дорожка).

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

4.6 Идентификаторы привязаны к ветвям, а не к людям

Идентификатор коннектора (учётная запись, тенант, область) крепится к узлу, а не к человеку. Claude Tag уже работает так для каналов Slack: админ привязывает сервисный аккаунт к области, и побеждают учётные данные самой узкой области. Наша модель требует того же на уровень ниже — для направления работы и его проектов. Человек, работающий в двух организациях, имеет два запечатанных дерева; он переключает деревья, а не аккаунты. Между ними ничего не переходит, если владельцы обоих явно этим не поделятся. Технический примитив уже существует: спецификация авторизации MCP использует OAuth-токены, привязанные к аудитории (RFC 8707 resource indicators, RFC 9728 protected resource metadata), и требует, чтобы серверы «MUST NOT accept or transit any other tokens» (версия спецификации 2026-07-28).

4.7 Разрешения идут по дереву

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

Агент никогда не превосходит человека или узел. Claude действует с разрешениями вызвавшего его пользователя, пересечёнными с политикой узла. Он не может менять правила или права — только предлагать изменения. (Сегодня Claude может сам обновлять инструкции папок Cowork. В этой модели это становится предложением, которое кто-то утверждает.)

Оценка. Права текут только вниз, никогда вверх или вбок. Эффективное разрешение на узле — это то, что дают роли на его пути, в рамках того, что разрешает политика на всём пути, минус любые запреты выше. Наложение даёт доступ только к своему содержимому: чтение спецификации не открывает проекты, которые её используют.

Жизненный цикл.

• Открыт: роли применяются как выданы.

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

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

• Запечатанное дерево: ничего не переходит без явного шаринга.

Исключения и делегирование. Исключения ограничены по времени и обоснованы, а утверждает их кто-то кроме заявителя. Они истекают сами и учитываются, потому что каждый переопределяющий костыль — это остров вечной поддержки; лимиты 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 плагин, обязательный для одной группы, может принести мод этой группе, но он выполнится как один из личных модов пользователя, без приоритета. И мод — это код без песочницы: чтобы работать раньше пользовательских модов, мод организации должен лежать в каталоге на каждой машине, а настройки из админ-консоли «can’t put the directory on a machine». Компания без управления устройствами может раздать мод всем, но он будет работать среди пользовательских модов, а не перед ними. Компания не должна писать TypeScript, чтобы сказать, что один отдел отчитывается в других единицах.

«Память выучит правила». Память в основном пишет Claude, для одного человека или одного проекта, и владелец не может читать или редактировать воспоминания участника. Аудитору нужны правила, написанные человеком, версионированные, согласованные и трассируемые до каждого ответа. Anthropic уже строила это трижды: для прав доступа — с «View effective role» и меткой «Granted by»; для навыков и плагинов — с историей версий и этапом проверки, где «you can’t approve your own»; и для доступа Claude Tag — с метками «Inherited from». У инструкций в проекте нет ни одного из этих трёх механизмов.

«Claude Tag уже это делает». Для каналов Slack — во многом да, и раздел 1 об этом говорит. Но трёх вещей всё ещё не хватает. Канал — не проект: у него нет папки, ключа, жизненного цикла, и «a channel can’t be pointed at a Project». Дерево состоит из трёх фиксированных уровней, поэтому компании с направлениями работы и сотнями проектов приходится сплющивать два уровня в названия каналов. И документация не описывает проверку на конфликт при написании инструкции; области видимости склеиваются, а согласовывать их оставляют модели. Если на то пошло, Claude Tag — сильнейшее доказательство в пользу дизайна из этой статьи: та же компания выбрала наследование, учётные данные, привязанные к области, и метку происхождения, когда строила продукт для команд.

«Иерархии добавляют сложности». Только если их глубина не ограничена. Сама Microsoft рекомендует для групп управления «не более трёх-четырёх уровней». Эта модель фиксирует четыре уровня с правилами, а группирующие папки вроде серий и лет правил вообще не несут.

«Наследование — это риск безопасности». Да, если доступ наследуется бездумно. Ответ из облачного мира работает и тут: разрешение должно быть на каждом уровне, запрет на любом уровне побеждает, Claude действует от имени пользователя, пересечённого с узлом, а правки правил самим Claude становятся предложениями.

«Больше слоёв — больше токенов». Раздел 3.2 показал обратное в Claude Code: на 20% меньше токенов инструкций в каскаде и на 34% меньше в скомпилированном виде по сравнению с плоскими копиями. Каждый дополнительный файл добавляет немного накладных расходов, поэтому компиляция лучше каскада. Типизированные задачи отбрасывают неиспользуемые шаблоны, а скомпилированные префиксы побайтово идентичны между проектами, так что кэширование промптов может их переиспользовать. В API Claude кэши изолированы по рабочим пространствам, поэтому рабочее пространство на организацию ложится на корень дерева. В 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. Проверяющий, который не писал ответ, принимает его или возвращает. Реальный прогон density-report в демо занял около 30 секунд; в трёх запусках Claude Code сообщил о $0,08–0,22 на ответ по прайс-листам. Claude ссылался на применённые правила, помечал результаты, близкие к пределу приёмки, и оставлял поля инженера пустыми.

• Дрейф. Каждый смонтированный 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. Пользовательские моды тоже утекают. Моды появились на следующий день после создания приложения, так что я их проверил. Я установил мод с одним хуком в своей пользовательской области, который добавляет строку в каждый промпт. Он добрался до запусков приложения: загрузились три правила организации, загрузилась и моя личная строка, и ответ ей подчинился. Добавление disableAllHooks в настройки запуска отсекло его и оставило три уровня CLAUDE.md целыми; теперь приложение делает это само. --safe-mode не замена: он убирал мод вместе со всем каскадом CLAUDE.md. Согласно документации, disableAllHooks в личных настройках пользователя оставляет работающим то, чем управляет организация.

1. CLAUDE.md — это контекст, а принуждение — конфигурация. Документация Anthropic говорит прямо: «Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude’s behavior but are not a hard enforcement layer.» Приложение на это опирается. Всё, что правило должно гарантировать, отображено на права инструментов; всё, что в CLAUDE.md, — рекомендация с тегом.

Это работает на сегодняшнем Claude Code, а скомпилированный текст можно вставить в чат или в инструкции проекта Cowork на любом плане. Одна зависимость устаревает: приложение полагается на то, что claude -p загружает файлы CLAUDE.md, а документация Anthropic говорит, что --bare, который их пропускает, «will become the default for -p in a future release». Когда это выйдет, приложению придётся передавать дерево иначе; скомпилированный режим и --append-system-prompt-file уже умеют. Это работающая спецификация для нативной версии, а не граница безопасности: «acting as» — это демо-переключатель, а не вход в систему.

6. Путь от того, что уже выпущено

Теперь в Claude Code. Начиная с 1 октября дерево можно поставлять как мод: компилировать правила узла в раздел системного промпта, блокировать вызовы инструментов, запрещённые политикой узла, и выводить действующие инструкции в отдельной панели. Организация сможет запускать такой мод до любых модов, установленных пользователем. Я этого не реализовывал — это первый пункт дорожной карты референсной реализации. Это покроет Claude Code и, возможно, сессии Cowork на машине пользователя, которые работают на том же движке. Чат это не покроет.

Версия на 30 дней — для чата и Cowork. У Anthropic есть все нужные детали. Позвольте проекту указывать родительский проект, чьи инструкции он наследует, — так же, как канал Slack наследует их от рабочего пространства в Claude Tag. Скомпилируйте оба по порядку, добавив тег к каждому правилу, и добавьте панель «Посмотреть действующие инструкции» рядом с существующей «Посмотреть действующую роль». Уже одно это даст каждому направлению работы единое место для хранения правил.

После этого каждый шаг полезен сам по себе, начиная с того, что поможет тарифам Team:

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

1. Типы задач как навыки, ограниченные рамками направления, с критериями приёмки.

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

1. Права доступа на узлах, которые работают в 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% больше этой оценки, поэтому суммы в долларах выглядят заниженными. Проценты — это отношения, и они сохраняются. Паттерны сессий и общий кэш — это допущения.

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

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

• Код и сырые данные не публикуются вместе с этой статьёй. Читатель не сможет воспроизвести замеры только по тексту; видео показывает работу приложения, а не то, как оно собрано.

• Референсная реализация работает на примере выдуманной компании. Она не интегрирована с claude.ai или Cowork, а «acting as» — это демо-переключатель, а не вход в аккаунт. Права доступа обеспечиваются списками инструментов Claude Code, а не самим приложением. Изоляция отключает хуки и моды пользователя на время запуска; моды, встроенные в Claude Code, продолжают работать, а имена личных агентов всё ещё могут появляться в контексте. Приложение зависит от загрузки CLAUDE.md командой claude -p, а 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, его тесты, скрипт замеров, обе партии результатов и каждый ответ хранятся у автора и доступны по запросу.