Когда агент ошибается: ситуация, проблема и что мы с ней делаем
Гипотетический, но типичный случай — и наш ответ на него
Гипотетический, но типичный случай — и наш ответ на него
Ситуация
Представьте сеть клиник, которая поставила нашего агента на запись и подтверждение приёмов. Агент работает в WhatsApp и по телефону, видит расписание, переносит слоты, отменяет записи и возвращает предоплату.
Однажды в пятницу вечером администратор, которая обычно подтверждает возвраты, уезжает и отключает телефон. В субботу пациент просит отменить приём и вернуть деньги. Агент видит, что отмена разрешена, а возврат — «в пределах полномочия», и делает и то и другое. В понедельник выясняется: администратор как раз в пятницу отозвала право на возвраты — но отзыв жил в другой системе, а агент о нём не узнал.
Деньги вернулись не тому пациенту и не в том объёме. Клиника задаёт нам три вопроса: кто это разрешил, почему агент не остановился и что мы можем предъявить.
Проблема
Проблема не в том, что модель ошиблась. Проблема в том, что в системе не было ответа на три вещи одновременно.
Первое. Полномочие жило отдельно от действия: право на возврат было отозвано в одном месте, а исполнялось в другом, и между ними не было связи.
Второе. Никто не описал, что происходит, когда подтверждающего нет на связи. По умолчанию система повела себя как «разрешено», а не как «запрещено».
Третье. У клиники остался лог. Подробный, красивый и бесполезный: из него нельзя было понять, на каком основании действие разрешили и было ли это основание действительным в ту секунду.
Это не экзотика. Так выглядит почти любой разбор инцидента с агентами: полномочие, решение и исполнение живут в разных местах, а доказательства собираются постфактум и не отвечают на главный вопрос.
Как мы это решаем
Мы не обещаем, что агент не ошибётся. Мы строим так, чтобы ошибка была ограниченной, остановимой и проверяемой.
Полномочие с границами и сроком. Агент действует не «вообще», а внутри выданного мандата: какие действия, до какой суммы, в каких каналах, до какой даты. Возврат денег, подпись документа, публикация — либо вне мандата, либо через подтверждение человека.
Правило на случай, когда никого нет. Мы заранее описываем, что разрешено без владельца, а что запрещено. По умолчанию — запрещено. Отзыв останавливает следующее действие, а не следующую переписку.
Запись, которая отвечает на вопрос «на каком основании». По каждому значимому действию остаётся след: какое полномочие, какое решение, что отправлено, что реально произошло на стороне получателя — и отдельно то, чего мы не измеряли. Последнее важно: запись, которая притворяется полной, хуже, чем запись, которая честно помечает пробелы.
Разбор, а не оправдание. Мы разбираем инцидент по заранее определённым сценариям — отказ в точке решения, устаревшее доказательство, недоступная власть, отзыв после отправки — и показываем, что из этого сработало, а что нет.
Договор. Что считается инцидентом, за сколько часов мы о нём сообщаем, кто отвечает за откат и в каких пределах. Без этого предыдущие четыре пункта — обещания.
Что получает клиент
В том же примере с клиникой: возврат не проходит, потому что право отозвано и отзыв проверяется в момент действия; если администратора нет, действует заранее согласованная граница, а не догадка; к понедельнику у клиники есть не «лог», а разбор: почему система поступила так, что было доказано и что осталось за пределами измерения.
Что мы не делаем
Не продаём сертификат соответствия. Не утверждаем, что доказали безопасность агента вообще. Не берёмся доказать в одиночку, что получатель исполнил именно это действие — часть гарантии живёт на стороне исполнителя и цели, и мы это прямо пишем.
Если хотите, разберём ваш сценарий: покажем, где сейчас проходит граница полномочия, что произойдёт, если ответственный исчезнет, и как будет выглядеть запись после инцидента.