Вы — CEO: почему иерархия агентов — это управление контекстом

Генеральный директор не знает, как один из его разработчиков пишет запрос к базе, и ему это не нужно. С разработчиками говорят тимлиды, с тимлидами — менеджеры, а CEO нужно знать, что задачи решаются. Со стороны это похоже на бюрократию. На деле это способ беречь единственное, чего нельзя добавить: внимание.

Если вы запускаете несколько ИИ-агентов, вы сидите в кресле CEO, а у ваших агентов тот же предел в другой форме. Эта статья — о том, почему организации устроены именно так, где это ложится на окно контекста модели, что говорят наши числа (включая одно, которое нас удивило) и где эта идея не помогает.

Дефицит — это внимание

Герберт Саймон сформулировал это в 1971 году: «в мире, богатом информацией, изобилие информации означает нехватку чего-то другого: того, что информация потребляет. Что она потребляет, довольно очевидно: она потребляет внимание тех, кто её получает. Поэтому изобилие информации порождает бедность внимания» (в нашем переводе).

Арифметика внимания руководителя хуже, чем кажется. В 1933 году В. А. Грайкунас считал не только людей, которыми руководит менеджер, но и связи, которые тому приходится держать в голове. Для одного, двух, трёх, четырёх, пяти и шести подчинённых получается 1, 6, 18, 44, 100 и 222. Он предлагал, чтобы подчинённых было не больше пяти, а в большинстве случаев — четыре. В учебниках по управлению это называют нормой управляемости (span of control).

Фред Брукс сказал то же о командах в 1975 году. Если каждую часть задачи надо согласовывать с каждой другой, каналов связи между n людьми n(n−1)/2. Дереву нужно куда меньше: у n людей, связанных деревом, n−1 связь (наша арифметика). Поэтому каждая растущая компания добавляет уровни.

Иерархия — ещё и о том, чего каждому уровню знать не нужно

В 1972 году Дэвид Парнас предложил правило, как резать программу на модули: «начинать со списка трудных проектных решений или таких, которые, вероятно, изменятся. Каждый модуль затем проектируется так, чтобы скрывать такое решение от остальных» (в нашем переводе). Интерфейс показывает как можно меньше. Разработчику не нужна стратегия компании, лиду не нужен код; каждый скрыт за интерфейсом «задача» и «результат».

Луис Гарикано показал в 2000 году, почему организации так делят знания. В иерархии на знаниях «рядовые исполнители осваивают самые частые и лёгкие задачи, а специалисты разбирают исключительные и трудные» (в нашем переводе). Частый случай остаётся внизу, наверх идут только исключения.

Мелвин Конвей добавил обратное в 1968 году, и это теперь называют законом Конвея: «организации, проектирующие системы (в широком смысле), вынуждены создавать проекты, которые являются копиями структур связи этих организаций» (в нашем переводе). То, как люди общаются, определяет форму того, что они строят, — так что структуру общения стоит проектировать.

Армии решали ту же задачу через замысел командира (commander’s intent). В одном из кратких описаний доктрины mission command подчинённым, которые понимают намерения командира, свои задачи и контекст, «говорят, какого эффекта достичь и зачем он нужен» (Джим Стор, 2003, в цитате на Википедии; сам устав армии США нам открыть не удалось). Так и работает хорошее описание роли: цель и то, что считать результатом, а не каждый шаг.

Контекст модели — это её рабочая память

Инженеры Anthropic называют эту практику context engineering, «инженерией контекста»: «набор стратегий для отбора и поддержания оптимального набора токенов (информации) во время вывода модели». Они отмечают, что «по мере роста числа токенов в окне контекста способность модели точно вспоминать информацию из него снижается», и что у моделей есть «бюджет внимания», который они тратят при разборе больших объёмов контекста. Один из приёмов для долгих задач — субагенты: «каждый субагент может долго исследовать, используя десятки тысяч токенов и больше, но возвращает лишь сжатую выжимку своей работы (часто 1 000–2 000 токенов)» (сентябрь 2025, в нашем переводе). Это брифинг для CEO в миниатюре.

Chroma проверила 18 моделей в июле 2025 года и сообщила, что «модели используют контекст неравномерно; вместо этого их результаты становятся всё менее надёжными по мере роста входа» — «гниение контекста» (context rot). Авторы добавляют, что реальная работа с длинным контекстом часто сложнее их задач и что они «ожидали бы ещё более сильного падения качества в таких условиях» (в нашем переводе).

Есть и ценовая сторона, мы разбирали её в статье «Куда уходят токены агентов»: на каждом шаге заново отправляется весь разговор. В нашу неделю 23–29 сентября 2026 года по ценам API шаг при контексте 100–200 тысяч токенов весил 0,054 $, а при 400–700 тысячах — 0,155 $, примерно в 2,9 раза больше. Это вес шага, а не готовой работы, и это вес по ценам API, а не счёт.

Как это делаем мы: что делает сборка

Свои команды мы ведём так, поэтому вот как это выглядит в harnsy — и только то, что делает сборка. Это наша команда сайта во вкладке Teams: лид наверху и роли под ним.

• Вы говорите с лидом, а не с каждым агентом, и принимаете результаты на карточке в дашборде.
• У ролей есть задача и результат. Роль — версионируемый документ (шаблон компании плюс слой проекта). Каждому агенту на роли при старте велено его прочитать, и агент это подтверждает; после правки агенты, не прочитавшие новую версию, видны как отставшие. Инструкции со временем меняются, и живут они в роли.
• Лид отдаёт работу ролям. Задача идёт на роль, исполнитель сдаёт её с доказательствами, и принимает тот, кто её заказал: лид — работу, которую сам раздал, человек — свои запросы.
• Передача дел несёт суть. Когда контекст агента подходит к пределу, он пишет записку; свежий агент начинает с текста роли и записки, а не со всего разговора, и подтверждает это. Порог задаётся на роль.
• Это иерархия решений с короткой боковой петлёй. В нашей команде коммит идёт от автора к ревьюеру, затем к интегратору и обратно к автору, минуя лида. Так что это не строгое дерево, и мы не рисуем его деревом.
• Уведомления о задачах собираются в пачку. Начиная с v0.7.0 уведомления о рабочих задачах (переход, заметка, вложение, изменение чек-листа, новая задача) ждут в очереди и доходят до свободного агента одним сообщением: через 60 секунд после последнего уведомления, не позже чем через 3 минуты после первого, до 15 в сообщении. Не собираются: решения человека из дашборда, оповещения о контексте и сообщения между агентами.

Ещё два вида той же команды: текст роли лида с его версиями и одна задача из работы над этим блогом.

Такая же команда на вашей машине: установить harnsy.

Поворот: контекст лида не чистый

Когда мы планировали эту статью, аккуратная версия была такой: у лида чистый стратегический контекст, а код несут разработчики. Наши данные говорят другое.

Числа — из транскриптов Claude Code всех команд на нашей машине за неделю 23–29 сентября 2026 года (29-е неполное). Лид нашей команды продукта в среднем нёс около 430 тысяч токенов контекста на шаг, на 7 160 шагах. Медиана по ролям этой команды — около 300 тысяч (315 тысяч; 285 тысяч по 53 ролям всех команд), а архитектор был ниже 100 тысяч (75 тысяч, малая выборка — 143 шага). В той команде было около 30 активных ролей. Не каждый лид так высок: у лидов трёх небольших команд 140–167 тысяч, ещё у двух — 339 и 363 тысячи. Десять из двенадцати основных сессий этого лида прошли отметку 400 тысяч токенов, девять закончили неделю на 732–854 тысячах; две остальные — короткие сессии.

Чем он заполнен? Мы разложили по источникам то, что попало в двенадцать основных сессий этого лида, в символах, а не в токенах. Больше всего — входящие сообщения других агентов, и вместе с собственными отправками лида и его обращениями к задачам и составу команды это около 56% координации:

Для контраста, по той же методике разговор разработчика на 91% состоит из его собственной работы с инструментами (результаты инструментов 48%, команды 43%) и лишь на 4,7% из сообщений; у ревьюера 64% — результаты инструментов, то есть диффы и вывод тестов, и 7,7% — сообщения.

Ещё две вещи. Каждая новая сессия стартует с медианы 48 тысяч токенов до начала работы, по 275 сессиям: системный запрос, инструменты, инструкции проекта и текст роли. Текст роли не бесплатен. И оговорки настоящие: символы — не токены, разбивка сделана по шаблонам, это один лид и двенадцать сессий, прошлые недели не считались.

Так что контекст лида растёт от координации: отчётов других агентов и его собственных ответов. Контекст разработчика растёт от результатов работы. Поэтому лиды тоже передают дела, и поэтому harnsy собирает свои уведомления о задачах в пачку. Это же и предел такого исправления. За ту же неделю 73,5% веса по ценам API пришлось на ходы, которые разбудило сообщение другого агента или системное уведомление, и лишь около 30 $ из 4 799 $ в этих ходах были собственные уведомления harnsy. Остальное — агенты пишут друг другу, и продукт это не уменьшает; уменьшают только собственные правила агентов: писать реже и короче.

Панель лида показывает, где проходит предел: насколько заполнен контекст и в какой точке лид передаёт дела. По умолчанию это 40% окна; роль может задать своё значение.

Разделение контекста: механизм и арифметика, а не результат

Если один агент держит и стратегию, и весь код, на каждом шаге он перечитывает всё это. Разделите по ролям: лид держит цели и решения, разработчик — код, ревьюер — дифф. Дальше — только арифметика. Если три роли работают при контексте 100–200 тысяч вместо одного агента при 400–700 тысячах, шаг весит 0,054 $, а не 0,155 $ (наши ценовые диапазоны, неделя 23–29 сентября 2026).

Здесь не учтены дополнительные шаги, которые добавляет координация, и мы не сравнивали одного агента с ролями на одной и той же работе. Это механизм, а не измеренный результат. Наши же числа говорят, что и роли сами доходят до 300 тысяч и больше: медианная роль на той неделе была около 300 тысяч.

Где это не помогает

Маленькие задачи. У роли есть постоянная цена: старт сессии, текст роли, передача дел. Если работа — одна небольшая правка, дешевле один агент.

Координация стоит токенов. Anthropic пишет про свою многоагентную исследовательскую систему, что «многоагентные системы используют примерно в 15 раз больше токенов, чем чаты» и что им «нужны задачи, ценность которых достаточно высока, чтобы окупить рост качества» (в нашем переводе). В той же статье сообщается, что система с Claude Opus 4 в роли лида и субагентами Claude Sonnet 4 обошла одиночный Opus 4 на 90,2% на их внутренней оценке исследовательских задач. Это их мера на их задаче; она показывает, что многоагентная оркестрация (multi agent orchestration) может окупаться, но не что окупается всегда.

Агенты по-прежнему дрейфуют, и работу по-прежнему должен принимать человек; мы писали об этом в статье «ИИ-сотрудники: работает не „персонаж“, а рабочее место». А сбои многоагентных систем в основном о том, как они устроены: в исследовании MAST размечено более 1 600 трасс и найдено 14 видов сбоев в трёх группах — устройство системы, рассогласование агентов и проверка результата. Иерархия ролей сама по себе плохое устройство не исправит.

Попробуйте на одной команде

• Назначьте одного лида и дайте человеку говорить только с ним.
• Напишите для каждой роли текст с результатом: цель и что считать готовым, а не каждый шаг.
• Передавайте дела запиской до того, как контекст подойдёт к пределу, и запускайте следующего агента с роли и записки.
• Договоритесь о правиле для сообщений между агентами: их мало, и они короткие.
• Следите за контекстом лида: он растёт от сообщений, а не от кода, и лиду тоже нужна своя передача дел.
• В течение недели считайте, как часто работа возвращается и сколько стоит шаг. Потом решайте, окупается ли разделение на вашей работе (наша практика).

Источники

• Herbert Simon, «Designing Organizations for an Information-Rich World», 1971, цитата на hapgood.us.
• V. A. Graicunas, «Relationship in Organization», 1933; числа и рекомендация по пересказу Никольса: nickols.us.
• Fred Brooks, The Mythical Man-Month, 1975, формула n(n−1)/2 по Википедии.
• David Parnas, «On the Criteria To Be Used in Decomposing Systems into Modules», CACM, декабрь 1972: PDF.
• Luis Garicano, «Hierarchies and the Organization of Knowledge in Production», Journal of Political Economy 108(5), 2000: RePEc.
• Melvin Conway, «How Do Committees Invent?», Datamation, 1968: melconway.com.
• Mission command и замысел командира, со ссылкой на Jim Storr (2003): Википедия.
• Anthropic, «Effective context engineering for AI agents», 29 сентября 2025: anthropic.com.
• Kelly Hong, Anton Troynikov, Jeff Huber, «Context Rot», Chroma, 14 июля 2025: trychroma.com.
• Anthropic, «How we built our multi-agent research system»: anthropic.com.
• «Why Do Multi-Agent LLM Systems Fail?», NeurIPS 2025: arXiv 2503.13657.