AI помнит всю переписку — и всё равно использует устаревшие условия сделки

Понедельник — с клиентом согласовали 100 единиц.
Среда — условия изменились: теперь 60.
Пятница — AI готовит коммерческое предложение на 100.
Система ничего не «забыла». Старая реплика действительно есть в переписке. Более того, она выглядит вполне правдоподобно: когда-то 100 единиц действительно были правильным значением.
Проблема в другом: к пятнице это уже не текущая правда.
Это иллюстративный сценарий, а не реальный клиентский инцидент из моей практики. Он нужен, чтобы показать тип сбоя, который легко пропустить, когда бизнес говорит: «Нам нужна память для AI».

Когда AI теряет информацию, проблему обычно видно сразу: он переспрашивает то, что уже обсуждали, не помнит контекст или отвечает так, будто разговор начался заново.
С устаревшим фактом сложнее.
В сохранённой истории есть оба значения: и 100, и 60. Оба действительно появлялись в разговоре. Оба относятся к одному клиенту и одной сделке.
Если просто искать релевантный текст в истории, старое значение может оказаться таким же убедительным, как новое.
И здесь важен не вопрос:

«Сохранили ли мы всю переписку?»

Сохранили.

Важен другой:

какой факт имеет право управлять следующим действием системы?

Для коммерческого предложения это уже не задача красивого ответа. Это задача управления состоянием бизнес-процесса.

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

В нашем сценарии в ней честно существуют две записи:

100 единиц — было согласовано в понедельник.
60 единиц — стало актуально в среду.

Если системе нужно объяснить, как развивался разговор, обе записи важны.
Если ей нужно подготовить следующий документ, равноправными они уже быть не могут.
Поэтому в рабочей AI-системе мне важно отдельно понимать текущее операционное состояние процесса: какое количество сейчас подтверждено, какой срок действует, какой статус у согласования, что уже утверждено, а что пока обсуждается. Где именно живёт это состояние — отдельный архитектурный вопрос. Это может быть запись заказа, CRM, ERP, внутренний процесс, утверждённый документ или другое место. Я бы не делала из одного инструмента универсальное правило.
Смысл не в том, что текущее состояние обязательно должно жить в CRM. Смысл в другом: у следующего действия должен быть источник текущей подтверждённой правды, а не только большой архив текста.

Кажется, что можно ввести простое правило: если значения конфликтуют, использовать самое свежее. Но время сообщения и его полномочия — не одно и то же.

Допустим, после подтверждённых 60 единиц клиент пишет:

«А если сделать 50?»

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

Именно это часто теряется за фразой:

«Давайте дадим AI всю историю».

Вся история помогает увидеть конфликт. Но сама по себе она не решает, какая версия должна победить.

Проблема становится ещё интереснее, когда системе нужен контекст не только внутри одного разговора, но и между разными сессиями. В документации Google Cloud сессия описывается как последовательность сообщений и действий внутри взаимодействия, состояние — как данные, связанные с текущим разговором, а память — как информация, доступная между несколькими сессиями. То есть это уже разные задачи системы, даже если пользователю всё выглядит как одно «AI помнит». При этом сам факт хранения разговора ещё не означает, что нужная информация автоматически станет правильным контекстом в будущем. Для долговременной памяти требуется решить, что записывать и что потом извлекать. Например, в Google Cloud Memory Bank память может формироваться из истории сессии, а приложение также может отдельно управлять созданием и извлечением сохранённых фактов.
И здесь появляется важная проблема.
Система может очень надёжно сохранить то, что позже перестало быть актуальным.AI может безошибочно найти старое значение 100, правильно связать его с клиентом и сделкой — и всё равно подготовить неправильный следующий шаг. Поэтому для долговременного контекста мне важны не только содержание, но и происхождение факта, его версия, область действия и актуальность.
Не всё, что однажды было правдой, должно потом всплывать как действующее условие. И я бы не сводила память к какой-то одной технологии. Она не обязана быть одной конкретной базой или одним типом поиска.

Важнее другое:

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

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

Перед следующим действием система должна уметь ответить хотя бы на четыре вопроса:

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

умеет ли она отличать сохранённую информацию от актуальной информации

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

Это не три обязательные базы данных и не универсальная схема для всех AI-систем. Конкретная архитектура зависит от процесса.

Но один принцип я бы сохраняла:

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

Поэтому главный вопрос при проектировании памяти для AI для меня звучит не так:

«Как сохранить больше контекста?»

А так:

какой факт в этой системе имеет право управлять следующим действием?

Google Cloud — Agent Platform Sessions overview. Описание session, events, state и memory и их разных ролей. Открыть документацию Google Cloud

Google Cloud — Agent Platform Memory Bank. Как формируется и используется долговременная память между сессиями, включая генерацию и извлечение memories. Открыть документацию Memory Bank

Google Cloud — Use an Agent Development Kit agent. Отдельные операции добавления сессии в память и поиска сохранённой памяти. Открыть документацию ADK и Memory