Изолированный «под-агент» с собственным системным промптом. Отвечает за одну тему: запись, перенос, цены, медицинский вопрос, общая справка, перевод на оператора. У каждой ветки — свой код (new_booking, price_question и т. п.) и активная версия настроек.

Системная ветка _router: отдельный, дешёвый вызов модели, который по последней реплике пациента возвращает один из кодов веток. Не отвечает пациенту напрямую — только классифицирует. Вызывается на КАЖДОЙ реплике, не один раз при входе.

Внутренний граф шагов внутри ветки. Сейчас есть только у new_booking: 6 шагов от приветствия до подтверждения записи. Модель на каждой реплике видит, на каком шаге сейчас, и какие слоты уже собраны.

Узел пошагового сценария. У каждого шага свой код (intro, qualify, present, offer_time, book, close), свой кусок промпта и список допустимых переходов.

Список кодов шагов, в которые можно перейти с текущего. Например, с qualify разрешено в qualify (остаться) или present (двигаться вперёд), но не в close. Если модель попытается перепрыгнуть через шаг — валидатор переходов (transition validator) отклонит запрос, мы останемся на шаге.

JSON-словарь данных, которые ветка собирает по ходу разговора. Для записи это name, reason, specialist, preferred_time, confirmed. Модель на каждой реплике их видит и обновляет — старые не переспрашиваются.

Список ситуаций, когда ветка должна вместо обычного ответа выдать служебный сигнал [INTENT_CHANGE: <код_ветки>] и передать диалог другой ветке. Например, если пациент в записи упомянул хирургию — ветка new_booking сама вернёт [INTENT_CHANGE: escalate_human].

Полная смена ветки внутри одного диалога с обнулением шага и слотов. Бывает в двух случаях: ветка сама выдала [INTENT_CHANGE] или маршрутизатор предложил другую ветку, которая не имеет пошагового сценария.

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

1. Пациент пишет что-то вроде «а сколько стоит приём?» внутри записи.
2. Маршрутизатор анализирует реплику и возвращает: general_info (в Песочнице — бейдж «роутер предложил: general_info»).
3. Система видит: тред уже идёт по многошаговой ветке new_booking, шаг qualify. Переключать опасно — потеряем контекст записи.
4. Вместо переключения: effective_code остаётся new_booking, в системный промпт ветки добавляется блок:

   [ПОДСКАЗКА РОУТЕРА]
   Роутер счёл, что тема — `general_info`.
   Ты ведёшь сценарий `new_booking`.
   Если пациент сменил тему — выдай [INTENT_CHANGE: general_info].
   Если реплика в сценарии — зафиксируй в слот и продолжай.

5. Модель new_booking получает весь этот контекст и сама решает:
   • Ответить на вопрос и остаться → вернёт {"state_after": "qualify", "soft_insertion": true} → бейдж «удержались в ветке» + «боковой вопрос».
   • Решить, что тема реально сменилась → вернёт [INTENT_CHANGE: general_info] → жёсткое переключение.

Ключевое: решение принимает модель ветки за один вызов, а не отдельный роутер. Подсказка роутера — просто контекст в промпте.

Ситуация, когда модель пошаговой ветки отвечает на вопрос вне сценария, не продвигая шаг и не меняя ветку. Типичные примеры внутри new_booking: «а сколько стоит приём?», «у вас есть парковка?», «как долго идёт приём?».

Откуда система знает, что это боковой вопрос? Модель сама сообщает об этом в структурированном ответе:

STATE_JSON: {"state_after": "qualify", "slots_updated": {}, "soft_insertion": true}

Флаг soft_insertion: true + текущий шаг в state_after + пустые slots_updated = «ответил на отвлечение, сценарий не двинулся».

Счётчик soft_insertion_count в состоянии диалога инкрементируется на каждом таком ответе и сбрасывается при смене шага или ветки. При трёх подряд — в системный промпт ветки добавляется жёсткое указание: «верни пациента к вопросу текущего шага».

В Песочнице: бейдж «тип ответа: боковой вопрос» (жёлтый) на ответе ассистента.

Каждая sm-ветка возвращает не только текст пациенту, но и служебный JSON-блок в хвосте ответа:

STATE_JSON: {"state_after": "qualify", "slots_updated": {"name": "Алексей"}}

Парсер вырезает этот блок (пациент его не видит), валидатор проверяет легальность state_after, обновляет состояние диалога. Необязательный флаг soft_insertion: true сигнализирует, что это был боковой ответ без продвижения сценария.

Если из пошаговой ветки произошёл переход в другую (например, посреди записи спросили про цены), её состояние (текущий шаг и собранные слоты) запоминается в полях suspended_intent, resumable_step_code, resumable_slots. Когда маршрутизатор увидит, что пациент возвращается к исходной теме («ладно, продолжаем запись»), мы автоматически восстановим шаг и слоты.

Счётчик handoff_count в состоянии диалога считает все переключения ветки. При превышении 3 переключений за диалог следующее переключение блокируется: диалог автоматически уходит в escalate_human с шаблонным ответом «Уточню детали с администратором клиники, свяжемся с вами в течение ближайшего часа». Это страховка от циклов вроде «запись ↔ цены ↔ запись ↔ цены».

Запись в БД (одна на диалог), хранящая текущую ветку, текущий шаг (если есть), собранные слоты, handoff_count и поля отложенного сценария. Видно в Песочнице справа, в блоке «Состояние диалога».