• Брифинг разбит на стадии; каждая возвращает типизированный JSON с флагом статуса
  • Один системный промпт на весь диалог деградирует по мере роста истории
  • Оговорка 2026: stage gate без lock-слоя не удерживает идентичность между шагами

Задача

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

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

Метод

Разбить брифинг на стадии и сделать каждую отдельным агентом с собственным промптом. Стадия возвращает не текст, а типизированный JSON: сообщение клиенту, поля, которые стадия обязана заполнить, и флаг статуса. Пока флаг false, оркестратор остаётся на стадии и передаёт ответ клиента тому же агенту. Когда флаг true, заполненные поля сохраняются в профиль проекта, и управление переходит к следующей стадии. Это stage gate: переход по типизированному выходу, а не по мнению модели о том, что «кажется, всё обсудили».

flowchart LR
    K([Клиент]) --> A[Агент стадии:<br/>типизированный JSON]
    A --> Q{Флаг<br/>статуса?}
    Q -->|false| K
    Q -->|true| P[Поля в профиль,<br/>следующая стадия]
    classDef key stroke:#FF3600,stroke-width:2px
    class Q key

Для продакшн-брифинга стадий пять: введение, основное видение, производственная услуга, бюджет и сроки, дополнительная информация с финальным резюме. Схема стадии «производственная услуга»:

{
  "message": "Уточните тип контента, цели, формат и результаты",
  "contentType": "",
  "goal": "",
  "format": "",
  "deliverables": [],
  "creativeSession": false,
  "serviceStatus": false
}

Пустые поля и false на входе; стадия закрыта, когда оркестратор видит заполненные поля и serviceStatus: true. Валидация механическая: схема либо проходит, либо нет, и ни модель, ни клиент не могут проскочить стадию словами.

Обновление, сентябрь 2026. Механическую валидацию с тех пор пришлось разделить на два слоя. В конструкторе приложений из таблицы, где модель тоже отдаёт типизированный JSON, первый слой проверяет форму ответа по схеме, второй — смысл: существует ли колонка, на которую ссылается поле, и подходит ли её тип. Форма может быть безупречной, а ссылка вести в пустоту. При провале любого слоя делается один автоматический повтор. Второй урок про нативные structured outputs: на схеме с объединением типов блоков провайдер отказал с ошибкой «Compiled grammar is too large», даже когда вариантов осталось четыре. Рабочим оказался путь из этой статьи: схема ответа описана в системном промпте, а JSON проверяется своей валидацией на Zod.

Каждый агент получает только то, что нужно его стадии: профиль клиента, накопленное резюме предыдущих стадий и последние ходы диалога, а не всю историю. Промпт стадии короткий: роль, задача, пример вопроса, схема ответа. Резюме накапливается инкрементально: после стадии видения есть резюме видения, после услуги к нему добавляется резюме услуги, и к финалу документ собран по частям, каждая из которых проверена своим гейтом.

flowchart LR
    P[(Профиль<br/>клиента)] --> A[Агент стадии:<br/>короткий промпт]
    R[Резюме прошлых<br/>стадий] --> A
    H[Последние<br/>ходы диалога] --> A
    A --> N[Резюме дополнено<br/>своей частью]

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

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

Где ломается

Раздувание токенов. В одном промпте стадии описаны все сразу, с примерами и правилами переходов, и к четвёртому ходу контекст состоит из инструкций, а не из разговора. Ответы становятся короче и беднее, модель начинает экономить на уточнениях. Стадийная схема лечит это тем, что каждый агент видит только свою инструкцию, но переносит нагрузку на оркестратор: он должен корректно собирать резюме и не терять поля между гейтами.

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

Оговорка 2026. Разделение на стадии выдержало проверку временем: тот же приём с типизированным выходом и флагом статуса повторяется в каждой агентской системе, которую я строил после. Но одного его недостаточно. Между стадиями плывёт идентичность: как называется клиент, как называется продукт, какой у бренда тон. Каждый агент видит только свою часть, и на пятой стадии продукт может называться иначе, чем на второй. Гейт проверяет форму, а не постоянство. Для этого нужен отдельный слой, который держит неизменяемые сущности поверх всех стадий, см. паттерн lock-слоя.

flowchart TB
    subgraph G1[Только гейты]
        direction LR
        A2[Стадия 2:<br/>название продукта] --> A5[Стадия 5:<br/>другое название]
    end
    subgraph G2[Гейты и lock-слой]
        direction LR
        L[Lock-слой:<br/>клиент, продукт, тон] --> B2[Стадия 2]
        L --> B5[Стадия 5]
    end
    G1 ~~~ G2
    classDef key stroke:#FF3600,stroke-width:2px
    class A5 key

Итог

  • Брифинг как последовательность гейтов: стадия закрыта, когда её JSON валиден и флаг true.
  • Каждый агент видит свою инструкцию и накопленное резюме, а не весь диалог.
  • Пять стадий, десятки полей, валидация механическая; выход — это бриф для планирования.
  • Stage gate проверяет форму; постоянство сущностей между стадиями держит lock-слой.

© Александр Никулин. Цитирование — с указанием автора и ссылкой · Версия для LLM