Агент, который помнит атомами, копит опыт.

Большинство агентов помнят кусками текста: «Пользователь Дмитрий из Москвы, работает в интеграторе, предпочитает Postgres». Через месяц он переехал в Казань. Переписывать весь абзац? Хранить оба и надеяться, что LLM угадает, какой свежее?

Решение — атом памяти: один факт, одна запись.

кто — что — чему равно + откуда узнали, насколько верим, когда это правда, кому можно видеть.

Атом можно отдельно найти, исправить, проверить и удалить, не трогая остальное.

Пример: Факт изменился Март: «Дмитрий работает из Москвы». Октябрь: «Переезжаю в Казань с 19-го».

Агент не перезаписывает старое. Он закрывает первый атом датой 19 октября и создаёт новый со ссылкой «заменяет предыдущий». Теперь он отвечает на три разных вопроса: Где Дмитрий сейчас? В Казани. Где он был 17 октября? В Москве: о переезде уже знали, но он ещё не случился.

Что агент думал о нём в сентябре? Что он в Москве. Это нужно, когда разбираешь, почему агент тогда дал такой совет.

Где всё это лежит Атом — одна логическая запись, разложенная по хранилищам: -PostgreSQL — сам факт и метаданные, источник правды; -векторная БД — только индекс, чтобы найти атом по смыслу; -граф — связи между фактами; -Vault — чувствительные значения, в атоме только ссылка на них.

Правило: в PostgreSQL атомы только добавляются и закрываются, но не перезаписываются. Остальные базы — индексы и выносные хранилища. Индексы можно пересобрать, “матку” правду — нет.

Что это даёт -Воспроизводимость. Можно восстановить, что агент знал в любой момент прошлого и почему принял решение. -Точечный комплаенс. Попросили забыть местоположение (привет, 152-ФЗ)? Стираем содержимое атомов с пометкой «локация» и всё, что из них выведено. Остаётся только отметка «удалено» для аудита, остальная память не страдает. -Обучение на исходах. Решения не просто копятся: каждое проверяется результатом.

Как выглядят контракты Semantic — факт. Структурированная связь сущностей  Bitemporal-факты . Атом памяти — это строго структурированные данные.