AI-агент как продукт: как SaaS-стартапы строят автономных ассистентов

За последние полтора года формулировка «мы добавили ИИ» в описании SaaS-продукта перестала что-либо значить: чат-окно с подсказками есть почти у всех. Новая волна стартапов делает иначе — строит продукт вокруг агента, который не просто отвечает, а сам выполняет цепочку действий: ходит в API, читает базу, заполняет формы, вызывает другие сервисы. Разберём, из чего такой агент собирается на практике, чем он отличается от обычного бота и во что обходится команде.

Что значит «агент как основной продукт»

Обычный ассистент в SaaS реагирует на запрос и возвращает текст. Агент получает цель и сам решает, какие шаги предпринять, в каком порядке и когда остановиться. Разница не косметическая: если бот ошибётся в ответе, пользователь просто перечитает, а если агент ошибётся в действии — он может отправить письмо не тому клиенту, изменить запись в CRM или запустить платёж.

Поэтому «агент как продукт» — это не одна модель, а система вокруг неё: слой инструментов (tools), к которым у модели есть доступ, слой памяти и контекста, слой проверок и подтверждений и слой мониторинга. Языковая модель здесь — двигатель, но не автомобиль.

Типичная архитектура

• Оркестратор — код, который принимает задачу, вызывает модель, разбирает её ответ на «мысль» и «действие», выполняет действие и возвращает результат обратно в модель. Это цикл, а не один запрос.
• Инструменты — функции с описанием: поиск по базе, вызов API площадки, отправка сообщения. Модель выбирает нужную по описанию и передаёт параметры.
• Память и извлечение — часто на базе RAG*: перед ответом система подтягивает релевантные документы из векторной базы, чтобы агент опирался на данные компании, а не на общие знания модели.
• Гардрейлы — правила и точки подтверждения: какие действия агент делает сам, а какие только предлагает человеку.

*RAG (retrieval-augmented generation) — подход, при котором модель перед генерацией ответа получает подобранные под запрос фрагменты из внешней базы знаний. Это снижает выдумывание фактов и позволяет работать с данными, которых не было в обучении.

Главный риск агента — не в том, что он глуп, а в том, что он действует. Ошибка бота стоит секунды внимания, ошибка агента — реального действия в чужой системе.

Из чего собирают агента сегодня

У команды есть два пути: взять фреймворк и модель через API либо строить оркестрацию самим. Большинство ранних стартапов начинают с чужого API — так дешевле проверить гипотезу.

Наиболее ходовые кирпичи на сегодня:

• модели с поддержкой вызова функций от крупных провайдеров (OpenAI, Anthropic, Google) — они умеют возвращать структурированный запрос на вызов инструмента;
• открытые фреймворки оркестрации вроде LangChain или LlamaIndex для сборки цикла и подключения инструментов;
• векторные хранилища для RAG;
• слой наблюдаемости — трейсинг каждого шага агента, без которого отладку вести почти невозможно.

Конкретные цены на API-токены и подписки провайдеры меняют регулярно — актуальные тарифы смотрите на страницах pricing самих компаний, а не по цифрам полугодовой давности.

Сборка своими руками или готовая платформа

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

Что ломается на практике

Демо агента собирается за выходные, а до продакшена доходят месяцы. Причины повторяются от команды к команде.

1. Стоимость на масштабе. Агент делает не один вызов модели, а цикл из нескольких, и каждый шаг — это токены. Задача, которую бот решал одним запросом, у агента разрастается в пять-десять. На тысячах пользователей счёт за API становится главной статьёй расходов.
2. Латентность. Пока агент «думает» и вызывает инструменты по кругу, пользователь ждёт. Секунды, приемлемые для одного ответа, превращаются в десятки секунд ожидания.
3. Непредсказуемость. На один и тот же запрос агент иногда выбирает разные пути. Для продукта это значит, что тестировать надо не отдельные ответы, а поведение — а инструменты для этого пока сырые.
4. Ответственность за действия. Если агент сам меняет данные, нужны логи, откат и точки подтверждения человеком. Иначе первая же ошибка в чужой системе обернётся разбирательством с клиентом.

Кому это пригодится, а кому нет

Агент оправдан там, где задача состоит из повторяющихся шагов через несколько систем и цена ошибки контролируема.

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

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

Что это значит для рынка SaaS

Продукт-агент меняет и экономику подписки. При обычном SaaS маржинальность растёт с числом клиентов почти бесплатно. У агента каждый активный пользователь тянет за собой переменные расходы на вызовы модели, и тарифная сетка «безлимит за фиксированную цену» становится опасной. Отсюда сдвиг к моделям оплаты по использованию или по числу выполненных агентом задач.

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