AWS предложила ночной конвейер очистки памяти AI-агентов

Память агента становится управляемым ресурсом

AWS опубликовала референсную архитектуру lifecycle management для Amazon Bedrock AgentCore memory. Её задача — не дать долгоживущему агенту бесконечно накапливать устаревший контекст, который ухудшает ответы и создаёт compliance risk. Вместо ручной уборки система каждую ночь оценивает, объединяет и удаляет записи.

Решение ориентировано на support, sales и IT helpdesk агентов, которые неделями или месяцами собирают большие объёмы взаимодействий. Для персонального ассистента с меньшим потоком AWS предлагает начать с простого TTL и процедур удаления данных по требованиям GDPR, а более сложные политики подключать по мере роста памяти.

Практический смысл подхода — отделить сохранение воспоминаний от правил их дальнейшей судьбы. Запись в memory store ещё не означает вечное хранение: у каждого типа данных должны быть срок, измеримая полезность, допустимый способ сжатия и проверяемое удаление.

Три типа памяти требуют разных сроков

AWS делит память на episodic, semantic и procedural. Episodic memory хранит конкретные разговоры и события: она объёмная, привязана ко времени и быстрее теряет актуальность. Semantic memory содержит извлечённые факты и предпочтения вне отдельной сессии, поэтому компактнее и обычно живёт дольше.

Procedural memory описывает выученные процессы и порядок использования tools — например, сначала запросить Cost Explorer, затем сформировать сводку. Такие записи могут быть особенно ценными и требуют наиболее высокого порога для pruning, но их всё равно нужно проверять при изменении процессов.

Для production-политики это означает, что единый retention period недостаточен. AWS предлагает как отправные точки 30–60 дней для summary memories, 6–12 месяцев для semantic memories и возможность не задавать TTL для procedural, сохраняя отдельную проверку их валидности.

Сначала TTL, затем relevance score

Первый этап удаляет записи старше `memoryTtlDays`; значение по умолчанию — 90 дней для episodic memory. В AgentCore memory нет встроенного auto-delete TTL, поэтому pruner фильтрует записи по системной метке создания через оператор `BEFORE`, а затем явно вызывает удаление.

Оставшиеся записи получают score из трёх сигналов: давность создания, давность последнего доступа и частота обращений. Весовые значения по умолчанию равны 0,4, 0,35 и 0,25, а параметр `pruneDays` преобразуется в коэффициент экспоненциального затухания. При `pruneDays = 45` и threshold 0,3 AWS приводит decay rate около 0,02676.

Поскольку AgentCore не возвращает `lastAccessedAt` в `MemoryRecordSummary`, архитектура восстанавливает обращения из CloudTrail data events `GetMemoryRecord`. Ночной scorer читает логи за 25 часов, объединяет их с накопительным ledger в S3 и получает lifetime access count, а не только дневной срез.

LLM сжимает записи перед удалением

Низкий score не сразу ведёт к потере данных. Memory Consolidator собирает связанные episodic memories и просит модель в Amazon Bedrock создать одну semantic summary, сохранить существенные факты, убрать повторы и вернуть confidence score. Затем новая запись сохраняется, а исходные удаляются.

AWS подчёркивает fail-safe поведение: если вызов Bedrock завершился ошибкой, originals остаются без изменений; неудачные удаления записываются для ручной проверки. Компания также прямо признаёт, что consolidation является lossy-операцией и может потерять нюансы.

Для high-stakes сценария авторы рекомендуют не удалять originals сразу, а архивировать их в cold storage, применять Bedrock Guardrails и grounding checks. Confidence от той же модели не является независимым доказательством качества, поэтому регрессионный набор должен проверять, сохранились ли критические факты после lifecycle run.

Step Functions связывает контроль и аудит

Ночной workflow запускается EventBridge и проходит последовательность в Step Functions: TTL expiration, scoring, consolidation низкооценённых записей, публикация metrics и сохранение результата в S3. Ошибки маршрутизируются в SNS, а CloudWatch показывает количество обработанных, объединённых и удалённых memories.

Отдельный GDPR Deletion Handler удаляет все memories конкретного пользователя и возвращает число успешных операций вместе со списком failed IDs. Мутации журналируются структурированно, а CloudTrail формирует audit trail вызовов AgentCore memory API.

AWS публикует CDK stack и код, но сама архитектура требует адаптации: thresholds зависят от сценария, удаление должно учитывать юридические сроки, а качество consolidation — проверяться на собственных вопросах агента. Надёжный memory lifecycle — это не периодический `DELETE`, а наблюдаемый процесс с provenance, regression tests, безопасным отказом и возможностью доказать, что конкретная запись действительно исчезла.