Как согласовать изменения двух агентов ИИ в одной заявке

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

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

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

Когда ИИ начинает действовать в корпоративных системах, качество его рассуждений становится только частью задачи. Компании нужен порядок, по которому несколько участников меняют общий объект. И этот порядок полезно обсудить до того, как второй помощник получит кнопку «Сохранить».

Общая карточка не делает работу согласованной

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

В нашем примере первый агент опирался на состояние заявки до появления препятствия. Пока он составлял ответ, карточка изменилась. Его вывод оказался устаревшим ещё до записи.

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

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

Разделите сведения и правила состояния процесса

В карточке часто смешаны сведения разного происхождения. Контактное лицо сообщил номер телефона. Агент предположил готовность объекта. Диспетчер назначил исполнителя. Все три записи выглядят одинаково, хотя их полномочия различаются.

Полезно разложить работу на три уровня. Первый — зарегистрировать полученное сообщение или подтверждённый факт. Второй — предложить действие на его основании. Третий — изменить официальное состояние заявки.

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

Такое разделение особенно важно для вычисляемых статусов. Если «Готово к выезду» означает наличие оборудования, доступа и назначенного специалиста, статус должен зависеть от этих признаков по определённому правилу. Свободная формулировка агента не должна становиться единственным основанием перехода.

У небольшой компании это может быть простая проверка полей. Большая организация добавит проверки связанных объектов. Принцип одинаков: содержание сообщения и право менять рабочее состояние описываются отдельно.

У состояния должен быть владелец

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

Это не означает, что все поля редактирует один человек. Менеджер уточняет контакт, инженер фиксирует результат осмотра, агент распознаёт содержание обращения. Но официальный переход проходит через установленную проверку. У неё есть правила, ответственный за их изменение и журнал результатов.

Можно начать с короткой таблицы полномочий:

Таблица предложена для учебного примера. В другом процессе роли будут другими. Её польза в том, что компания может обнаружить две автоматизации, которые считают себя окончательным хозяином одного статуса.

Если такую коллизию нашли, не спешите выбирать более умную модель. Сначала договоритесь, кто принимает изменение и на каких основаниях.

Версия защищает запись от устаревшего решения

Для контроля конкурентных изменений применяют оптимистическую проверку версии. Помощник получает карточку вместе с признаком её версии. Когда отправляет изменение, указывает, на какой версии оно подготовлено. Система принимает его, только если исходное условие ещё выполняется.

Представим условные версии 17 и 18. Оба агента прочитали версию 17. Помощник поддержки записал отсутствие доступа, карточка стала версией 18. Изменение помощника клиентского сервиса, подготовленное по версии 17, отклоняется. Дальше ему нужно прочитать новое состояние и заново оценить действие.

Ключевая деталь: проверку и запись выполняет принимающая система как одну согласованную операцию. Два отдельных шага «сравнить версию», затем «сохранить» могут оставить тот же промежуток для чужого изменения.

Механизмы отличаются. Некоторые API предоставляют ETag и условные запросы, другие — поле версии или специальный метод обновления. Самостоятельно добавленная колонка «Версия» не создаёт защиту, если никто не проверяет её при записи. И признак версии не всегда является числом: его смысл и допустимые операции определяет API.

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

Не повторяйте отклонённый запрос вслепую

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

В условной заявке после отказа нужно показать помощнику новое препятствие. Предложение о готовности выезда больше не подходит. Можно сохранить подтверждение наличия оборудования, но переход отложить.

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

Проверяйте зависимости при изменении отдельных полей

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

Однако частичное изменение само по себе не гарантирует согласованность. Два агента могут менять разные поля, которые вместе определяют результат. Один снимает признак ожидания доступа, другой меняет адрес объекта. Каждая запись технически допустима, но подтверждение доступа для старого адреса не относится к новому.

Для таких случаев нужно обозначить зависимость: подтверждение доступа связано с конкретным объектом и его актуальными данными. Когда они меняются, проверка готовности должна это учитывать. Простого правила «агенты пишут в разные колонки» недостаточно.

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

Приоритет нужен конкретному событию

Фраза «поддержка важнее продаж» слишком груба для рабочего процесса. Новый телефон из клиентского чата может быть достовернее старого телефона в служебном комментарии. А сообщённая проблема доступа может запрещать выезд независимо от того, какой помощник её зарегистрировал.

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

Вот учебный разговор при настройке:

— Пусть сервисный агент всегда побеждает. Он ближе к клиенту.

— Если он узнал новый номер, принимаем номер. Если он предлагает выезд при закрытом доступе, предложение отклоняем.

— А если клиент пишет, что всё уже открыто?

— Проверяем, какое подтверждение требуется для снятия ограничения. Сам статус ограничения по одной уверенной фразе не исчезает.

Такой разговор вскрывает содержание полномочий. Агент может понимать текст и готовить предложение. Правило принятия остаётся проверяемым и одинаковым для одинаковых обстоятельств.

Не поручайте третьей модели быть окончательным судьёй

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

Если третий агент просто сравнит два красивых текста, он может предпочесть более подробное обоснование, не заметив, что оно построено на старых данных. Его ответ тоже способен устареть до применения.

Для рабочего контроля нужны проверки, которые при одинаковых входных данных дают одинаковый результат: существует ли объект, действительна ли исходная версия, разрешено ли участнику действие, выполнены ли обязательные условия. Это называют детерминированными проверками. Модель помогает извлекать смысл из неструктурированных сообщений; определённый порядок проверяет допустимость изменения.

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

Запись в CRM ещё не управляет всеми последствиями

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

Представим: переход принят, затем до отправки уведомления появилась новая блокировка. Текст «бригада назначена» должен опираться на действительный результат назначения и актуальные условия отправки. Нельзя считать исходное предложение агента доказательством успешного действия.

Для последствий нужен свой порядок: какая запись служит основанием, как результат связан с заявкой, что происходит при изменении условий. Интегратор может организовать последовательное применение команд или отдельный сервис переходов. Конкретная техника зависит от CRM и внешних систем.

Если CRM не поддерживает условные обновления, промежуточный сервис способен упорядочить запросы, проходящие через него. Но его защита ограничена, если сотрудники, другие роботы и прямые интеграции продолжают менять те же поля в обход. Этот предел нужно проверить до запуска.

Общая агентная платформа задаёт общий порядок действий

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

Единая агентная платформа полезна общими идентификаторами объектов, контролем полномочий, правилами обращения к инструментам и историей попыток изменения. Разные модели могут разбирать разные каналы, но сохранять результаты по одному согласованному порядку.

Здесь есть граница централизации. Не нужно переносить все данные компании в память каждого агента. Помощник получает сведения, необходимые для его задачи. CRM или другой профильный сервис может оставаться местом официального состояния. Платформа организует доступ и выполнение, а устойчивость записи обеспечивается конкретной реализацией.

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

Проверьте столкновения до запуска

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

1. Оба участника прочитали одно состояние, затем сохраняют разные результаты.
2. Во время подготовки ответа сотрудник вручную добавил ограничение.
3. Контакт обновился, пока другой сценарий менял назначение.
4. Агент получил отказ и пытается повторить прежний переход.
5. Условия изменились после принятия перехода, но до внешнего действия.

Для каждой ситуации заранее запишите ожидаемый итог. Смотрите на сохранённые сведения и выполненные действия. Успешный ответ API ещё не доказывает, что нужный факт остался в карточке.

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

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