CRM для продаж с ИИ-агентами на LangGraph

Задача

• Клиенты писали в несколько мессенджеров, менеджеры отвечали с личных и общих аккаунтов — единой истории общения с клиентом не было.
• Первые минуты каждого лида уходили на одни и те же уточняющие вопросы.
• Было не видно, какие чаты ждут ответа команды, а какие — клиента; на дорогие заявки отвечали так же долго, как на случайные.
• Работа с партнёрами, рассылки и объявления велись вручную — в телефонах и таблицах.
• Система должна была продолжать работать, когда не отвечает API мессенджера, LLM или внешний источник данных.

Решение

Мы построили CRM из двух рабочих пространств на общей платформе. В пространстве продаж сообщения из всех каналов проходят через один конвейер и становятся лидами: карточка на канбане, менеджер по графику смен, форма требований, события в календаре, задачи и чат в реальном времени. За каждой колонкой воронки закреплён свой агент на LangGraph: он уточняет требования, подтверждает заказ или подбирает партнёров, а затем переносит карточку в следующую колонку. Для каждого чата выбирается режим ИИ — «off», «suggest» или «auto», — а менеджеры обучают агентов правилами на обычном языке. Пространство партнёрской сети держит в той же системе исполнение заказов: реестр контактов, канбан-доски, карточки партнёров и рассылки по расписанию. Долгие процессы выполняет Temporal: обогащение и скоринг лидов, обработку медиа, синхронизацию истории, рассылки и диспетчер зависших чатов.

Что умеет система

Свой ИИ-агент на каждом этапе воронки

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

Решения остаются за менеджером

У каждого чата три режима ИИ: «off», «suggest» (агент готовит черновик, менеджер одобряет или правит) и «auto». Автоматический режим отключается, как только в чат пишет человек, а в сомнительных случаях агент задаёт вопрос менеджеру. Менеджеры пишут правила для агентов обычным языком — для направления, этапа, сегмента клиентов или отдельного чата, — и правила действуют со следующего хода.

Журнал каждого запуска ИИ

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

Омниканальный inbox

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

Надёжные процессы на Temporal

Больше 20 workflow в Temporal: обогащение лида из внешних источников, оценка по двум осям с переводом в уровень и целевое время ответа, рассылки, где каждый запланированный запуск отправляется ровно один раз, и задача раз в пять минут, в которой LLM решает, действительно ли зависшему чату нужен человек.

Партнёрская сеть и разграничение доступа

Второе пространство — для партнёров, которые исполняют заказы: контакты с несколькими ролями, две канбан-доски, карточки с вложениями и автозаполнением из переписки с помощью ИИ, каталог с поиском для менеджеров продаж. Вход — через Keycloak, четыре роли проверяются на каждом маршруте, WebSocket-соединении и диалоге.

Инженерные решения

• У ИИ-воркера нет подключения к базе. Он читает и пишет только через MCP-инструменты с теми же проверками ролей, что и HTTP API, а backend на каждом вызове отклоняет пишущие инструменты, не относящиеся к текущему этапу. Если ИИ-воркер импортирует клиент базы данных, сборка падает на статической проверке.
• Живой трафик, сообщения с других устройств и подгрузка истории идут по одному пути приёма. Сообщения показываются в порядке отправки, а непрочитанные считаются отдельным счётчиком — поэтому восстановленное старое сообщение не нарушает порядок и не теряется среди прочитанных.
• Расходы на LLM под контролем: платные вызовы не повторяются вслепую, сводки не пересчитываются, если входные данные не изменились, а диспетчер внимания останавливается, когда исчерпан дневной бюджет.
• Инварианты обеспечивает сама база: один пост на адресата в кампании, одна отправка на запланированный запуск, один перевод на сообщение и язык. Упавший источник данных не блокирует ни скоринг, ни назначение менеджера, ни ИИ.
• Четыре backend-образа из одной кодовой базы на Python, fanout в RabbitMQ для обновлений в реальном времени на всех экземплярах API, больше 100 миграций Alembic, больше 400 тестовых модулей и end-to-end-тесты на Playwright.

Стек

• Python 3.12
• FastAPI
• SQLAlchemy 2
• PostgreSQL
• LangGraph
• MCP
• Temporal
• RabbitMQ
• Keycloak
• S3
• React 19
• TypeScript
• Playwright
• Docker

Что это показывает

• CRM для бизнеса, который продаёт через чаты: омниканальный inbox, настраиваемая воронка, распределение лидов, календарь и задачи.
• ИИ-агенты в продакшене, ограниченные состоянием сделки и работающие под контролем людей, — с журналом, контролем расходов и правилами от менеджеров.
• Долгие бизнес-процессы с безопасными повторами на Temporal и событийный backend на RabbitMQ, WebSocket и SSE.
• Спрос и предложение на одной платформе: клиенты — в пространстве продаж, партнёры и исполнение — в партнёрском.

Вопросы по кейсу