Жив ли n8n, когда есть ИИ-агенты: где без него не обойтись

n8n жив, и мы продолжаем на нём строить. ИИ-агент и n8n делают разную работу. Агент понимает текст и принимает решения. n8n каждый раз одинаково выполняет одни и те же шаги и связывает сервисы между собой. Без n8n не обойтись в трёх случаях: задача повторяется каждый день по одной схеме; в интеграции между сервисами нужен шаг с решением агента; агенту нужно своё MCP-подключение.

Почему вопрос «жив ли n8n» звучит каждую неделю

Агенты научились делать то, ради чего раньше собирали сценарии автоматизации. 26 октября OpenAI выпустила GPT-6.1 Terra, модель для работы за компьютером: она сама заполняет формы и берёт на себя рутинные действия в программах. Миллион входящих токенов стоит $1, исходящих $5. Это вдвое дешевле прошлой версии Terra. Кажется, что агенту можно отдать всё, а конструктор процессов больше не нужен.

В сообществах автоматизаторов этот вопрос задают так часто, что участники уже раздражаются. Ответ, который там часто звучит, совпадает с нашим опытом. Агенты плохо справляются со скучной точной частью: повторить запрос, принять вебхук (входящее уведомление от сервиса), запускать задачу каждые 15 минут и записывать результат. Здесь и нужен n8n.

Одинаковые задачи каждый день: флоу

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

Примеры таких задач:

• каждые 15 минут забирать новые заказы с маркетплейса и заводить их в 1С;
• переносить заявку с сайта в amoCRM или Битрикс24 и ставить задачу менеджеру;
• утром отправлять клиентам напоминания о записи.

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

Сбои тоже часть процесса

Флоу тоже ломается: сервис не ответил, заявка пришла дважды, связь оборвалась на середине. Надёжность автоматизации в том, чтобы такие ошибки были видны и обработаны. В настройках узла n8n есть Retry On Fail: при ошибке узел повторяет запуск. Настройка On Error решает, остановить процесс, продолжить или отправить ошибку по отдельной ветке. Можно назначить отдельный флоу-обработчик для нескольких процессов: он запустится при сбое любого из них и, например, напишет ответственному.

Интеграции, где в середине нужно решение

Частая задача интеграции: связать два-три сервиса так, чтобы в середине кто-то понял текст и выбрал, что делать дальше. Флоу везёт данные, агент или модель решений принимает решение на развилке, потом флоу снова выполняет точные действия.

Например, заявка приходит с сайта. Флоу передаёт текст модели, модель определяет тип обращения и срочность. Дальше флоу сам ставит сделку в CRM, назначает менеджера и отправляет клиенту письмо. Модель здесь отвечает только на один вопрос, а запись в CRM и письмо остаются под контролем флоу. Так меньше шансов, что модель создаст дубль контакта или отправит письмо дважды.

Для развилок появились отдельные модели решений. Jev от TypeSafe AI выбирает ответ из заданных вариантов и называет вероятность. Мы разбирали его в статье что даёт автоматизации модель решений. Такую модель тоже можно вызывать из флоу: уверенный ответ процесс выполняет сам, неуверенный отдаёт менеджеру. Из таких связок мы и собираем решения для автоматизации бизнеса.

Флоу n8n с развилкой: заявка с сайта, модель определяет тип и срочность, при высокой вероятности сделка в CRM, при низкой задача менеджеру