Gumloop: автоматизация задач с ИИ без кода

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

Один результат агента и допустимые входы

Начните с формулировки результата. В документации Gumloop агент описан как помощник, который решает открытые задачи и сам выбирает инструменты, подстраивая подход под задачу. Одна единица работы называется task, и у каждой задачи своя история, свои файлы и своя стоимость в кредитах. Это задаёт рамку: вы описываете не «умного помощника вообще», а конкретную задачу с началом и концом.

Возьмём учебный пример: ручная очередь поддержки. Это ручной учебный пример; запуск Gumloop не проводился. В очереди три обращения:

• A: «Не могу войти в заказ105, ошибка пароля» — категория access, order_id 105, действие — подготовить инструкцию.
• B: «Верните оплату» — категория refund, order_id неизвестен, действие — Ask Question; возврат не выполнять.
• C: «Спасибо, всё работает» — категория resolved, запись нового тикета не требуется.

Результат агента формулируется так: по каждому обращению выдать ID, category, order_id, draft_reply, next_step. Допустимые входы — текст обращения и справочная база знаний. Всё, что за пределами этих входов, агент запрашивает отдельно.

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

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

Инструкции, подключения и узкий триггер

Документация Gumloop предлагает три шага настройки агента. Сначала добавьте коннекторы в разделе Connectors — те интеграции, которые агенту нужны. Затем дайте реальную задачу и прогоните её от начала до конца, наблюдая, где агент угадывает или пропускает шаг. После этого попросите агента написать собственные инструкции и навыки: формулировки вроде «обнови свои инструкции, чтобы всегда делать так» или «преврати это в навык».

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

Инструкция для нашего примера выглядит так:

Обрабатывай обращения A, B и C независимо. Категории: access — проблема входа; refund — запрос возврата; resolved — клиент сообщил, что проблема решена; other — остальное. Для каждого обращения выведи ID, category, order_id, draft_reply, next_step. Извлекай order_id только из текущего обращения; если номера нет, ставь null. Не переноси данные и выводы между A, B и C. Готовь только черновики. Не отправляй сообщения, не делай возврат, не меняй статус и не удаляй записи. Для refund без order_id используй Ask Question, запроси номер заказа и жди ответа. Для access подготовь черновик помощи со входом, не запрашивая пароль. Для resolved не создавай новый тикет. Не называй черновик выполненной операцией. Любое внешнее действие выполняй только после отдельного разрешения через предусмотренный tool approval; Ask Question таким разрешением не считается.

Триггер делайте узким. Документация Gumloop перечисляет пять способов добавить триггер: app trigger срабатывает на событие в другом приложении, webhook — на HTTP-запрос, scheduled trigger идёт по расписанию, one-time trigger срабатывает один раз, а Create With AI собирает триггер по описанию. Для очереди поддержки в этом примере выберите app trigger на новое обращение.

Промпт триггера — это сообщение, которое агент получает при срабатывании. Документация приводит примеры удачных и неудачных формулировок: конкретное описание нужной сводки по тикетам помогает задать вход и результат; расплывчатое указание «сделай обычное» этих условий не задаёт. Если у агента есть подходящий навык, сошлитесь на него в промпте: агент загрузит навык и пойдёт по его инструкциям.

Часть интеграций работает в реальном времени, часть опрашивает сервис примерно раз в 60 секунд. Документация относит к опросу Gmail, Outlook, Google Sheets, Notion, Airtable, Google Calendar, HubSpot, Salesforce, Linear и Jira, а к реальному времени — Slack, Teams, Google Drive, Zendesk, Google Forms, Typeform, Monday.com и Parallel Web Monitor. Для очереди поддержки это определяет задержку между появлением обращения и реакцией агента.

Риск каждого connector и смена Always allow

Самое практичное место в Gumloop — настройки одобрения коннектора. Документация проекта называет режим Always allow значением по умолчанию: агент использует все инструменты приложения, не спрашивая. Для чтения это удобно, для записи — рискованно.

Режимы одобрения в документации описаны так:

Документация называет Ask for writes/deletes хорошим значением по умолчанию для большинства приложений: агент свободно собирает информацию, а изменения остаются под вашим контролем. Инструменты коннектора при добавлении сортируются на read-only и write/delete, поэтому этот режим работает одинаково и для Gmail, и для self-hosted коннектора. Если группировка инструмента кажется неверной, режим Custom позволяет задать правило для одного инструмента.

Отдельно от режимов работают App Rules. Это условные правила на CEL-выражениях, которые смотрят на фактические аргументы вызова. Документация приводит пример: требовать одобрение только тогда, когда получатель письма находится за пределами домена компании. Правило можно создать двумя путями — попросить агента сформулировать его на естественном языке или собрать вручную в интерфейсе конфигурации приложения. Для создания правил через чат нужна включённая способность App Rules Creation.

Практический порядок для нашего примера: пройдите по каждому подключению и явно смените Always allow там, где он не подходит. Чтение тикета оставьте разрешённым, создание черновика — тоже. Изменение статуса и отправку клиенту переведите в ask for writes. Удаление закройте через never allow. Такой проход занимает минуты и снимает основной класс ошибок.

Read, draft, write, send, delete и матрица разрешений

Разложите действия по пяти категориям. Чтение не меняет внешнюю систему. Черновик создаёт объект внутри вашего инструмента и не уходит наружу. Запись меняет состояние: статус, поле, запись в CRM. Отправка доставляет сообщение человеку. Удаление необратимо.

Матрица для очереди поддержки:

Документация Gumloop описывает, как работает одобрение: агент останавливается и показывает карточку с инструментом и читаемым описанием предлагаемого действия. Уведомление приходит в приложение, в личку Slack или прямо в ветку чата. При одобрении агент продолжает с того места, где остановился; при отклонении он принимает отказ и меняет подход. Документация подчёркивает: агент не выполняет закрытый одобрением вызов инструмента без вашего явного согласия.

Отдельно проверьте, что попадает в категорию «отправка». В документации Gumloop есть пример, где агент готовит письмо и показывает карточку одобрения с полями To, Subject, Body. Это ровно тот случай, когда черновик уже существует, а отправка ещё не произошла. Разница между этими состояниями и есть предмет вашей проверки.

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

Запрос данных отдельно от подтверждения записи

Способность Ask Question в Gumloop устроена иначе, чем настройки одобрения. Документация прямо разделяет эти механизмы: Ask Question не закрывает вызов инструмента, а позволяет агенту задать вам вопрос, когда для продолжения не хватает ввода. Агент показывает структурированные карточки выбора — группы переключателей, множественный выбор — и в каждой карточке есть вариант «Other» с текстовым полем.

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

Подскажите номер заказа, по которому вы хотите запросить возврат. Возврат пока не выполнен.

Обратите внимание на вторую фразу. Она фиксирует фактическое состояние: возврат не выполнен. Это защищает от ситуации, когда клиент читает ответ агента как подтверждение операции.

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

Проверьте сценарий целиком. Обращение B приходит, агент извлекает категорию refund, видит отсутствие номера, задаёт вопрос и ждёт. Возврат не выполняется. Когда номер приходит, агент готовит черновик и показывает карточку одобрения на отправку. Только после вашего согласия сообщение уходит. Такой порядок даёт предсказуемый результат на каждом шаге.

Проверка approval card: получатель, ресурс, контекст

Карточка одобрения в Gumloop показывает имя инструмента и иконку, намерение агента и ключевые аргументы. Документация отмечает важную деталь: карточка показывает читаемые имена ресурсов и ключевые детали; полный перечень аргументов может быть недоступен. Часть деталей может быть недоступна или скрыта вашими правами. Поэтому документация советует смотреть на контекст задачи вместе с карточкой.

Зелёный статус означает, что агент дошёл до шага одобрения. Он не означает, что получатель, ресурс и содержание верны. Проверяйте три вещи по отдельности.

Получатель. В карточке отправки письма есть поле To. Сверьте адрес с тем, кому вы действительно собирались писать. Ошибка в одной букве домена уводит письмо наружу.

Ресурс. Для записи в CRM или смены статуса проверьте, к какой именно записи применяется действие. В нашем примере это тикет с конкретным номером. Если в карточке номер не тот, одобрять нельзя.

Контекст. Посмотрите на задачу, из которой пришёл запрос. Документация Gumloop описывает очередь одобрений на странице Tasks с фильтром Approval Required, где собраны все ожидающие решения по вашим агентам. Это удобно, когда агентов несколько, и опасно, когда вы одобряете по одному заголовку без открытия задачи.

В карточке есть чекбокс «Don’t ask again for this tool». Документация поясняет: отметка запоминает ваше решение для этого инструмента на этом агенте, и будущие вызовы используют эту настройку с учётом прав и политик. Для коннекторных инструментов изменить её можно в настройках Tool Management. Включайте этот чекбокс осознанно: он снимает будущие проверки для конкретного инструмента.

Отдельный случай — агент, который меняет собственную конфигурацию. Документация Gumloop описывает, что при включённом Edit Own Instructions агент может попросить изменить модель, коннекторы, навыки, источники знаний, подагентов, способности и настройки, а также создавать расписания и вебхуки. Каждое изменение требует вашего одобрения, и карточка в этом случае не предлагает опцию «Don’t ask again for this tool» независимо от настроек одобрения агента.

Отказ и неполный вход на ручном эталоне

Ручной эталон — это заранее известный правильный ответ, с которым вы сравниваете поведение агента. Для нашего примера эталон задан тремя обращениями и ожидаемыми результатами. Прогоняйте агента по нему после каждого изменения инструкций или разрешений.

Что проверять на отказе. Документация Gumloop описывает поведение при отклонении: агент получает отказ и необязательную причину, не выполняет инструмент, продолжает разговор и часто предлагает другой подход или просит уточнений. Отклонения не разрушают состояние. Проверьте, что после вашего отказа внешняя система осталась без этой записи. Это и есть критерий приёмки.

Что проверять на неполном входе. Обращение B без номера заказа — штатный случай. Агент должен извлечь категорию refund, поставить order_id в null, задать вопрос через Ask Question и не выполнять возврат. Если агент подставил номер из обращения A, это ошибка смешения записей.

Отрицательные пробы для эталона:

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

Ведите журнал прогонов. Для обращения B он выглядит так: извлечено refund; номер отсутствует; сообщение подготовлено; разрешение на запись не получено; фактический возврат не выполнялся. Такой журнал показывает, на каком шаге вы находитесь, и не даёт спутать подготовку с выполнением.

Run history и фактическое состояние системы

Перед повторной попыткой прочитайте историю запуска. Документация Gumloop описывает Trigger Details как экран с тремя частями: заголовок со статусом On или Off, последние три запуска со статусом, временем и кредитами, и настройки триггера. Кнопка View all открывает Task history со всеми запусками и фильтрами All, Completed, Approval Required и Failed.

Порядок чтения: сначала статус запуска, затем время, затем кредиты, затем фильтр. Если запуск помечен как Approval Required, действие ждёт вашего решения. Если Failed, смотрите причину. Документация Gumloop отмечает, что все триггеры автоматически отключаются после трёх подряд неудачных запусков, а типичные причины — истёкшие учётные данные, удалённые ресурсы и изменения прав. Владелец триггера получает уведомление по почте, в личку Slack и в приложении со ссылкой на последний неудачный запуск. Повторное включение сбрасывает счётчик неудач.

Сверьте состояние системы. История показывает, что сделал агент. Внешняя система показывает, что реально произошло. Расхождение между этими двумя картинами — главный сигнал проблемы. В нашем примере после отказа в одобрении в истории будет запись о подготовленном черновике, а в системе возврата не будет.

Отдельно про стоимость. Документация Gumloop перечисляет, за что начисляются кредиты: использование моделей, вызовы инструментов, время вычислений и оркестрационная надбавка сверху. Итог по задаче виден рядом с её именем в заголовке, а подробная разбивка открывается в панели деталей с отдельными строками по типам. Триггерные запуски расходуют кредиты так же, как чат, а кастомные AI-триггеры тратят кредиты ещё и на опрос.

Честный журнал стоимости до живого запуска выглядит так:

run_id=unknown
timestamp=unknown
agent/model=unknown
число tool calls=unknown
credits до=unknown
credits после=unknown
фактически списано credits=unknown
внешние API charges=unknown
источник показаний=unknown

Порядок проверки: сохраните время и run_id, снимите показания из run history до и после изолированного запуска, отдельно учтите внешние API и повторные попытки. Если сервис не показывает показатель, оставьте unknown и не вычисляйте его по длительности ответа. Заполненный здесь журнал отражает отсутствие запуска, и численная стоимость не измерена.

Частые вопросы

Что такое Gumloop простыми словами?
Это платформа для сборки ИИ-агентов, которые работают с вашими сервисами. Документация проекта описывает агента как помощника, который решает открытые задачи и сам выбирает инструменты. Вы задаёте цель, подключаете нужные интеграции и пишете инструкции.

Как работает human in the loop в Gumloop?
Агент останавливается перед вызовом инструмента, который требует одобрения, и показывает карточку с описанием действия. Уведомление приходит в приложение, в Slack или в ветку чата. При одобрении агент продолжает с того места, где остановился, при отклонении меняет подход. Без вашего явного согласия закрытый вызов не выполняется.

Чем Ask Question отличается от одобрения инструмента?
Ask Question собирает недостающие данные и показывает карточки выбора с вариантом «Other». Одобрение инструмента разрешает внешнее действие. Документация Gumloop разделяет эти механизмы, поэтому в инструкции агенту стоит указать, что ответ на вопрос не открывает путь к записи.

Какой режим одобрения выбрать для коннектора?
Документация называет Always allow значением по умолчанию и советует Ask for writes/deletes для большинства приложений. Чтение идёт свободно, запись и удаление ждут одобрения. Для отдельных инструментов режим Custom задаёт правило точечно.

Что делать, если триггер отключился?
Все триггеры автоматически деактивируются после трёх подряд неудачных запусков. Владелец получает уведомление со ссылкой на последний неудачный запуск. Устраните причину — истёкшие учётные данные, удалённый ресурс, изменение прав — и включите триггер заново. Повторное включение сбрасывает счётчик неудач.