Агент начинается не с чата, а с права выбрать следующий шаг
Обычная автоматизация следует заданным условиям. Агент получает цель и сведения о задаче, затем сам выбирает следующий шаг. В продажах это полезно, когда клиент пишет свободным текстом, меняет вводные, возвращается к старой сделке или задаёт вопрос, для которого нужно сначала собрать недостающие данные
Вместе с этой свободой появляется риск: агент может вызвать не тот инструмент, записать неверный факт или продолжить диалог, который пора передать менеджеру. Поэтому при проектировании нужно проверить не только качество общения, но и то, какие действия система способна выполнить в CRM и за её пределами
Четыре слоя агента продаж
Это рабочая схема проектирования для статьи, а не стандартная четырёхслойная модель ИИ-агента.
Состояние
Состояние - это сведения о текущей задаче: исходное обращение, идентификатор клиента, продукт, стадия, заданные вопросы, ответы и ограничения. Храните их компактно и однозначно. Чтение всего архива переписки при каждом шаге увеличивает расходы на контекст и затрудняет выяснение, на какие факты опиралась система
Инструменты
Инструменты - функции для конкретных операций: найти клиента, прочитать карточку, получить каталог продуктов, создать черновик задачи, записать поле или поставить напоминание. У каждой функции должны быть узкое назначение и понятный результат. У функции «сделай всё с клиентом» трудно проверить и границы, и последствия
Права
Инструмент может существовать, но агент не обязан иметь право использовать его во всех режимах. Чтение карточки и изменение коммерческого условия - разные уровни риска
Проверка
Проверка должна включать реальные задачи с заданным результатом, а не только удачные демонстрации. Anthropic рекомендует повторять прогоны и проверять фактическое состояние систем после выполнения: важно, что агент сделал, а не что написал в финальном ответе 1
Лестница прав: от чтения до коммерческого действия
| Уровень | Что разрешено | Что проверять для этого права |
|---|---|---|
| 0. Наблюдение | читать вход и данные, ничего не менять | корректно ли понимается задача |
| 1. Подсказка | предложить классификацию, ответ, следующий шаг | качество рекомендации на истории |
| 2. Ограниченная запись | заполнить некритичные поля, создать внутреннюю заметку | точность, последствия и возможность исправления |
| 3. Организационное действие | создать задачу, назначить повторный контакт | ошибочные назначения и защита от повторов |
| 4. Внешняя коммуникация | отправить сообщения из разрешённых классов | тон, факты, правила эскалации |
| 5. Изменение состояния сделки | менять стадию по формальным условиям | выполнение условий и последствия смены стадии |
| 6. Коммерческое решение | скидки, сроки, индивидуальные условия | подтверждение уполномоченным сотрудником |
Это пример распределения прав, не универсальная шкала безопасности и не обязательный путь до шестого уровня. Даже внутренняя заметка может запустить другой процесс, а смена стадии - финансовое действие. Оценивайте последствия конкретной операции; ограничения должны действовать в интеграции, а не только в текстовой инструкции агенту
Для критичных и субъективных решений Google Cloud описывает контрольные точки с подтверждением человеком 2
Какая информация действительно нужна агенту
Для квалификации заявки отберите сведения, которые действительно нужны. Вместо доступа ко всей CRM начните с такого набора
- самого обращения
- подтверждённых контактных данных
- последних значимых взаимодействий
- текущих открытых сделок
- каталога продуктов и ограничений
- правил квалификации
- таблицы маршрутизации
Дополнительные сведения агент получает через разрешённые инструменты по необходимости. Так проще ограничить доступ и восстановить, какие данные повлияли на конкретное решение
Контракт каждого инструмента
Для каждого инструмента зафиксируйте условия вызова и последствия. Такая карточка помогает проверить функцию до подключения к агенту
Карточка инструмента агента
- название действия
- какой вход обязателен
- какие данные функция читает
- что именно может изменить
- какие ошибки может вернуть
- можно ли безопасно повторить вызов
- нужно ли подтверждение человека
- что записывается в журнал
Реализация событий, повторов, прав и журналирования в CRM подробно разобрана в материале «Как интегрировать ИИ с CRM».
Особенно важно разобрать повтор после сетевой ошибки. Если команда не знает, как отличить выполненное действие от невыполненного, инструмент с записью данных ещё не готов к автономному использованию
Сценарий одного лида
Условная заявка: «Хотим автоматизировать заявки, 18 менеджеров, работаем в Битрикс24, подскажите порядок и бюджет». Возможная последовательность работы агента
- определить, что запрос относится к автоматизации продаж
- извлечь размер команды и используемую систему
- проверить, есть ли компания в базе
- посмотреть последние значимые контакты
- заметить, что не указаны объём заявок и основные каналы
- задать два коротких уточнения
- после ответа определить приоритет и подходящего специалиста
- создать внутреннюю карточку и задачу
- передать менеджеру краткий контекст и исходную переписку
Эта цепочка сама по себе не доказывает необходимость агента. Если уточнения и переходы можно заранее описать правилами, используйте их. Агентный подход стоит проверять, когда по ответам клиента системе приходится самой выбирать дополнительные вопросы, источники и проверки
Где агент должен остановиться
Заранее определите случаи, когда агент прекращает самостоятельные действия и передаёт задачу сотруднику
- клиент просит нестандартную скидку
- нужно дать юридическое обязательство
- данные из двух источников противоречат друг другу
- не удалось однозначно идентифицировать клиента
- человек прямо просит связаться с менеджером
- инструмент вернул неожиданный результат
- действие необратимо или потенциальный ущерб выше допустимого порога
При остановке сохраняйте собранные сведения, причину передачи и назначайте ответственного. Иначе безопасный отказ агента обернётся ещё одной заявкой, которую никто не обработал
Как собрать тестовый набор до запуска
Для начальной проверки Anthropic предлагает 20-50 простых задач, взятых из реальных ошибок 1. Это стартовый набор для разработки, не достаточный объём для автономного запуска. В продажах он должен охватывать и обычные заявки, и случаи, где агент обязан остановиться
Включите в набор разные ситуации
- обычная квалифицированная заявка
- неполная заявка
- существующий клиент
- дубль контакта
- конфликтующие данные
- просьба о скидке
- запрос вне профиля компании
- раздражённый клиент
- технический сбой инструмента
- повторное событие
Для каждого случая задайте проверяемый результат. Например, клиент найден, критичное поле не перезаписано, задача назначена нужному менеджеру, а сообщение со скидкой не отправлено без подтверждения. Формулировка ответа может меняться; ограничения и результат - нет
Почему одного процента правильных ответов мало
Ошибка в начале цепочки может проявиться только при последующем действии. Чтобы её найти, сохраняйте три уровня сведений
- входные факты - что агент получил
- траектория - вызванные инструменты, их входные данные, результаты и применённые правила
- конечное состояние - что реально изменилось в системах
Сообщение «задача создана» сверяйте с записью в CRM. Сохраняйте данные для проверки с ограничением доступа: журнал не должен становиться бесконтрольной копией клиентской базы
Метрики агента продаж
| Метрика | Зачем нужна |
|---|---|
| доля задач с правильным конечным состоянием | главный показатель надёжности |
| доля эскалаций | показывает границы самостоятельности |
| доля ручных исправлений | сигнал качества полей и решений |
| среднее число действий на задачу | помогает видеть лишние циклы |
| стоимость одного успешно обработанного лида | связывает технологию с экономикой |
| время до передачи менеджеру | показывает скорость процесса |
| ошибки по классам | отделяет модель, данные и интеграции |
| повторяемость результата | показывает вариативность между прогонами |
В опросе Salesforce участники ожидали от полного внедрения агентов сокращения времени на изучение потенциального клиента примерно на 34%, а на подготовку писем - на 36% 3. Это ожидания, а не измеренный эффект. Для своего проекта такие показатели нужно получить на пилоте, не переносить из отчёта в расчёт окупаемости
Как выпускать агента в живой процесс
Выпускайте систему по этапам, проверяя результат перед расширением прав
Теневой режим. Агент получает тот же вход и сохраняет предложения, но не меняет рабочие данные. Сотрудники работают как раньше; их решения и предложения агента затем сравниваются
Этап 2 - режим подсказки. Менеджер видит предложение агента и подтверждает или исправляет его
Ограниченные действия. Разрешите проверенные операции с приемлемым риском: например, внутренние заметки, задачи или некритичные поля. Сначала убедитесь, что они не запускают нежелательных последующих действий
Этап 4 - ограниченная внешняя коммуникация. Разрешаются только заранее определённые классы сообщений
Расширение прав. Следующий тип действий добавляйте, когда статистика ошибок, стоимость контроля и эффект текущего этапа оправдывают переход
На каждом этапе должна оставаться возможность остановить автоматические действия и передать незавершённые задачи сотрудникам. Полезный результат текущей ступени не обязывает переходить к следующей
источники и методика
- Anthropic: оценка ИИ-агентов - опубликовано 9 января 2026 года. Начальный набор 20-50 задач описан как начало работы над тестами, не норматив допуска
- Google Cloud: архитектура агентных систем - редакция с отметкой 28 мая 2026 года; раздел о подтверждении критичных действий человеком
- Salesforce: исследование состояния продаж, 2026 - опубликовано 3 февраля; 4 050 участников из 22 стран, опрос август-сентябрь 2025 года. Проценты экономии времени относятся к ожиданиям
Лестница прав, карточка инструмента и сценарий лида - авторские примеры проектирования, не результаты клиентских внедрений. Они требуют адаптации под реальные права, данные и последствия действий в компании
