AI Sales Agent: evidence-first архитектура AI-агента для CRM

Бизнес-задача: понимать сделку, не превращая гипотезу в факт

Менеджер работает одновременно со статусом сделки в amoCRM, перепиской через Wazzup, задачами, звонками и документами из базы знаний Yonote. Простая схема «отправить чат в GPT и записать ответ в CRM» не отвечает на критичные вопросы: к какой именно сделке относится диалог, какие данные были доступны модели, на чём основан вывод и можно ли выполнять действие.

Поэтому решение построено как production-oriented reasoning pipeline вокруг реальных бизнес-данных. Оно сохраняет происхождение evidence, фиксирует снимок состояния, требует ссылок на доказательства и проводит структурный результат через набор контрактов до того, как он сможет повлиять на процесс.

Evidence-first pipeline

1. Ingestion и нормализация

   amoCRM, Wazzup, транскрипты звонков и Yonote преобразуются в локальные записи с идентификаторами источника, временем и provenance.

   source evidence

2. Entity Resolution

   Структурированные идентификаторы сопоставляют мессенджер, контакт и активную сделку. Неоднозначность сохраняется как отдельный результат.

   resolved · ambiguous · unresolved

3. Immutable Deal Context

   Watermarks источников и нормализованные записи образуют версионированный неизменяемый пакет контекста.

   snapshot · version · provenance

4. Fact Extraction и Resolver

   Модель выделяет факты, сценарий, business goal, prerequisites и ownership, возвращая typed output со ссылками на evidence.

   AI interpretation

5. Контракты и validation

   Детерминированный слой проверяет типы, существование ссылок, допустимость completion, blockers и ownership.

   accept or reject

6. Clarification или action boundary

   Недостающий критичный факт запрашивается у менеджера; внешние действия остаются отдельной, явно ограниченной границей.

   human-in-the-loop

Entity Resolution до начала reasoning

Неизменяемый контекст и воспроизводимость

AI не читает постоянно меняющийся набор API-ответов напрямую. Нормализованное состояние сделки фиксируется с watermarks источников в Context Package. Новый сигнал создаёт новую версию, а прежний AI-result остаётся связан с тем snapshot, на котором был получен.

В аудите сохраняются входной пакет, сырой ответ провайдера, механическая нормализация и канонический валидированный результат. Это позволяет воспроизвести решение и отличить изменение бизнес-данных от изменения интерпретации.

Детерминированный safety layer

• Несуществующая evidence-ссылка → reject. Модель не может сослаться на фрагмент, которого не было во frozen input.
• Неверный тип evidence → reject. Ссылка должна соответствовать ожидаемому типу источника и run-local alias.
• Неподдерживаемый completion → reject. Завершение должно соответствовать контракту текущей цели.
• Недопустимый prerequisite → reject. Деталь, нужная после принятия решения, не становится текущим blocker.
• Некорректный ownership → reject. Ответственность выводится из принятого состояния prerequisites, а не из свободного текста.

Human-in-the-loop без подмены доказательств

Если Resolver обнаруживает неподтверждённый критичный prerequisite, eligibility проверяется кодом, после чего менеджеру задаётся узкий вопрос. Ответ становится отдельным immutable human evidence, формируется новый Context Package и reasoning запускается снова.

Human assertion имеет собственную authority: он может подтвердить сказанное менеджером, но не доказывает несвязанное техническое событие и не закрывает коммерческую цель автоматически. Путь clarification отдельно ограничен, rate-limited, защищён от дублей и аудируется.

Звонки и operational intelligence

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

Модель полномочий

Что реализовано сейчас