Память агента нельзя просто копить. Старые факты начинают мешать: агент берёт устаревший статус заказа или неактуальное правило и принимает по ним решения.

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

Pipeline из пяти этапов Classify. Определяем тип и назначение записи: состояние задачи, эпизод, знание, сведения о сущности, внешний документ или кэш. Риск: ошибка в классификации приводит к неподходящей политике хранения.

Evaluate. Оцениваем возраст, надёжность источника, значимость, частоту использования и вероятность изменения. Риск: удалить полезное из-за возраста или оставить устаревший факт.

Apply Policy. Решаем: сохранить, обновить, снизить приоритет, архивировать или удалить. Риск: потерять опыт или накопить мусор.

Validate. Перед критичным использованием перепроверяем изменяемые факты по авторитетным источникам, учитываем версии и даты. Риск: решение на устаревших данных.

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

Что нужно в production -TTL: срок жизни записи. -Decay Function: приоритет снижается со временем, но запись не удаляется. -Event-based Invalidation: сброс при изменении источника. -Versioning: история изменений и актуальная версия. -Revalidation: повторная проверка перед критичным использованием. -Retention Policy: сроки хранения с учётом безопасности и законодательства.

Критичные решения об удалении не стоит отдавать одной LLM(оценка 2-3 LLM). Это три разных решения: -Freshness: насколько информация актуальна. -Priority: насколько важно достать её сейчас. -Retention: нужно ли её вообще хранить.

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