ИИ-агентам мало правил: зачем бизнесу хранить следы решений
Бизнес часто думает, что для ИИ-агента достаточно трех вещей: доступ к базе, набор правил и сильная модель. Но в реальной работе этого мало. Самые важные решения редко живут только в CRM, регламенте или таблице. Они живут в переписках, созвонах, исключениях, прошлых согласованиях и негласной памяти команды.
Поэтому агенту мало знать правило. Ему нужно видеть, как это правило применяли в жизни. Кто разрешил исключение? Почему клиенту дали скидку выше лимита? Из-за какого сбоя поддержка изменила стандартный ответ? На каком основании руководитель согласовал нестандартную поставку? Если эти следы не сохраняются, агент будет каждый раз заново угадывать то, что команда уже давно решила.
Что такое след решения
След решения — это не просто лог действий. Лог говорит: кто нажал кнопку и когда. След решения объясняет, почему действие стало разумным в той ситуации. Он связывает видимые факты: клиента, договор, заявку, правило, исключение, человека, который согласовал шаг, и итог.
В статье Foundation Capital про context graphs это названо decision traces — следами решений. Мы будем говорить по-русски: следы решений и граф рабочего смысла. Смысл простой: если компания хочет, чтобы ИИ действовал не как случайный чат, а как участник рабочего процесса, ей нужно сохранять не только данные, но и причины действий.
| Обычная система хранит | След решения добавляет | Зачем агенту |
|---|---|---|
| Финальную цену сделки | кто и почему одобрил скидку | не повторять спор с нуля |
| Статус заявки | какие факты изменили стандартный ответ | учитывать исключения |
| Регламент | как регламент применяли в похожем случае | видеть прецедент |
| Комментарий в чате | связь комментария с клиентом, риском и решением | не терять рабочую память |
Почему CRM и база знаний не закрывают вопрос
CRM хорошо показывает текущее состояние: клиент, стадия, сумма, ответственный. База знаний хорошо хранит правила: что можно, что нельзя, какой порядок действий. Но между правилом и конкретным решением часто лежит человеческая работа. Менеджер помнит, что похожему клиенту уже давали отсрочку. Руководитель знает, что этот партнер важен для следующего проекта. Поддержка видит, что формально клиент неправ, но до этого сервис трижды сорвал срок.
Если всё это остается в головах и чатах, агент получает плоскую картину. Он видит правило, но не видит причины исключения. Видит заявку, но не видит историю доверия. Видит цену, но не видит, почему ее согласовали. В итоге агент либо действует слишком жестко, либо постоянно зовет человека, либо начинает придумывать логику сам.
В продолжении темы Foundation Capital прямо говорит о графе рабочего смысла как о недостающем слое для ИИ: не просто данные, а связи между событиями, решениями и причинами. Для бизнеса это звучит менее модно, но гораздо полезнее: надо научиться сохранять рабочие "почему".
Редакционный вывод: если решение нельзя восстановить через месяц, его нельзя безопасно автоматизировать завтра.
Как это связано с нашей платформенной логикой
В статье про LABA как усиление бизнеса мы описывали похожую рамку: компания сначала задает идеальную структуру работы, потом наполняет ее реальными процессами и видит, как замысел воплощается в действиях. Следы решений — это слой между планом и реальностью. Он показывает не только "как должно быть", но и "как на самом деле решили в конкретном случае".
Это особенно важно для агентных систем. Агент, который видит только план, будет формальным. Агент, который видит только хаос чатов, будет шумным. Рабочая система появляется тогда, когда план, реальные действия, исключения и подтверждения собираются в одну карту. Тогда нейросеть становится не отдельным чатиком, а интерфейсом к информационной системе компании.
Исследовательская работа AgentTrace смотрит на похожую проблему со стороны надежности: когда в многоагентной системе что-то идет не так, нужно восстанавливать причинную цепочку. В бизнесе задача такая же, только язык проще: понять, почему агент предложил действие, какие данные он видел и где человек подтвердил важный шаг.
С чего начать без большой перестройки
Начинать можно не с огромного графа, а с трех привычек. Во-первых, фиксировать не только итог решения, но и причину. Во-вторых, связывать исключение с объектом: клиентом, сделкой, заявкой, документом, инцидентом. В-третьих, отдельно отмечать, кто подтвердил шаг и при каких условиях.
Например, если поддержка разрешила возврат после формального срока, запись должна хранить не только "возврат одобрен". Она должна хранить: доставку переносили три раза, коробка приехала поврежденной, клиент важный, руководитель подтвердил исключение. Тогда следующий агент не будет слепо читать правило "14 дней". Он увидит рабочую историю применения правила.
Это не отменяет регламенты. Наоборот, делает их живыми. Правило остается правилом, но рядом появляется история его применения. И именно эта история постепенно становится самым ценным материалом для автоматизации: она показывает, как компания думает, где рискует, где уступает, где держит границы и где доверяет человеку.
