Мы не делаем «агентов ради агентов»: как LLM встраивается в задачу, а не в чат

Когда говорят об ИИ в продукте, разговор почти всегда быстро сводится к двум образам.

Первый — это чат-бот: окно, куда человек что-то пишет, а система отвечает.
Второй — это автономный агент: система, которой ставят цель, и дальше она как будто сама «идет и делает».

Оба образа полезны, но между ними есть еще один, гораздо более практичный вариант. Именно на него мы делаем ставку в реальных продуктах.

Суть подхода простая: мы не строим ИИ как отдельного персонажа, которого нужно уговаривать через чат. Мы встраиваем LLM в конкретные точки процесса, где она действительно сильнее классического софта.

То есть не «попроси ИИ сделать маркетинг», а:

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

Во всех остальных местах продолжают работать обычные, детерминированные механизмы: правила, лимиты, API, очереди, валидация, мониторинг, права доступа, ручное утверждение там, где оно нужно.

Именно поэтому такой подход в бизнесе часто дает больше пользы, чем и обычный чат, и «магический агент, который всё сделает сам».

Почему чат — не лучший интерфейс для работы

Чат хорош, когда задача плохо определена: подумать, набросать идеи, быстро что-то уточнить, помочь с текстом или анализом.

Но как только начинается реальная операционная работа, у чата быстро проявляются ограничения.

Во-первых, человек каждый раз заново тащит в диалог контекст. Нужно объяснить, что это за проект, какая ниша, какие ограничения, какие данные можно использовать, в каком формате нужен ответ.
Во-вторых, качество сильно зависит от того, насколько хорошо пользователь умеет формулировать запрос.
В-третьих, сам результат часто остается «разговором», который еще надо превратить в действие руками.

Поэтому чат обычно находится слишком далеко от реального процесса.

Он может подсказать.
Может предложить черновик.
Может что-то объяснить.

Но он редко является хорошей формой исполнения повторяемой рабочей задачи.

Автономный агент звучит мощно, но это не всегда то, что нужно

Противоположная крайность — идея полностью автономного агента. Ему ставят цель, и дальше он сам выбирает шаги, инструменты и решения.

Для исследовательских и открытых задач это может быть полезно. Но в прикладном бизнес-контуре у такого подхода быстро появляются вопросы:

• откуда агент берет право на действие;
• где границы его ответственности;
• как ограничить стоимость ошибки;
• как гарантировать формат результата;
• как объяснить команде, что именно он сделал и почему.

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

Поэтому в большинстве прикладных сценариев полезнее не «агент, который умеет всё», а система, где LLM решает строго определенный фрагмент работы.

Третий путь: LLM как встроенный слой внутри процесса

Вот это и есть наш рабочий подход.

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

Обычно картина выглядит так:

1. Данные и события приходят из реальных источников: CRM, рекламные кабинеты, сайты, базы компаний, аналитика, очереди задач.
2. LLM включается только в тех шагах, где нужно понимать смысл, текст, намерение, контекст или неструктурированное содержание.
3. Детерминированный слой проверяет формат, применяет лимиты, права доступа, правила compliance, вызывает API, пишет в базу, запускает фоновые задачи.
4. Человек подключается там, где нужно утверждение, контроль качества или управленческое решение.

В таком контуре LLM — это не «мозг всего продукта», а очень сильный специализированный модуль.

И в этом, как ни странно, ее настоящая сила.

Пример 1: Sending Machine — не чат для продаж, а машина точечного аутрича (персонализированного B2B-контакта)

Если смотреть со стороны, можно было бы сказать: «Ну это просто AI для писем». Но внутри логика намного интереснее.

В Sending Machine ИИ не сидит в углу интерфейса и не ждет, пока пользователь попросит: «Придумай мне хорошее письмо».
Он встроен в цепочку конкретных шагов.

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

Но дальше происходит самое важное: решающие операционные части делает не LLM.

• проверяется валидность email;
• учитываются лимиты отправки;
• работает прогрев домена;
• автоматически формируется legal footer;
• учитываются отписки и правила compliance;
• рассылка идет через фоновые задачи и контролируемый SMTP-процесс.

То есть LLM здесь отвечает не за «отправить кампанию», а за то, что у нее получается лучше человека и хуже всего у обычных правил: понять, чем живет компания, и адаптировать сообщение под ее контекст.

Это очень важная разница.

Если бы мы делали это через чат, пользователь сам бы:

• копировал куски сайта;
• объяснял, кому пишет;
• просил придумать ice-breaker;
• вручную переносил текст в рассылку;
• отдельно следил бы за лимитами, отписками и репутацией домена.

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

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

Пример 2: Ads Machine — не агент-маркетолог, а система, где ИИ работает по узким ролям

С рекламой похожая история. Многие представляют себе «AI-маркетолога» как универсального помощника: дай ему продукт, и он сам придумает аудиторию, ключи, объявления, бюджеты и стратегию.

Звучит красиво, но в реальной рекламе так работать опасно.

В Ads Machine мы разделяем задачу на слои.

Есть места, где LLM действительно полезна:

• придумать стартовый набор поисковых гипотез по офферу;
• увидеть смысловые формулировки, которые человек может пропустить;
• разбить ключи по интенту: горячие, теплые, информационные, брендовые;
• сгенерировать рекламные тексты под конкретные ограничения Яндекса или Telegram;
• объяснить результаты исследований и собрать выводы в понятную форму.

И есть места, где лучше работают алгоритмы и интеграции:

• проверка частотности через Wordstat;
• сбор подсказок из реального поискового спроса;
• загрузка ключей в группы объявлений;
• контроль бюджетов;
• rule-based биддинг;
• детекция аномалий;
• применение изменений через API рекламных систем.

Это значит, что LLM не получает задачу «управляй рекламой».
Она получает более узкие, но очень полезные задачи:

• понять смысл оффера;
• предложить гипотезы;
• превратить эти гипотезы в структурированный список;
• помочь с текстом там, где действуют символьные ограничения и требования площадки.

Дальше система валидирует результат на реальных данных и реальных интерфейсах.

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

Получается не «маркетинговый агент», а инженерная рекламная машина, где LLM встроена как слой смысловой работы, а не как свободный оператор бюджета.

Чем это отличается от чат-бота на практике

Разница здесь не философская, а очень прикладная.

У чат-бота обычно так:

• пользователь сам приносит контекст;
• пользователь сам формулирует задачу;
• пользователь сам решает, что делать с ответом;
• качество зависит от навыка переписки с моделью.

У встроенного LLM-слоя иначе:

• контекст приходит автоматически из системы;
• задача уже заранее определена продуктом;
• формат ответа заранее ограничен;
• результат сразу попадает в следующий шаг процесса.

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

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

Он просто пользуется инструментом.

Почему это часто лучше и для бизнеса, и для обычной жизни команды

У такого подхода есть несколько практических плюсов.

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

Второе — ниже цена ошибки.
Если модель неидеально сгруппировала ключи или предложила слабый вариант вступления, это локальная ошибка. Она не равна ситуации, где «автономный агент» самовольно что-то поменял в бюджете, отправил не туда письмо или выполнил неверную последовательность действий.

Третье — проще измерять эффект.
Можно отдельно считать:

• лучше ли стали open rate и reply rate;
• быстрее ли собирается семантика;
• выросло ли качество рекламных гипотез;
• сколько ручной рутины ушло у команды.

У чата эти эффекты обычно размыты.
У встроенного процесса они привязаны к конкретной операции.

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

Когда чат все-таки нужен

Важно не впадать и в другую крайность: чат сам по себе не бесполезен.

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

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

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

И вот в этот момент ИИ перестает быть игрушкой и становится частью операционного контура.

Что это меняет в мышлении о продукте

Если смотреть на ИИ именно так, вопрос меняется.

Не «куда бы нам прикрутить чат».
И не «как бы сделать автономного агента, который всех заменит».

А вот так:

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

Это гораздо менее эффектно выглядит в заголовке.

Но именно так обычно и появляется реальная ценность.

Не как «волшебный агент».
А как набор очень точно встроенных интеллектуальных функций, которые снимают лишнюю работу, улучшают качество решения и не требуют каждый день заново договариваться с машиной через чат.

Вывод

Самая полезная форма ИИ в продукте — не обязательно чат-бот и не обязательно автономный агент.

Очень часто это встроенный LLM-слой внутри конкретной задачи:

• в рассылке — чтобы понять компанию и персонализировать сообщение;
• в рекламе — чтобы работать со смыслами, гипотезами, семантикой и креативом;
• в аналитике — чтобы превращать сырые данные в понятные выводы;
• в любом операционном процессе — чтобы усиливать именно тот участок, где язык и смысл важнее жесткой логики.

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

Потому что в работе людям обычно нужен не «ИИ, с которым можно поговорить».
Им нужен инструмент, который надежно делает полезную часть работы внутри уже существующего процесса.