Почему одного хорошего текста недостаточно
Языковая модель умеет предложить идею, сформулировать объявление и разложить задачу на шаги. Однако она не знает автоматически, какие сведения о компании подтверждены, кто имеет право расходовать бюджет, активна ли интеграция и выполнила ли площадка отправленную команду. Если скрыть эти пробелы за уверенным тоном, получится впечатляющее демо, но не рабочий продукт.
Полезный агент обязан различать знание, предположение, предложение и выполненное действие. У каждого из этих состояний — свои доказательства и свои границы.
Контекст должен принадлежать проекту
Сначала агенту нужен разрешённый контекст: подтверждённые факты о продукте, аудитории, бренде, подключённых каналах и ограничениях. Такой контекст нельзя собирать в один бесконечный разговор. Он должен иметь структуру, версии, происхождение и проектную принадлежность.
Если данные противоречат друг другу или устарели, агент должен вынести неопределённость наружу: задать вопрос, предложить обновление или ограничить вывод. Догадываться молча — значит превращать удобство в риск.
Память и доказательство — не одно и то же
Агенту полезно помнить выбранный тон, рабочие предпочтения и последовательность обсуждения. Но память разговора не может заменить источник факта. Цена, условие доставки, ограничение продукта или юридически значимое обещание должны ссылаться на подтверждённую запись, а не на фразу, случайно произнесённую несколько недель назад.
Такое разделение делает систему спокойнее. Пользователь может свободно обсуждать идеи, не опасаясь, что каждая из них автоматически станет правилом бренда. Когда предложение действительно должно войти в знания проекта, агент показывает изменение и просит подтвердить его.
Предложение отделяется от исполнения
Когда пользователь просит запустить рекламу, агент сначала готовит предложение: цель, сегмент, сообщения, креативы, бюджет, критерии остановки и ожидаемые расходы сервисов. Затем детерминированный контур проверяет права, лимиты, согласования и идемпотентность.
Только после подтверждения создаётся задание на исполнение. Его результат проверяется по ответу внешней системы и сохраняется в журнале. Эта последовательность кажется строже мгновенной кнопки, зато она защищает от повторного запуска, неверного проекта и незаметного расхода.
Агент должен уметь честно не выполнить задачу
Провайдер может быть недоступен, модель — не соответствовать формату, рекламный кабинет — отозвать разрешение, а данных для вывода может не хватать. Рабочая система различает эти причины и предлагает следующий безопасный шаг. Она не подменяет отказ заранее написанным результатом и не переключается на дорогой резерв, скрывая изменение стоимости.
Стоимость и качество требуют наблюдения
Даже хороший маршрут со временем меняется: поставщик обновляет модель, цена растёт, задержка увеличивается, а ответы на русском языке становятся слабее или сильнее. Поэтому выбор модели нельзя навсегда зашить в рекламный текст. Он закрепляется в конфигурации выпуска и проверяется на эталонных задачах.
Для каждой попытки система учитывает модель, время, расход, ошибку и использование резерва. Пользователь видит понятную итоговую стоимость, а команда продукта получает основание для решения: где достаточно экономичного маршрута, а где сложная задача действительно оправдывает более сильную модель.
Как выглядит хороший пользовательский опыт
В простом режиме человек видит короткий диалог, ясное предложение, стоимость, необходимое подтверждение и полученный результат. В профессиональном — источники, версии, попытки, параметры и журнал. Это одна и та же операция, показанная с разной глубиной.
Именно поэтому интерфейс агента может быть очень простым, а система за ним — строгой. Простота для пользователя достигается не устранением правил, а их правильной организацией.