Make ставит агенту потолок циклов, чтобы не жечь операции

Многие люди уверены: повесил агента на задачу — и он сам разберётся. Им кажется, что раз модель умеет рассуждать, значит умеет и остановиться.

Точнее, рассуждать он умеет. Останавливаться — только если вы заранее сказали когда.

Агент в Make уже висит на живой задаче: крутит tool-вызовы, сценарий не говорит «готово», а operations тают. Боль не в том, умная ли модель. Боль в том, что никто не поставил выход.

Цикл без выхода жжёт операции

Сравнение: цикл без выхода против потолка циклов в Make

Make AI Agent (New) — это не один ответ в чате. Это agentic loop: perceive → reason → act → observe, пока задача не закрыта. Путь выбирается в runtime, а не зафиксирован при сборке сценария.

Без явного выхода цикл может жечь операции часами. Официальный блог Make разбирает это прямо: агент снова и снова смотрит контекст, думает, вызывает tools, смотрит результат. Полезно — пока есть стоп.

Без guardrails типичные поломки одни и те же:

runaway iteration — нет стопа, крутится бесконечно;
tool cost blowup — каждая итерация копит operations;
hallucinated tool selection — размытые имена и описания tools → неверный вызов;
context overflow — длинный loop портит качество reasoning.

Пример из того же поста Make: uncapped агент на 20 итерациях там, где хватило бы пяти. Не только медленнее. Ещё и дороже по operations.

Потолок калибруют по execution history после первых прогонов. Не «на глаз навсегда».

В сообществе Make уже встречалась боль «убежал helper»: порядка 100 000 operations за около секунды. Алерты 75%/90% месячной квоты — про бюджет аккаунта, не hard stop на одном runaway-прогоне.

Это иллюстрация страха. Не замена потолку цикла.

Два выхода до боевого прогона

Схема трёх стоп-выходов агента Make до боевого прогона

Блог Make для продакшена просит минимум два стоп-условия до первого боевого запуска. Набор из поста простой:

task complete — структурированный финальный выход, когда задача реально закрыта;
max iterations — жёсткий потолок циклов; стартовая рекомендация блога — около 10 для типичных business tasks;
human review — человек на низкой уверенности (модуль Human in the Loop → Create a review request на условном маршруте);
error fallback — Router после агента → алерт (в примере блога — сообщение в Slack).

Одного «сам поймёт, что готов» недостаточно.

Все просто: потолок циклов и человек на сомнении — это и есть крышка над operations.

Что смотреть в UI — и где оговорка

Чеклист UI агента Make: циклы, проверка и таймаут шага

Make AI Agent (New) в open beta с 2 февраля 2026: на всех планах через Make AI Provider; custom AI provider connections — на платных планах. Поведение и pricing могут меняться.

Любопытно расхождение blog ↔ help. Образовательный пост Make говорит про max-iterations cap в настройках агента и про HITL-модуль Create a review request. Справочник help для Run an agent на момент проверки перечисляет другое:

Step timeout — максимум секунд на шаг, потолок 600 с (10 мин); пусто → default 300 с (5 мин);
Maximum conversation history — сколько ответов помнить в conversation;
вкладка Reasoning — инструкции/inputs, скорость, thinking (если reasoning-модель), context usage в токенах;
Metadata → Execution steps + сводка token usage.

Не утверждать UI-лейбл «max iterations», если его нет в актуальном help. Формулировка блога — рекомендация архитектуры. В beta сверяйте живой UI и сценарийные HITL-модули.

Step timeout — это секунды на шаг, не число итераций цикла. И не путать agentic loop с обычным Iterator / Array aggregator в Make. У темы другой объект.

Сборка, tools и Reasoning Panel

На canvas — модуль Make AI Agents (New). System prompt = роль, цель, ограничения. Tools = отдельные сценарии: одно действие на tool, точные имена вроде «Update HubSpot contact».

Перед агентом полезен Text aggregator → JSON: меньше токенов на парсинг.

С апдейта февраля 2026 в Make AI Agents (New) есть Reasoning Panel: видно решения по tool calls по итерациям. Чеклист первых примерно 10 прогонов:

правильный tool и порядок вызовов;
остановился ли агент на ожидаемой итерации;
схема финального бандла ок;
не было запрещённых вызовов.

Рост числа итераций на одном типе задач — сигнал prompt drift или размытых описаний tools. Много действий в одном tool-сценарии усложняет отладку в Reasoning Panel.

Какой смысл звать tool «сделай всё», если потом в панели не понять, где именно свернуло?

Человек в контуре, когда уверенность низкая

HITL в best practices Make — не «магическое поле» агента само по себе. Паттерн другой: tool шлёт черновик человеку (пример help — Gmail Draft → Slack Send a message) и явная инструкция агенту ждать подтверждения.

Отдельный HITL-гайд Make: checkpoint = пауза + данные ревьюеру + ветка approve / reject / escalate. Блоки: Trigger → Router (routine vs exception) → захват решения (webhook / Data store / approvals).

Куда ставить паузу — по шести вопросам: latency, ambiguity, impact radius, rework cost, frequency, learning potential.

Общий индустриальный паттерн тот же: штатный выход (Final Answer) + лимит шагов + детект повторов; при срабатывании — честное «не удалось», лог или человек.

Лимит обязателен не потому что «модель тупая». А потому что без него loop дороже результата.

Практика перед продом

До первого боевого прогона:

зафиксировать структурированный «задача сделана»;
поставить второй выход — потолок циклов (ориентир блога ~10) и/или HITL на низкой уверенности;
сверить Step timeout и Maximum conversation history в Run an agent;
прогнать ~10 тестов с Reasoning Panel и подкрутить потолок по history;
повесить Router / алерт на ошибки после агента.

Типичные ошибки одни и те же. И это бесит заранее:

запуск в прод без второго стоп-условия;
куча действий в одном tool — сложнее отладка;
размытые имена tools → неверный selection;
путать Step timeout с числом итераций из блога;
считать алерты 75%/90% месячной квоты заменой hard stop на одном runaway-прогоне.

Агент в Make полезен ровно пока у него есть выход: потолок циклов и человек на сомнении. Иначе operations горят раньше, чем появится «готово».