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

Сначала договоримся, какую работу должен выполнить маркетинг
Представим обычное совещание небольшой компании. Собственник хочет новых покупателей, маркетолог — быстрее выпускать материалы, руководитель продаж — получать обращения с понятной задачей. На экране появляется команда ИИ-агентов. У одного красивый аватар, у другого серьёзная должность, третий уже рисует стратегию. Все участники довольны, потому что каждый успел представить себе собственного цифрового сотрудника. Проблема проявится позже: наняли вроде бы одну команду, а договорились о трёх разных работах.
Поэтому агентский маркетинг я бы начинал с предложения, которое можно произнести без названия нейросети: «Человек приходит из такого источника, получает такую помощь и может сделать такой следующий шаг». Если вместо этого приходится перечислять исследователя, копирайтера, квалификатора и оркестратора, процесс пока описан со стороны подрядчика. Для покупателя там ещё нет законченного действия.
Первый процесс нужен как небольшая проверяемая единица бизнеса. Например, участник партнёрского сообщества приносит неполное задание на мебель, получает список нужных размеров и может передать исходные данные на расчёт. Внутри могут работать модель, поиск по документам, обычные правила и человек. Покупатель не обязан разбираться в составе бригады, чтобы понять полученную помощь. Описанный пример учебный: он объясняет устройство работы, а не сообщает о клиентском результате.
Выбирайте ситуацию покупки, а не самое эффектное действие агента
Хороший кандидат находится там, где у потенциального покупателя уже есть предметная трудность, компания умеет её разбирать и после помощи существует разумное продолжение. Вопрос «какой кухонный фасад выбрать» слишком широк для первого запуска. Вопрос «какие исходные данные нужны, чтобы сравнить два предложения на одну кухню» заметно удобнее: можно задать границы, проверить материал и увидеть, готов ли человек продолжить работу.
Оценивать стоит весь переход. Допустим, агент способен находить публичные вопросы, но компания не готова отвечать на них по существу. Или умеет составлять предварительный подбор, но наличие и применимость товара нигде не подтверждены. В таких случаях сложная технология только быстрее приведёт к отсутствующему звену. Выбирайте процесс, у которого понятны входные сведения, допустимый ответ, получатель результата и действие сотрудника после обращения.
Полезен и вопрос о замене: что произойдёт, если эту же работу сделает обычная форма, инструкция или человек по шаблону? Если все варианты одинаковы, а ИИ лишь пересказывает три заранее известных фразы, запуск может быть проще без агента. В исследовательском материале Anthropic о построении агентов различаются заданные маршруты и более самостоятельный выбор действий; там же предлагается начинать с достаточного простого решения. Это архитектурный ориентир, а не обещание коммерческого эффекта.
Для новых клиентов требуется внешний вход
Установка помощника на собственный сайт часто улучшает обслуживание уже пришедших людей. Но посетители не возникают от того, что в правом углу появился компетентный кружочек. Если компания рассчитывает получить новую аудиторию, в первый процесс нужно включить источник: согласованное размещение у партнёра, доступное сообщество, распространение тематического материала или платный канал с отдельно определёнными расходами.
Запишите не только название площадки, но и человека, который отвечает за появление полезного предложения перед аудиторией. «Будем работать с сообществами» не заменяет договорённость о конкретном разборе. «Сделаем контент» не говорит, кто увидит его на малопосещаемом сайте. Для небольшого пилота достаточно одного внешнего входа, если его действительно можно включить и проверить. Создание сразу десяти каналов обычно затрудняет ответ на вопрос, где именно возникло обращение.
При этом включённый источник и отклик аудитории — два разных события. Партнёр разместил ссылку, путь проверен, результат доступен: маршрут технически существует. Кто-то воспользовался им и принёс задачу: появился наблюдаемый интерес. Человек подтвердил предмет и возможность продолжения: возникло принятое обращение. Тестовый проход команды подтверждает только работу интерфейса. Первый визит по новому cookie ещё не доказывает, что этот человек никогда не был клиентом.
Контракт процесса помещается на один лист
Под контрактом здесь понимается рабочее описание первой задачи, а не юридический документ. Оно связывает маркетинг, разработку и продажи до того, как каждый начнёт улучшать свою часть. Удобно заполнить его вместе с человеком, который будет принимать обращения. Именно он часто замечает неприятную деталь: полезный для интерфейса результат ещё недостаточен для дальнейшей работы компании.
| Поле | Что следует записать |
|---|---|
| Покупатель и ситуация | Кому помогаем и какую трудность разбираем сейчас |
| Источник аудитории | Откуда придёт человек, кто включает этот вход |
| Исходные сведения | Какие данные просим и что можно оставить неизвестным |
| Законченная помощь | Что человек получит даже без передачи контакта |
| Основания | Какие документы, правила и факты разрешено использовать |
| Следующее действие | Что можно сделать после результата и кто это примет |
| Граница самостоятельности | Что выполняется автоматически, что проверяет человек |
| Приёмка | Как проверим качество, передачу и работу исключений |
Одного листа не хватит на всю реализацию, и это нормально. Его задача — сохранить одинаковое понимание предмета. Подробные поля, доступы и технические ограничения появятся в рабочем описании. Но если на первом листе нет владельца внешнего входа или определения пригодного результата, дополнительные схемы не закроют этот пробел. Они лишь красиво распределят неизвестность по нескольким подразделениям.
Материал компании нужно превратить в основания для ответа
У компании может быть много контента и мало пригодных сведений для конкретного процесса. Презентация уверенно обещает удобство, каталог хранит характеристики, менеджер знает исключение, которое действует с прошлого четверга. Агенту нужен не литературный образ бизнеса, а набор проверяемых фактов: какой документ актуален, к какому продукту относится условие и кто вправе подтвердить спорное.
Начните с нескольких типов исходников, необходимых выбранному действию. Для подготовки задания мебельщику это могут быть список нужных размеров, состав предложения и примеры допустимых форматов. Для предварительного выбора товара — действующие характеристики, совместимость и ограничения. Не нужно сначала загружать двадцатилетний архив и надеяться, что модель сама устроит внутреннюю редакцию документов. Она способна убедительно совместить сведения, которые никогда не должны были встретиться.
Рядом с фактом полезно хранить источник, дату проверки, область применения и владельца. Отсутствующее значение остаётся отсутствующим. В рабочем результате оно превращается в вопрос человеку или задачу специалисту. Это не ухудшает интеллектуальность системы. Наоборот, показывает, что она различает подтверждённое и предполагаемое. Для отдельного устройства знаний есть разбор базы знаний для ИИ-агента; здесь важно выбрать только те сведения, без которых первый процесс не состоится.
Разрешения описывают действия, а не характер цифрового сотрудника
Фраза «агент работает самостоятельно» слишком удобна для презентации и слишком неопределённа для эксплуатации. Самостоятельно прочитать документ, подготовить сравнение, изменить карточку и отправить сообщение человеку — разные полномочия. Если объединить их одним переключателем, придётся либо постоянно держать систему за руку, либо узнавать о важном действии уже после его выполнения.
Разложите работу на наблюдение, подготовку и исполнение. Для каждой операции задайте условие. Например, подготовленный список исходных данных можно показать без проверки, если он целиком собран из утверждённого набора и не содержит индивидуального технического заключения. Новое условие применимости передаётся специалисту. Публичный ответ проходит согласование в выбранном формате. Отправка сообщения или запись в другую систему требуют собственного подтверждённого подключения и правил.
У правил должен быть и отрицательный маршрут. Что происходит, когда факт не найден, человек меняет задачу, источник недоступен или сотрудник отклоняет результат? Без этих состояний агент будет пытаться продолжать работу там, где бизнес уже предпочёл бы остановиться. Проектирование такой границы согласуется с общим назначением добровольной рамки NIST AI RMF: учитывать риски при создании и использовании ИИ. Сама ссылка на рамку не означает сертификацию проекта или выполнение всех её положений.
Приёмка начинается с примеров, которые неудобно показывать на демо
Самый приятный тест — принести ясный вопрос, действующий документ и клиента, который охотно следует сценарию. Он подтверждает, что система способна пройти знакомую дорожку. Но для рабочего процесса гораздо важнее случаи, в которых дорожка обрывается. Человек не знает размер. В двух документах разные условия. Запрос относится к другой услуге. Сотрудник уже ответил, но сообщение ещё раз попало в обработку.
До запуска соберите небольшой набор таких ситуаций и рядом запишите ожидаемое поведение. Не нужно придумывать магический универсальный размер выборки. Она должна покрывать существенные состояния именно вашего процесса. Отдельно полезны типовой запрос, неполные сведения, противоречие, повтор, неподходящая ситуация и отказ продолжать. Для каждого случая проверяется не красота текста, а правильное решение: уточнить, остановиться, передать человеку или выдать ограниченный результат.
В руководстве OpenAI по оценке систем проверка связывает цель, примеры и критерии, а изменения предлагают оценивать повторно. Для маркетингового процесса из этого следует практическая рекомендация: сохранить собственные трудные случаи и возвращаться к ним после правки знаний или логики. Это не инструкция использовать конкретный API. Тест текста также не заменяет проверку внешнего источника, формы или передачи обращения.
Время человека входит в стоимость процесса
Цена обращения к модели — только одна строка. Кто-то должен проверить новый материал, разобрать спорный подбор, выяснить причину отказа и обновить правило. Чем меньше компания, тем заметнее эти действия: у неё редко есть отдельный сотрудник, который весь день принимает решения цифровых коллег. Если участие человека нельзя встроить в обычную работу, экономику процесса стоит пересмотреть до расширения.
Покажем условный расчёт, который ничего не говорит о тарифах 404ai. Допустим, на запуск и ведение ограниченного процесса за период потрачено 24 000 рублей, на модели и инфраструктуру — 2 000, на распространение — 4 000. Сотрудник затратил четыре часа, для внутренней оценки компания использует 1 000 рублей за час. Совокупные затраты в этой учебной модели составляют 34 000 рублей. Четыре часа не следует считать бесплатными только потому, что сотрудник уже получает зарплату.
Если команда приняла восемь предметных обращений, арифметическое отношение расходов к их числу равно 4 250 рублей. Это стоимость принятого обращения в заданном учёте, а не стоимость нового покупателя и не доказанная окупаемость. Часть людей могла обратиться прежде, сделки могли не состояться, а источник — участвовать лишь в одном эпизоде выбора. Такая честная дробь полезнее большого числа «обработанных возможностей», смысл которых никто не закрепил.
Считайте ручные исправления как подсказку для развития
Не всякая правка означает, что ИИ не справился. Сотрудник может уточнить новое условие, которого в источниках ещё нет. Но когда одинаковое исправление повторяется, это уже характеристика процесса. Например, система постоянно предлагает получить расчёт людям, которые ещё не выбрали продукт. Или выдаёт слишком общий список материалов, после которого менеджер повторно задаёт те же вопросы. В обоих случаях исчезает смысл автоматизации.
Полезно записывать причину исправления простыми категориями: не хватило данных, неверно применено правило, устарел источник, неподходящий следующий шаг, ошибка передачи. Эти записи нужны для решения, а не для рейтинга модели. Если преобладают пропуски исходных сведений, стоит изменить вход. Если проблема в правилах, уточнить знания. Если человек принимает хороший результат, но продолжать некуда, дорабатывать нужно коммерческий маршрут.
Так появляется разумный план следующей итерации. Система не обязана сама «обучаться на каждом диалоге» в техническом смысле. Сначала достаточно дисциплины: сохранять повторяющийся дефект, проверять основание, вносить согласованную правку и заново проходить трудные примеры. Автоматическое изменение знаний без владельца способно быстро превратить частное исключение в общее правило. Обновление должно быть наблюдаемым действием с понятной причиной.
Запускать стоит через три состояния готовности
Первое состояние — процесс разобран на допустимых примерах. Есть исходники, критерии и пригодный вид результата. Это ещё не работа с новой аудиторией. Второе — включён настоящий вход и проверено продолжение: внешний материал доступен, человек может воспользоваться помощью, сотрудник получает нужный контекст. Третье — началась регулярная работа, в которой команда видит повторения, ошибки, затраты и дальнейшие действия людей.
Такое разделение помогает принимать работу без ложного торжества. Демонстрация может пройти успешно, а партнёр ещё не согласовал размещение. Внешний вход может работать, но за период никто не принёс подходящую задачу. Могут появиться обращения, но часть не соответствует услуге. Это разные факты с разными решениями. Перезапуск модели не заменит разговор о доступной аудитории, а новый канал не исправит неправильную передачу менеджеру.
Что делать, если заказчик просит добавить ещё пять задач
После первого удачного показа часто хочется немедленно присоединить рассылку, конкурентов, публикации и помощника руководителя. Это понятная реакция: компания наконец видит, как технология делает что-то относящееся к её работе. Но дополнительная задача меняет число источников, исключений, ответственных и проверок. Один новый пункт в презентации может оказаться отдельным процессом эксплуатации.
Разрешить расширение помогает короткая проверка зависимости. Новая функция необходима, чтобы закончить уже выбранное действие, или приносит другой результат другой аудитории? Если без неё нельзя принять обращение, она действительно относится к первому процессу. Если она создаёт самостоятельный поток, её лучше вынести в следующий этап. Такой разговор касается состава работ, а не запрета на развитие.
Первые улучшения часто выглядят скромнее новой роли агента. Сократить неоднозначный вопрос. Добавить ссылку на действующий документ. Передавать менеджеру не весь транскрипт, а предмет и неизвестные. Сделать понятный ответ человеку, которому услуга не подходит. Эти изменения редко становятся центральным кадром демонстрации, зато позволяют превратить небольшой процесс в рабочую привычку компании.
Разные компании могут принять один и тот же принцип
Мебельщику важно получить достаточные исходные данные для разговора, интернет-магазину — помочь человеку различить совместимые варианты, консультанту — сформулировать предмет встречи, поставщику — сохранить основания подбора для второго участника закупки. Общая технология может быть похожа, но контракт результата у каждого свой. Универсальная анкета не обязана быть удобной всем четырём.
Поэтому широкий рынок не означает одинаковое содержание. У одной компании действующий вход находится у партнёра, у другой — в тематическом размещении, у третьей — в уже доступном потоке добровольных вопросов. Заказчик выбирает применимый первый процесс и проверяет его на своей ситуации. Если доступной новой аудитории нет, начинать с её проверки честнее, чем продавать регулярную работу системы, которой пока не с кем работать.
Именно такую последовательность описывает Агентский маркетинг 404ai: определить задачу покупателя, внешний вход, полезный результат и способ продолжения, затем настроить и вести выбранную работу. Это описание подхода услуги. Оно не означает готовый поиск во всех сетях, автоматическую отправку от имени клиента или гарантированное число продаж. Подключения и допустимые действия проверяются для конкретного состава.
У первого процесса должно быть право закончиться
Пилот нужен для решения, а не для превращения любой подписки в вечную. Полезно заранее определить основания продолжать, пересобирать и останавливаться. Например, процесс выдаёт пригодные результаты, обращения принимаются командой, трудозатраты понятны — можно обсуждать регулярное ведение. Источник привёл неподходящую аудиторию — стоит менять вход или предложение. Выбранный вопрос почти не встречается — возможно, эту задачу не нужно автоматизировать отдельно.
Условия остановки не должны появляться только после неприятного отчёта. Если компания не готова принимать обращения, нет действующих материалов или существенное действие нельзя выполнить в доступном контуре, дальнейшее масштабирование не устранит эти причины. Результат диагностики может состоять в том, что сначала нужна простая организационная правка. Это менее впечатляюще, чем запуск целого ИИ-отдела, но иногда значительно дешевле для покупателя.
Само отсутствие сделки за короткий период тоже нельзя автоматически назначить провалом. Нужно знать цикл решения, число пригодных ситуаций и дальнейшее движение. У мебельщика и недорогой услуги могут быть разные сроки. Важно не откладывать оценку бесконечно: заранее выбрать дату управленческого разбора и определить, какие наблюдения к ней реально доступны. Для общего принципа работы от задачи к оценке есть подход «Цель → метрика».
Как выглядит передача процесса в регулярную работу
Вместо фразы «агенты подключены» принимающая команда должна получить рабочую карточку процесса, источники знаний, правила действий, доступы ответственных и способ разбирать исключения. Нужен понятный путь для сотрудника, который не присутствовал на запуске: где увидеть основание результата, как отклонить ошибку, кому передать вопрос и когда менялось правило. Отсутствие автора проекта не должно превращать систему в музей удачного демо.
К карточке полезно приложить несколько проверенных примеров и журнал существенных изменений. Не только удачный ответ, но и правильное поведение при нехватке сведений. Не только запись в реестре, но и подтверждение, что сотрудник смог продолжить задачу. Если в процессе используется Цифра, клиентская история и задачи могут стать частью такого учёта; конкретные поля, обмен и права согласуются отдельно, а не возникают от упоминания продукта.
В этот момент первый процесс становится понятным предметом дальнейшего заказа. Можно оценить, какую работу он берёт на себя, какой ресурс требует и какое улучшение имеет смысл следующим. ИИ-команда перестаёт быть списком должностей. У неё появляется занятие, которое покупатель способен описать своими словами, проверить и при необходимости остановить. Для первого внедрения это гораздо более полезная амбиция, чем обещание немедленно заменить весь маркетинг.
Источники и границы разбора
Проверено 3 ноября 2026. Документы платформ подтверждают отдельные механизмы и определения. Предлагаемые маршруты и условные примеры — авторская методика, а не отчёт о внедрении или обещание клиентов.
- Anthropic — Building effective agents
Реально открыто 03.11.2026. Поддерживает различие заданных workflows и выбора действий агентом, рекомендацию достаточной простоты. Материал 2024 года с предупреждением об изменении инструментов; не используется как актуальная инструкция SDK или доказательство продаж 404ai.
- OpenAI — Evaluation best practices
Открыто и проверены разделы о цели, примерах, критериях и повторной оценке. Поддерживает принцип приёмки системы; не обещает коммерческий эффект. Старый Evals API в статье не рекомендуется: отдельная документация уже отмечает завершение его работы.
- NIST — AI Risk Management Framework
Реально открыто 03.11.2026. Описывает добровольное управление рисками при проектировании и использовании ИИ; на странице отмечен пересмотр AI RMF 1.0. Ссылка не является сертификацией, правовым заключением или доказательством соответствия конкретного проекта.