Claude Code: паттерн Chief of Staff для оркестрации ИИ-агентов

Автор блога asyncdot.com описывает организационный, а не технический приём для долгих автономных сессий кодинга с Claude Code: одна сессия координирует и перепроверяет работу, а отдельные сессии её выполняют, состояние живёт во внешнем хранилище, а не в контексте, и каждый отчёт агента перепроверяется заново, прежде чем ему поверят. Автор называет это паттерном Chief of Staff, но подчёркивает, что сам термин не устоявшийся, та же схема известна как orchestrator-worker (супервизор), coordinator-implementor-verifier (CIV), maker-checker (из финансов и операций), integration manager (человеческий аналог из распределённых практик Git) и team lead с подчинёнными, так эту роль описывает собственная документация Claude Code по сабагентам. Отдельно автор разводит своё понятие с «chief of staff agent» из кукбука Anthropic: там это ассистент, ведущий календарь, почту и приоритеты CEO стартапа и раздающий задачи специализированным агентам, метафора та же, задача другая.

Проблема, которую решает паттерн: одна сессия ИИ-кодинга хорошо работает первый час и деградирует после. Три причины: контекст конечен и теряется, долгие сессии сжимаются (compaction), детали трёхчасовой давности превращаются в резюме без нужной конкретики; собственные отчёты агента расходятся с реальностью, фраза «тесты проходят» это пересказ намерения и памяти агента, а не свежая проверка, и разрыв растёт с длиной сессии; ничего не накапливается, урок, выученный на втором часу, пропадает к следующей сессии, если его никто не записал туда, где следующая сессия это прочитает. Добавление ещё агентов не чинит эту проблему, а умножает её: получается несколько ненадёжных источников отчётов без того, кто сверяет их между собой.

Роль координатора (в тексте её также называют overwatch): забирать и назначать задачи из постоянной очереди в заданном порядке; писать брифы, которые способна выполнить более слабая модель без суждений координатора; перепроверять заявленное исполняющей сессией, перезапуская те же команды; читать диффы, а не стенограммы разговора, важно то, что легло в код, а не что агент об этом сказал; записывать уроки в постоянный артефакт до конца сессии; направлять сбившуюся сессию, не забирая у неё саму работу. Координатор не пишет реализацию сам: в момент, когда он начинает кодить, он перестаёт проверять, и паттерн схлопывается в одну перегруженную сессию.

Три компонента: (1) среда выполнения агентов, Claude Code, даёт сессиям инструменты, редактирование файлов, доступ к shell и обмен сообщениями между сессиями; у каждой сессии свой контекст, и это осознанно, путаница одной сессии не заражает другую; (2) субстрат сессий, cmux, управляет терминальными рабочими пространствами и управляется из командной строки. Автор приводит пример команды cmux workspace create --name project-session-12 --cwd /path/to/repo --command 'claude "Read docs/briefs/current.md and do exactly what it says."' и предупреждает о двух неочевидных особенностях cmux: флаг --command просто вводит текст в shell рабочего пространства и не запускает агента сам, агента нужно вызывать явно, иначе команда напечатается в shell, который её не выполнит, а сам запуск при этом всё равно отчитается об успехе; а длинные командные строки ненадёжно выполняются в cmux, поэтому короткий промпт со ссылкой на закоммиченный бриф работает надёжнее, чем длинная строка, зарытая в истории shell; (3) постоянное хранилище состояния, Plan Desk, доска планирования, доступная агентам по MCP: проекты, цели, задачи со связями зависимостей, привязанные дизайн-документы и комментарии; координатор и каждая исполняющая сессия читают и пишут в одну и ту же доску. Автор называет доску тем компонентом, который чаще всего пропускают, и именно поэтому многоагентные связки не переживают ночь: доска, это память, сессии, расходный материал. На доске держат задачи как строительные контракты (постановка проблемы, пункты действий, интерфейсы, контракт проверки, что вне рамок, настолько подробно, что исполняющей сессии не нужно читать родительский документ, чтобы закончить работу), статус, который меняется атомарно вместе с работой (in_progress в момент старта, done в момент проверки, никогда не пачкой в конце сессии), привязанные дизайн-документы и комментарии, где человек оставляет указания, а агент, рассуждение.

Рабочий цикл, по одной задаче за раз, один запуск, один коммит: забрать следующую неблокированную задачу с доски; прочитать её дизайн-документ перед тем, как что-то трогать; сначала прогнать проверку и убедиться, что она красная (red gate), если проверка уже зелёная до начала работы, работа ничего не доказывает: нельзя отличить корректную реализацию от проверки, которая никогда не запускается, фильтра, который ничему не соответствует, или теста, утверждающего уже верное; попутно красный гейт дёшево ловит устаревшие задачи, часть задач в очереди на практике оказывается уже сделанной под другой карточкой или отменённой более поздним изменением, и зелёный ответ на первой же команде экономит час, который иначе ушёл бы на чтение уже существующего кода; поручить брифинг исполняющей сессии или сделать самому; перепроверить каждую заявленную команду заново, решают коды возврата; прочитать дифф построчно; провести через approval-этап с записанным обоснованием; зафиксировать статус, закоммитить именно эту задачу отдельно и записать прогресс. Один коммит на задачу держит историю git синхронной с доской, тема каждого коммита называет свою задачу, и путь от симптома, обнаруженного через три дня, до решения, это один git log.

Ядро статьи, дисциплина проверки. Отчёт агента, это улика, а не инструкция: когда исполняющая сессия сообщает «набор тестов зелёный, 49 проверок, ноль сбоев», задача координатора, выяснить, правда ли это, не потому что агенты лгут, а потому что предмет отчёта и предмет проверки часто оказываются двумя разными объектами. Автор приводит иллюстративный пример такого расхождения: сессия вручную вписала хеш коммита в лог-файл, а затем сверила его командой git cat-file, но не со строкой, которую сама записала в файл, а с коротким хешем из своей shell-сессии. Обе проверки прошли успешно, при этом файл содержал хеш, который никуда не разрешался: проверка и запись оказались двумя разными объектами, и проверен был только один. Отсюда правило: проверять артефакт, читая значение обратно из самого артефакта, а не из переменной, в которую, как вам кажется, вы его записали. Самый частый класс сбоя в агентной разработке, инструмент, который отчитывается об успехе за работу, которую не выполнил; у него много форм, и общая защита, любая проверка, которая может не найти совпадение, обязана явно сообщить об этом отдельно от нулевого результата, а утверждение об отсутствии чего-либо нуждается в позитивном контроле в том же запуске, иначе «ничего плохого не произошло» проходит просто потому, что ничего не запускалось. Прежде чем делать вывод об отсутствии, стоит сначала проверить инструмент на заведомо существующем случае: рабочий инструмент, ответивший «чисто», и сломанный инструмент дают одинаковый вывод.

Постоянные каналы связи надёжнее эфемерных: сессии могут писать друг другу напрямую, это полезно для уточняющего вопроса на середине прогона или для сигнала о противоречии, но канал недостаточно надёжен, чтобы на него полагаться: сообщение может застрять за занятой сессией, повиснуть на согласовании в зависимости от режима прав получающей сессии или истечь недоставленным, и молчание не означает согласие. Поэтому всё, что обязано дойти, идёт через постоянный канал: закоммиченные файлы (бриф, документ передачи, ограничение, сессии читают репозиторий при старте), карточки и комментарии на доске для контекста, специфичного для задачи, и ссылки-шаринги, большинство досок умеют отдавать задачу или документ как текст по URL, и в стартовый промпт лучше положить Context: <url>, чем вставлять контекст целиком: промпт остаётся коротким, а контекст поддерживается там, где он и должен обновляться. Сообщение, это намёк, файл, это контракт. Отдельная небольшая дисциплина: держать постоянную политику (правила цикла, маршрутизацию, стандарты, долгоживущее, редко меняющееся) отдельно от разового содержимого работы (брифы, контекст конкретной задачи, на доске или в scratch-директории); если их смешать, через полгода никто не разберёт, какие файлы вообще ещё что-то определяют. В сохранённом фрагменте текста статья обрывается на полуслове в разделе про таймбоксинг, и что именно автор рекомендует по таймбоксингу дальше, неизвестно.

Ключевые факты

• Одна сессия ИИ-кодинга хорошо работает около часа, затем деградирует: контекст сжимается, самоотчёты агента расходятся с реальностью, а уроки не накапливаются между сессиями.
• Решение, организационное: долгоживущая сессия-координатор (Claude Code) назначает работу, перепроверяет заявленные командой результаты и читает диффы, а не выполняет реализацию сама.
• Состояние держат вне контекста, на постоянной доске (в примере автора это Plan Desk по MCP), а рабочий цикл идёт по одной задаче: сначала проверка должна быть красной, затем перезапуск каждой заявленной команды и один коммит на задачу.
• Правило проверки: отчёт агента, улика, а не инструкция; артефакт проверяют, читая значение обратно из него самого, а не из переменной, куда его, как кажется, записали.
• Сообщения между сессиями ненадёжны и могут потеряться, постоянными считаются только закоммиченные файлы, карточки доски и ссылки на контекст по URL.

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

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

Кому это важно

Тем, кто уже строит или собирается строить многоагентные конфигурации на базе Claude Code, параллельные или долгоживущие сессии, которым поручают реализацию, а не просто разовые запросы. Полезно и тем, кто пишет собственные оркестраторы поверх других рантаймов: автор прямо говорит, что инструменты (cmux, Plan Desk) заменяемы, а роли, координатор, исполнитель, постоянное хранилище состояния, нет.

Как это применить

Автор описывает воспроизводимую структуру из трёх частей и восьми шагов. Три части: агентный рантайм (в статье, Claude Code, даёт инструменты, shell и обмен сообщениями между сессиями), субстрат сессий (в статье, cmux, запускается из командной строки; автор предупреждает, что его флаг --command только вводит текст в shell и не запускает агента сам, агента нужно вызывать явно, и что длинные командные строки в cmux ненадёжны, поэтому короткий промпт со ссылкой на закоммиченный бриф-файл работает лучше), и постоянное хранилище состояния (в статье, доска Plan Desk по MCP, где задачи оформлены как самодостаточные контракты, а статус меняется атомарно, а не пачкой в конце сессии). Восемь шагов цикла: забрать неблокированную задачу с доски → прочитать её дизайн-документ → прогнать проверку и убедиться, что она красная, ещё до начала работы → поручить исполняющей сессии короткий бриф или сделать самому → перезапустить каждую заявленную команду и доверять кодам возврата → прочитать дифф построчно, а не рассказ о нём → провести через approval с обоснованием → зафиксировать статус и закоммитить именно эту задачу одним коммитом.

Можно ли доверять

Источник, блог одного автора без указанной подписи и без данных о том, кто стоит за asyncdot.com, cmux или Plan Desk; версии перечисленных инструментов и цифры распространения в тексте тоже не приводятся. Это методологическое эссе, а не документация Anthropic и не независимо проверенное исследование: описанные приёмы, личная практика автора, изложенная как рекомендация. Отдельно стоит не путать этот «Chief of Staff» с одноимённым примером из кукбука Anthropic, там это совсем другой агент, ведущий календарь и приоритеты CEO стартапа, а не координатор кодинга.

Риски и подводные камни

Автор прямо называет главный источник ошибок: инструмент или проверка, которая отчитывается об успехе за работу, которую на самом деле не выполнила, как в примере, где сессия сверила вручную вписанный хеш коммита не с файлом, а с переменной в своей собственной shell-сессии, и обе проверки прошли, хотя итоговая запись была бита. Ещё риски: сообщения между сессиями могут застрять, повиснуть на согласовании прав или истечь незамеченными, молчание нельзя принимать за согласие; проверки на отсутствие чего-либо ложно проходят, если инструмент вообще не запускался, а не потому что искомого действительно нет; и смешение постоянной политики с разовым контентом задач со временем делает непонятным, какие файлы вообще ещё что-то определяют.

«Сообщение, это намёк. Файл, это контракт.»

— из поста на asyncdot.com