Кейс: обзвон должников

Два типа потока

В AGONTS два режима flow, и они работают в паре:

• automation (основной) — без клиента на проводе. Запускается по cron / webhook / вручную. Тянет данные, дёргает интеграции, инициирует звонки.
• conversation (диалог) — то, что слышит / читает клиент. Узлы задают реплики и ветвления.

Основной поток вызывает диалог через узел «Исходящий звонок». Один диалог переиспользуется в десятке основных потоков.

---

Шаг 1. Папка кейса в списке потоков

Все потоки одного кейса лежат в папке. Здесь — папка «Долг обзвон» с тремя потоками: один cron-обзвон + два диалога.

Видны последние 28 запусков по каждому, статус (Активный), число узлов, дата изменения. Слева — дерево папок, справа — действия (Запустить, Тест, История, Аналитика).

---

Шаг 2. Основной поток: «Прозвон должников (cron)»

Это automation-flow. 4 узла, никакого общения с клиентом.

---

Шаг 3. Узел «Исходящий звонок» — настройки

Клик по узлу → справа открывается панель параметров.

• Кому звонить — литерал E.164 (+7123123123) или выражение {{$prev.output.rows.0.customer_phone}} — берёт телефон из результата предыдущего SQL-узла.
• С какого номера — переопределение caller-id; пусто = провайдер по умолчанию.

• Целевой диалог-flow — Разговор с должником. Список фильтруется по mode=conversation.
• SIP-провайдер — mango-vpbx400363293. Меняется в один клик.

---

Шаг 4. Узел «Интеграция» — SQL в продовую БД

Тот же редактор, другая нода.

• Источник — Платформенный сервер (заранее настроенный MCP) или любой URL на лету.
• MCP-сервер — SQL к БД и семантический каталог.
• Инструмент — execute_query_json (read-only).
• Аргументы — обычный SQL: SELECT a.customer_display_name, a.customer_phone, a.legacy_account_number, ROUND(...) AS balance_rub, a.dunning_stage::text AS dunning_stage_raw, ...

Результат уезжает в $prev.output.rows[], и любой следующий узел может к нему обратиться.

---

Шаг 5. Диалог «Разговор с должником» — общий вид

Это conversation-flow. Каждый ответ клиента уходит в ИИ-маршрут по смыслу, который классифицирует фразу и выбирает ветку.

Все семь сценариев из обсуждения уже на холсте:

Любая ветка на плюс-минус строчке текста — добавить ещё одну (например «хамство и оскорбления» → отдельный outcome) — это перетащить новый узел и подписать стрелку.

---

Шаг 6. Узел «ИИ-маршрут по смыслу» — настройки

Главный «мозг» диалога. Без машинного обучения, без грамматик — конфигурируется текстом.

• Что спросить клиента — реплика, которую бот произнесёт перед слушанием: «Удобно ли вам сейчас обсудить вопрос оплаты?»
• Подсказка для ИИ — свободный текст-инструкция: «Классифицируй ответ ровно одной веткой. ГОТОВ — клиент согласился говорить (да, ага, удобно, конечно...). ЗАНЯТ — попросил перезвонить позже (нет, не сейчас, занят, перезвоните...)» и т.д. по каждой ветке.
• Ветки — берутся с холста: подписали стрелку ЗАНЯТ — появилась ветка ЗАНЯТ. Удалили стрелку — ветка пропала.

Если ИИ не уверен — уходит в ветку other. На неё повешен retry или эскалация на оператора (зависит от логики).

---

Шаг 7. Узел «Извлечь данные ИИ» (slot-filler)

Когда от клиента нужно вытащить числа или даты из живой речи — ставите этот узел.

• Что говорим клиенту — «Хорошо, могу оформить обещанный платёж — доступ продлим, оплату внесёте позже. На какую сумму и на сколько дней (до 7 дней)?»
• Поля для извлечения — список из каталога:
  • promise_amount_rub — число, обязательное (сумма обещанного платежа).
  • promise_days — число 1-7, обязательное (срок).
• Сообщение при недостающих полях — фраза, которую бот скажет, если клиент назвал только сумму, но не срок (или наоборот). Бот сам переспросит до 3 раз, потом фолбэк.

Извлечённые значения доступны во всех следующих узлах как {{slot.promise_amount_rub}} и {{slot.promise_days}} — например, в финальной реплике «Зафиксировал: 5000 ₽ через 3 дня. Жду перевода до 8 мая.»

---

Шаг 8. Узел «Передать оператору»

Эскалация на живого человека — отдельный узел с приоритетом.

• Причина переключения — текст, который увидит оператор в карточке сессии: «Клиент утверждает, что уже оплатил. Сверить с биллингом.» + все слоты диалога, плюс предыдущие ответы ({{$prev.…}}).
• Приоритет — Низкий / Обычный / Высокий (попадание в очередь).
• Голос: hold-loop — для звонков. Бот будет повторять reassurance-фразу («Минуту, специалист сверяет вашу оплату с биллингом...»), пока оператор не возьмёт сессию — иначе SIP-линия молчит и клиент сбрасывает.
• Текст ожидания — то, что произносится в цикле.

---

Шаг 9. История запусков и трасса

Каждый прогон — запись в flow_runs. Видно, на какой ноде разговор остановился, что сказал клиент, какой интент сработал.

Клик по запуску → панель с пошаговой трассой:

Видно: бот сказал «...», клиент ответил «...», ИИ классифицировал как other, ушло на оператора. По этой трассе ловятся регрессы и докручиваются формулировки промптов.

---

Что меняется без программистов

Через UI в правой панели редактируется:

• любая реплика бота;
• список интентов и подсказка для классификатора;
• список полей в slot-filler;
• условия в decision-узлах;
• параметры SQL-запроса и MCP-инструмента;
• caller-id / SIP-провайдер;
• расписание cron-триггера;
• приоритет и текст для оператора.

Всё это — без редеплоя. Версии потока сохраняются (v1·draft, v2·draft, ...), можно откатиться одним кликом.

---

Связь с CRM, биллингом, Bitrix24

Платформа подключается к источникам через MCP-серверы:

• SQL — execute_query_json для read и execute_query_write для write (с правами и audit-логом).
• HTTP — любая REST-API через универсальный http_call.
• Bitrix24 — отдельный MCP с готовыми инструментами (crm.lead.add, crm.deal.update, crm.contact.get, ...).
• 1С — через HTTP-сервис 1С или ODBC; ноду можно вешать на Действие в фоне после любого исхода.

В ноде интеграции вы выбираете сервер → инструмент → передаёте аргументы шаблонами {{slot.*}} / {{$prev.*}}. Подключение MCP-сервера делается один раз в Настройки → MCP-серверы (URL + headers + список разрешённых инструментов).

---