Дело о взрыве контекста: поиск случайного гостя, который захотел остаться

Всё началось со странной потери скорости решения задач.

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

Насчёт лимитов я особо не переживал. Подход моей AI-команды позволяет параллельно работать над несколькими крупными проектами на подписке Claude Code стоимостью 100 долларов. Команда разделена на роли, у каждой роли собственная рабочая область, задачи декомпозируются, а большие исследования можно выносить в отдельные сессии. Система была рассчитана именно на то, чтобы не складывать весь проект в голову одному агенту.

Но затем мой AI-архитектор продукта дважды ушёл в сжатие контекста.

Он работал на Opus с контекстным окном в один миллион токенов.

Первый раз можно списать на случайность. Второй — уже закономерность.

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

Началось расследование.

Тогда я ещё не знал, что системная проблема всей AI-команды началась, скорее всего, с одной моей ошибки в терминале.

Первый симптом: 24 минуты без работы

На экране ArchitectProduct-агента появилось:

Compacting conversation… (24m 47s · ↓ 85.5k tokens)

Compaction — это сжатие истории разговора. Когда сессия приближается к пределу контекстного окна, Claude Code создаёт краткое описание предыдущей работы и продолжает уже с ним. Иначе новые сообщения просто перестанут помещаться.

Механизм полезный. Но здесь сразу возникли два вопроса.

Во-первых, почему сжатие заняло почти 25 минут?

Во-вторых, как агент вообще успел исчерпать миллион токенов?

Да, задача была большой. Архитектор работал с архитектурной документацией, OpenAPI-контрактами, YAML-задачами, реестрами изменений и PlantUML-диаграммами. Но миллион токенов — тоже не маленькое окно. Чтобы заполнить его обычным чтением документации, нужно очень постараться.

При этом после сжатия интерфейс показывал около 110 тысяч токенов. Если смотреть только на текущий экран, всё выглядело даже успокаивающе: занято примерно 11%, впереди ещё огромный запас.

Только это были уже 11% после compaction. Что происходило до него, интерфейс не объяснял.

Дело передаётся AI CTO

Причину я поручил искать AI CTO моей команды. Это отдельная роль, которая тоже работает в Claude Code. Получилась немного ироничная схема: один Claude Code-агент расследует, почему другой Claude Code-агент потерял контекст.

Первый запрос был прямым: почему я вижу compaction, если у нас окно в миллион токенов?

AI CTO начал с проверки конфигурации: модель, effort, переменные окружения, локальные и глобальные настройки. Подтвердилось, что проблемная сессия действительно работала на Opus и что окно не было искусственно уменьшено проектной настройкой.

Затем он нашёл транскрипт нужной сессии ArchitectProduct и восстановил объём входного контекста по usage каждого запроса.

Картина оказалась странной.

Контекст не рос постепенно до миллиона. Он увеличился примерно на 540 тысяч токенов за один запрос.

537 433 → 1 077 204

Почти идеальное удвоение.

Первой версией стал слишком большой результат инструмента. Она выглядела разумно: AI-агент мог прочитать огромный файл, вывести целый контракт, развернуть документацию или случайно отправить в stdout содержимое большого набора артефактов.

AI CTO так и ответил: искать нужно крупный tool result, а массовые развёртки лучше выполнять через субагентов и возвращать в основную сессию только выводы.

Хороший совет.

Только причина была не в этом.

Ложный след: огромного вывода не существовало

Я попросил продолжить:

Исследуй, что дало такой выброс. Нужно найти причину.

AI CTO разложил usage на составляющие:

И вот здесь версия с огромным выводом начала разваливаться.

Свежий input вырос всего на два токена. Почти весь скачок пришёлся на cache_read_input_tokens — повторное использование уже закешированного контекста.

Мы посмотрели соседние события в JSONL. Перед выбросом агент проверял наличие PlantUML, затем извлёк 26 диаграмм. Результаты двух команд занимали 174 и 109 символов. После скачка был обычный FileNotFoundError примерно на тысячу символов.

Ни одного результата на полмиллиона токенов рядом не было.

Сам AI CTO в этот момент сформулировал важную мысль:

Скачок ровно вдвое подозрителен, надо убедиться, что это реальный контент, а не двойной счёт.

После этого он выгрузил записи транскрипта вокруг момента аварии:

07:40:04.173  TOOL_USE Bash               context = 537 43307:40:07.173  TOOL_RESULT               109 символов07:40:09.361  thinking               context = 1 077 20407:40:09.395  SERVER_TOOL_USE name=advisor07:40:41.186  ADVISOR_TOOL_RESULT               около 5 064 символов в зашифрованном виде07:43:34.991  This session is being continued from a               previous conversation that ran out of context.

Так в деле впервые появился советник.

Кто такой Advisor и почему он оказался подозреваемым

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

Но тут важно понять, что именно происходит при advisor().

Согласно официальной документации Anthropic, сервер запускает отдельный inference на advisor-модели и передаёт ей full transcript текущего executor’а — полную стенограмму работы основного агента на этот момент.

В неё входят:

• system prompt executor’а;

• определения доступных ему tools;

• предыдущие сообщения пользователя и модели;

• все предыдущие tool calls и их результаты;

• текст, который основной Claude уже успел сгенерировать в текущем ходе до вызова Advisor.

У самого Advisor при этом есть ещё собственный system prompt от Anthropic. Полная стенограмма executor’а передаётся ему как цитируемый контекст, после чего ответ возвращается основному агенту блоком advisor_tool_result, и тот продолжает генерацию.

И вот здесь есть неочевидная деталь. В транскрипте вызов выглядит почти пустым:

SERVER_TOOL_USE name=advisor input={}

Но пустой input не означает пустой prompt. Executor вообще не формирует аргументы этого инструмента: момент вызова выбирает модель, а весь контекст автоматически подставляет сервер. Поэтому за двумя фигурными скобками может скрываться стенограмма на сотни тысяч токенов.

Идея хорошая. Вместо того чтобы вести всю задачу на самой дорогой модели, можно дать основную работу более быстрой модели, а сложные решения эскалировать более сильному Advisor.

Но в нашей конфигурации основной агент уже работал на Opus. И Advisor тоже был Opus.

То есть Opus попросил второго Opus посмотреть на работу первого Opus.

Само по себе это не бессмысленно. Одинаковые модели могут пройти задачу разными траекториями и найти разные ошибки. Вопрос в другом: какой контекст получает второй проход и как этот контекст учитывается системой?

В проблемном запросе числа складывались почти идеально:

контекст основной сессии        ≈ 537kдобавка при вызове Advisor      ≈ 540k                                 ─────учтённый контекст запроса       ≈ 1.077M

Первая часть механизма теперь подтверждается не только нашими числами, но и документацией: Advisor действительно получает полную стенограмму executor’а. А вот почти двукратный рост cache_read_input_tokens — уже наблюдение из наших транскриптов.

Это различие важно. Официальная документация отдельно объясняет, что вызов проходит внутри одного запроса /v1/messages, но включает несколько итераций executor’а и отдельный advisor-inference. Верхнеуровневые поля usage суммируют итерации executor’а, а токены самого Advisor отражаются отдельно в usage.iterations как advisor_message. В нашем JSONL детальной разбивки iterations не было, поэтому число 1 077 204 корректнее называть учтённым контекстом всего запроса, а не размером одного физического prompt, отправленного Advisor.

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

Но один совпавший скачок — ещё не доказательство. У нас была сильная гипотеза, а не закрытое дело.

Для чего придумали Advisor и как изменилась его роль

На этом этапе я решил отдельно разобраться, откуда вообще взялся Advisor и для какого сценария его создавали. Эта часть расследования восстановлена по диалогу, сведённому в claude-code-advisor-dialog-summary.md, и затем сверена с официальной документацией Anthropic.

Первые временные метки видны прямо в технических идентификаторах:

advisor_20260301advisor-tool-2026-03-01

Они указывают на версию протокола от 1 марта 2026 года. А 9 апреля 2026 года Anthropic объявила Advisor Tool публичной beta-функцией.

Первоначальная идея была понятной и экономически красивой: основную работу выполняет быстрая и более дешёвая модель, а сложные решения она передаёт более интеллектуальной.

Sonnet или Haiku      │      ├── читает файлы      ├── пишет код      ├── запускает тесты      │      └── сложное решение                  │                  ▼             Opus Advisor                  │                  └── план или корректировка курса                              │                              ▼                    executor продолжает работу

Именно так функция до сих пор представлена в начале официального описания: более быстрый и дешёвый executor обращается к более интеллектуальному advisor, а основная генерация остаётся на дешёвой модели. Экономический смысл очевиден — приблизиться к качеству сильной модели, не оплачивая её на каждом шаге длинной задачи. Позже экспериментальный Advisor появился и в Claude Code.

Условно:

дешёвый executor + редкие дорогие консультации                    вместодорогая модель на протяжении всей сессии

Но текущая реализация Advisor не ограничивается эскалацией от слабой модели к сильной.

Текущая таблица совместимости требует, чтобы Advisor был не слабее executor’а, но отдельно разрешает моделям равной силы консультировать друг друга. В ней прямо присутствует конфигурация:

Opus 5 executor → Opus 5 Advisor

Это уже другая экономическая модель. Никакой передачи сложного случая «наверх» не происходит. Вместо неё запускается второй независимый inference того же уровня — second opinion.

Польза у такого режима может быть. Второй Opus способен заметить ошибку первого, предложить другую архитектуру или остановить неудачную траекторию. Но первоначальное преимущество схемы почти исчезает: мы больше не экономим на основном executor’е и вдобавок повторно обрабатываем его большой transcript моделью того же класса.

было задумано:    Sonnet → редкая консультация Opusполучилось в нашей сессии:    Opus 5 → консультация ещё одного Opus 5

Текущая документация равноправные связки описывает прямо, поэтому никакой тайны на стороне совместимости моделей здесь нет. Тайна была в другом: почему Advisor вообще стал доступен моим AI-сотрудникам, если ни одна роль и ни одна методология его не включала?

На этом этапе был зафиксирован только результат: основной Opus 5 сам вызвал Advisor Opus 5, хотя я не просил об этом в исследованной задаче. Теперь предстояло выяснить, когда инструмент появился в рабочих сессиях и откуда взялась его конфигурация.

Для короткой сессии второй проход того же уровня может быть терпимым. Но когда Opus передаёт второму Opus full transcript на 537 тысяч токенов ради финальной проверки, контекстная нагрузка становится принципиально другой.

Когда Advisor включился в моей AI-команде

Публичная дата запуска объясняла происхождение инструмента, но не отвечала на более важный вопрос: когда и по чьему решению он начал работать у меня?

AI CTO восстановил первый фактический вызов: 1 августа 2026 года, 16:46:51 UTC. Это была сессия e8786e56-… агента ProductWebProduce в проекте pasharealestateaz_lp. В журнале появилось событие server_tool_use с "name":"advisor"; ревьюером был claude-opus-5.

Хронология перед включением выглядела так:

Версия Claude Code всё это время оставалась 2.1.220. Сессия от 25 июля на этой версии ещё не содержала advisorModel; сессия от 1 августа на той же версии уже содержала. Значит, обновление CLI можно было исключить. Между двумя сессиями изменилось состояние конфигурации.

Единственная найденная улика — команда /advisor, набранная 30 июля. Транскрипт той сессии уже удалён, поэтому восстановить последовательность действий по журналу было нельзя. На этом этапе оставались разные версии: изменение локальной настройки, аккаунтный feature flag или ещё один неучтённый механизм.

К 8 сентября масштаб выглядел уже не как случайный эксперимент:

• 1180 вызовов Advisor;

• 503 из 713 сессий за период с 1 августа по 8 сентября;

• 56 каталогов агентов.

Больше всего вызовов пришлось на ipb10_docs/Architect — 226, aiteam/CTO — 192, ipb_authentication/Architect — 134, agent-orchestrator/ArchitectProject — 75 и ipb_frontend_core/ArchitectProduct — 52.

То есть Advisor распространился не на отдельную экспериментальную роль, а практически на всю команду. И особенно активно включался у архитекторов и CTO — именно у тех AI-сотрудников, которые работают с самым длинным контекстом. Для инструмента, повторно передающего full transcript, это худший возможный профиль нагрузки.

Проверка на 500 сессиях

Одной аварии было недостаточно. AI CTO проверил 500 доступных сессий и сравнил изменение учтённого контекста в запросах с Advisor и без него.

Первая версия расчёта оказалась неправильной: JSONL содержал повторяющиеся записи одного запроса, и они считались независимыми событиями. AI CTO заметил это и переписал анализ с группировкой по requestId.

После исправления в выборке осталось 43 646 последовательных запросов:

Восемь скачков без Advisor были сравнительно небольшими — например, с 43 до 85 тысяч токенов — и объяснялись обычными крупными результатами инструментов. С Advisor контекст почти удваивался в 94% запросов.

На всей выборке дополнительный учтённый контекст составил около 224 миллионов токенов.

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

Как миллион токенов превратился в половину миллиона

Если клиент использует такой верхнеуровневый учёт для запуска autocompact — а в исследованной сессии события шли именно в этой последовательности, — практическая ёмкость окна меняется.

Без Advisor условие выглядит так:

текущий контекст < 1 000 000

С потенциальным вызовом Advisor:

текущий контекст + ещё один текущий контекст < 1 000 000

Иными словами, окно в миллион токенов для такой конфигурации фактически начинает вести себя как окно примерно в полмиллиона.

При 300 тысячах всё ещё спокойно:

300k + 300k ≈ 600k

При 450 тысячах уже опасно:

450k + 450k ≈ 900k

А в нашей сессии получилось:

537k + 540k ≈ 1.077M

Буфер autocompact размером около 33 тысяч токенов здесь не помог. Он рассчитан на постепенный рост. Когда один запрос добавляет полмиллиона, система не подходит к порогу — она перепрыгивает через него.

В массовом анализе нашлось 33 случая, когда запрос с Advisor пересекал расчётный порог примерно в 967 тысяч токенов, хотя непосредственно перед вызовом основная сессия была ниже него. Средний исходный контекст в этих случаях составлял 556 234 токена.

Проверка через ChatGPT: был ли Advisor вообще нужен

Причину выброса нашёл AI CTO в Claude Code. Но я решил отдельно проверить не стоимость, а обоснованность самого вызова. Для этого передал сессию ChatGPT.

Вопрос был простой: происходило ли в тот момент что-то, для чего основному агенту действительно требовался совет второй модели?

Ответ — нет.

Основной агент уже работал на Opus 5 с высоким effort. Он не застрял, не повторял одну и ту же ошибку и не выбирал между двумя рискованными архитектурными решениями. К этому моменту работа была практически завершена, а сам Opus уже выполнил подробный self-review: перечитал требования, сверил документы, проверил реестры, downstream-задачи и дочерние проекты. Более того, эта проверка действительно нашла и позволила исправить неточность.

Последнее действие перед Advisor тоже не оставляло пространства для драматической эскалации:

Validate all PlantUML diagramsextracted 26exit=0

Проверка прошла успешно. После неё Opus 5 вызвал другого Opus 5 для ещё одной проверки уже проверенной работы.

Если разложить ситуацию по критериям, всё становится совсем однозначно:

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

Цена ничего не меняет в этой оценке. Она лишь показывает, насколько разрушительными оказались последствия ненужного решения: около 540 тысяч дополнительных учтённых токенов, выход за миллион, compaction и почти 25 минут ожидания.

В процессе этой проверки ошибся и сам ChatGPT. Сначала он не заметил отдельное событие Advisor в JSONL и принял 110.3k / 1m за объём сессии до инцидента. На самом деле это был уже сжатый контекст. После моего уточнения:

Так взрыв контекста произошёл именно при вызове advisor.

ChatGPT восстановил хронологию, признал ошибку и оценил вызов примерно в 2 балла из 10. Моя формулировка жёстче: в этой точке задачи оснований для Advisor не было вообще.

Этот эпизод заодно подтвердил ещё одну вещь: вторая модель не становится независимым аудитором только потому, что она вторая. Её выводы тоже приходится проверять по логам.

Откуда взялся непрошенный советник

После этого остался последний вопрос:

А где у нас написано, что нужно вызывать Advisor?

AI CTO проверил harness: описания ролей AI-сотрудников, методологию команды, навыки и локальные настройки.

Нигде.

В harness не было ни одного правила, требующего обращаться к Advisor.

Последняя улика нашлась в пользовательской конфигурации Claude Code:

"advisorModel": "opus"

Строка в ~/.claude/settings.json делала Advisor доступным сразу всем ролям на этой машине. После этого уже не я, а основная модель решала, когда ей требуется совет.

Это поведение соответствует официальному описанию: встроенное описание инструмента подталкивает executor вызвать Advisor в начале сложной задачи и при возникновении трудностей. Anthropic также предлагает направлять модель к Advisor до существенной работы и перед объявлением задачи завершённой. То есть отдельная команда для каждого вызова не требуется — решение принимает сам executor.

Теперь две улики сложились вместе.

Я часто меняю модель AI-сотрудника через навык model. По всей видимости, 30 июля я случайно набрал /advisor, увидел очередной выбор модели, принял его за привычный выбор основной модели и указал Opus. Только выбирал я в тот момент не модель сотрудника, а модель его советника.

Команда сохранила выбор в пользовательских настройках. Поэтому действие, совершённое в сессии одной роли, оказалось не локальным для этой роли. advisorModel подхватили все последующие сессии Claude Code на машине.

Транскрипт от 30 июля удалён, поэтому эту последовательность нельзя подтвердить покадрово. Но это наиболее вероятная реконструкция: единственная команда /advisor в истории, появление advisorModel после неё и первый автоматический вызов двумя днями позже.

Да, это была моя ошибка.

Я не собирался включать Advisor для всей AI-команды. Но, скорее всего, сам выбрал Opus в меню Advisor, не заметил разницы и тем самым создал глобальную настройку. Ошибка заняла несколько секунд. Её последствия работали больше месяца.

Советник всё равно остался непрошенным внутри конкретных задач: harness его не требовал, я его не вызывал, а решение о каждом обращении принимала модель. Но дверь для него, вероятнее всего, открыл я сам.

Как одна ошибка стала политикой всей AI-команды

Технически причина умещалась в одной строке настроек. Системной её сделал радиус поражения.

Я ошибся внутри одной сессии одного AI-сотрудника. Но выбор Advisor сохранялся не для этой сессии и не для этой роли. Он попадал в пользовательскую конфигурацию Claude Code и становился общим для всех AI-сотрудников на машине.

Дальше ошибка масштабировалась автоматически:

случайный вызов /advisor          ↓Opus выбран как модель Advisor          ↓advisorModel сохранён глобально          ↓инструмент доступен всем ролям          ↓каждая основная модель сама решает, когда его вызвать          ↓1180 вызовов в 503 сессиях

В обычной программе ошибка пользователя чаще всего заканчивается в том месте, где была совершена. В системе из AI-сотрудников одна неверная настройка управляющего слоя может разойтись по десяткам ролей и месяц работать в фоне. Чем автономнее команда, тем быстрее она воспроизводит не только правильную методологию, но и ошибочную конфигурацию.

Контекстная цена сделала этот случай особенно болезненным. У каждого автоматического инструмента есть не только функция, но и стоимость для рабочего состояния агента:

• какой объём истории получает новый inference;

• дублируются ли закешированные данные в учёте;

• приближает ли вызов compaction;

• сколько деталей потеряется после сжатия;

• сколько ролей унаследуют ошибку одновременно.

На короткой демонстрации удвоение двадцати тысяч токенов легко не заметить. В реальной сессии те же правила превратили 537 тысяч в 1,077 миллиона и остановили работу почти на 25 минут.

Я не перекладываю ответственность на Claude Code: ошибочный выбор сделал я. Но надёжная архитектура строится с учётом того, что оператор иногда ошибается. Настройка инструмента, способного повторно обработать весь контекст, должна иметь понятную область действия, наблюдаемые последствия и безопасное значение по умолчанию.

Что я сделал: отключил Advisor глобально

После расследования я не стал искать «более безопасный процент окна» и оставлять Advisor включённым для всей команды.

Я отключил его глобально.

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

Глобально Advisor отключается одной командой:

/advisor off

В исследованной версии Claude Code это не временное отключение только для текущего разговора. Команда очищает сохранённый выбор Advisor в пользовательских настройках. После неё параметр advisorModel исчезает из:

~/.claude/settings.json

Именно это я и сделал. Проверить результат можно, открыв файл настроек: строки

"advisorModel": "opus"

в нём больше быть не должно.

Исключение — сессия, запущенная с флагом --advisor: такой override относится только к выбранному процессу. Но в расследуемом случае Advisor пришёл именно из глобального advisorModel, поэтому /advisor off отключил его глобально.

До /advisor off конфигурация выглядела примерно так:

{  "model": "opus",  "advisorModel": "opus",  "theme": "dark"}

После команды:

{  "model": "opus",  "theme": "dark"}

Редактировать JSON вручную необязательно. Удаление advisorModel из файла остаётся запасным способом для старой версии Claude Code, headless-среды без текстовой команды или ситуации, когда нужно проверить и исправить конфигурацию напрямую. При ручном редактировании важно сохранить валидный JSON и убрать лишнюю запятую, если advisorModel был последним полем.

Возможность обратиться к советнику я оставил, но теперь включаю её только у того члена AI-команды, которому она нужна для конкретной задачи.

Здесь есть важный нюанс, на который я как раз таки и попался. Команда

/advisor opus

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

/advisor off

Для изолированного включения у конкретной роли безопаснее передать Advisor только при запуске её сессии:

claude --advisor opus

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

Таким образом, Advisor перестал быть неявной глобальной политикой и стал управляемым инструментом конкретного агента.

Это и есть моё решение по результатам расследования:

по умолчанию для всей AI-команды: Advisor OFFдля выбранного участника и конкретной задачи:    запустить с --advisor opus → выполнить работу → завершить сессию

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

Спичкой оказался автоматический второй проход по почти всей истории.

Вердикт: одна невнимательность и огромный радиус поражения

Самой дорогой частью моей ошибки был не выбор Opus. Ею стала область действия настройки, которая выглядела как действие внутри одной сессии, а повлияла на всю AI-команду.

AI-команда масштабирует действия оператора. Хорошо настроенная методология распространяется на десятки ролей и позволяет параллельно вести крупные проекты. Но тот же механизм масштабирует ошибку. Если неверное действие попало в общий управляющий слой, его последствия тоже становятся командными.

В моём случае ошибка влияла сразу на три ресурса:

• контекст — Advisor повторно получал full transcript основной модели;

• время — один из вызовов закончился почти 25-минутным compaction;

• качество рабочего состояния — после сжатия AI-сотрудник продолжал задачу уже без части деталей исходной истории.

Поэтому следить нужно не только за тем, правильно ли AI-сотрудники выполняют методологию. Нужно контролировать управляющий слой всей команды:

• какие настройки являются глобальными;

• какие инструменты доступны каждой роли;

• что изменилось после любой команды конфигурации;

• когда появляются новые типы tool calls;

• как меняются длительность задач, расход контекста и частота compaction.

Особенно осторожно нужно относиться к настройкам, область действия которых шире текущей сессии. Если команда введена внутри одного AI-сотрудника, это ещё не означает, что её последствия останутся внутри него.

Advisor задумывался как вторая пара глаз.

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

Ошибки оператора неизбежны. Системная проблема начинается тогда, когда одна такая ошибка может тихо пережить сотни сессий и затронуть десятки AI-сотрудников.

Поэтому настоящий вопрос не в том, сможете ли вы никогда не ошибаться. Не сможете.

Вопрос в том, какой радиус поражения будет у одной вашей ошибки.