ИИ-агент против автоматизации: когда что реально работает

Неправильный вопрос

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

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

Процессы, где оператор должен думать (этот тикет срочный? выглядит ли эта сделка здоровой? какой правильный ответ на это письмо?), это агентные процессы. Тот, кто предлагает вам Zapier для них, делает неправильное по-новому; детерминизм не выдержит реальной вариативности.

Конкретный пример

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

Шаги 1, 2, 3 и 4, детерминированные. Суждение не нужно, если домен email контакта совпадает с существующим аккаунтом, он идёт к этому менеджеру; если нет, round-robin назначает. Zapier делает это надёжно за условные копейки в месяц.

Шаг 5, составление первого касания. Это работа суждения. Правильное письмо зависит от того, кто такой этот лид, что он скачал, что происходит в его компании, какие у нас были прошлые взаимодействия. Шаблон Zapier даст общее письмо, которое конвертируется хуже тишины. Агент читает обогащённые данные, извлекает нужный контекст и составляет текст в голосе вашей команды под конкретного потенциального клиента. Вот где агент зарабатывает своё место.

Производственная версия процесса использует оба инструмента: Zapier для шагов 1–4, Workspace Agent для шага 5. Не одно или другое.

Когда ИИ-агенты явно выигрывают

• Процессы, требующие синтеза из 3+ неструктурированных источников данных (чтение документов, писем, тикетов, заметок), агенты в этом сильны; детерминированная автоматизация не справится.
• Классификация с нетривиальными правилами, «этот клиент рискует уйти» или «этот тикет поддержки требует эскалации», критерии достаточно размытые, что правила пропустят граничные случаи, которые LLM поймает.
• Задачи составления, письма, резюме, отчёты, предложения, всё, что требует производства текста, который прочитает человек. Автоматизация заполняет шаблоны; агенты пишут.
• Многошаговые рассуждения, где план зависит от предыдущих шагов, «если аккаунт выглядит рискованным по данным Q1, подтяни сигналы Q2; если они совпадают, составь переговорный трек по продлению», агенты обрабатывают это нативно; автоматизация требует хрупких условных цепочек.
• Процессы с высокой вариативностью входных данных, например, каждый RFP имеет разную структуру, но требует той же библиотеки ответов, агенты адаптируются; автоматизация требует нового шаблона под каждую форму RFP.

Когда традиционная автоматизация явно выигрывает

• Высокообъёмные детерминированные процессы, перемещение данных, запуск уведомлений, синхронизация систем. Zapier, работающий 10 000 раз/день, обычно дешевле агента с 10 000 вызовов и надёжнее при таком объёме.
• Процессы со стабильными, хорошо описанными правилами, маршрутизация заявок, подтверждения записей, напоминания об истечении подписок. Здесь не нужен LLM; нужен аптайм.
• Процессы, где предсказуемость важнее гибкости, комплаенс-процессы, финансовые расчёты, всё, где выдача должна быть идентична при одинаковых входных данных. LLM вносят вариативность; автоматизация детерминирована по природе.
• Интеграции между инструментами для передачи структурированных данных (из CRM в ESP, события в хранилище данных и т.д.): платформы автоматизации созданы именно для этого и имеют лучшее покрытие коннекторов.
• Процессы, где задержка важна на уровне долей секунды, API-to-API обмены, где клиент ожидает. Агентам нужно несколько секунд на рассуждение; автоматизация, миллисекунды.

Гибридный паттерн, к которому приходит большинство команд

После нескольких сборок агентов для команд паттерн устойчивый: автоматизация ведёт «сантехнику», агенты ведут рассуждения. На практике это выглядит как процесс в Zapier или Make, который вызывает Workspace Agent на одном конкретном шаге, обычно шаге составления или классификации, и выдача агента возвращается в остальную цепочку автоматизации.

Это дешевле, чем строить всё на агенте (не хочется тратить кредиты на перемещение полей между инструментами, с которыми Zapier справляется нативно). Это мощнее, чем строить всё на автоматизации (шаг суждения был бы слабее). Это также устойчивее: если у агента неудачный день, автоматизация всё равно работает и происходит корректная деградация.

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

Как понять, какой инструмент нужен процессу

Тест из 3 вопросов, когда клиенты принимают решение:

1. 01

   Каждый экземпляр этого процесса имеет одинаковую форму?

   Если да (одинаковые поля, структура, пространство результатов), автоматизация. Если нет (вариативность во входных данных или результатах), вероятно, территория агента.

2. 02

   Процесс производит язык, который читает человек?

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

3. 03

   Если бы тот же сотрудник делал это вручную, он бы «думал» или «двигал поля»?

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

Чего не нужно делать

• Не выбирайте агента только потому что он новее, потратите деньги на проблемы, которые Zapier решал бы за долю стоимости.
• Не выбирайте автоматизацию только потому что она привычнее, построите хрупкую условную логику, которая должна была быть агентными рассуждениями, и она будет ломаться на каждом граничном случае.
• Не пытайтесь строить единого агента, который делает «всё», агенты наиболее надёжны при чётком ограничении области. «Писать письма новым лидам», хорошая область; «обрабатывать все входящие», нет.
• Не пропускайте слой автоматизации в надежде, что агент справится со всем, агент дорог при высоком объёме; «сантехника» должна оставаться в автоматизации.
• Не называйте Zap «ИИ-агентом». Это всё чаще встречается в маркетинговых материалах и создаёт ложные ожидания. Zap. Это Zap.

Итог

ИИ-агенты и традиционная автоматизация, разные инструменты, решающие перекрывающиеся, но различные категории задач. Решение не в том, «что лучше», а в том, «где в этом процессе живёт суждение». Поместите шаги суждения в агента. Поместите механические шаги в автоматизацию. Пусть они вызывают друг друга.

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