AWS Open-Sources AgentCore Memory Eviction Workflow, Filling the Built-In TTL Gap with a Scheduled Workflow

Long-running agents continually accumulate conversation summaries, user preferences, and operational experience. If every record is retained permanently, retrieval may reintroduce resolved incidents or outdated procedures into the context. AWS has therefore published an [AgentCore Memory lifecycle reference architecture](https://aws.amazon.com/blogs/machine-learning/designing-lifecycle-policies-for-agentcore-memory/) that categorizes memories as frequently used, faster-expiring episodic memory; more durable semantic memory; and procedural memory, which should be evicted cautiously.

This solution does not add built-in automatic TTL support to AgentCore. It uses `ListMemoryRecords` with a `BEFORE` filter applied to the system creation time, while EventBridge triggers Step Functions nightly. The workflow chains Lambda functions to perform expiration-based deletion, relevance scoring, batch consolidation, metrics emission, and audit logging in sequence. By default, episodic memory has a hard retention period of 90 days. Low-scoring records are passed to a Bedrock model, which consolidates them into semantic summaries containing confidence scores and source IDs; the originals are deleted only after the summaries have been written back successfully. Failure paths preserve the original memories and send alerts through SNS.

The engineering value lies in turning “forgetting” into an observable, regression-testable data pipeline. The sample uses AgentCore Evaluations to compare response scores before and after consolidation, and provides a handler for deleting an individual user’s memories, CloudTrail API auditing, and a CloudWatch dashboard. However, the [GitHub repository](https://github.com/aws-samples/sample-memory-lifecycle-policies-for-bedrock-agentcore) is explicitly labeled as not intended for production use. LLM-based consolidation is inherently lossy, and confidence scores do not prove fidelity. High-risk deployments should still retain cold backups and add human review or grounding-based validation.

The public materials also currently show version discrepancies. The AWS article describes a three-factor score based on creation time, most recent access, and access frequency, while the repository README presents a two-factor, equally weighted decay formula. The article’s workflow diagram also lists five Lambda stages, whereas the README’s resource list specifies four functions. Deployers should rely on the actual commit and the synthesized CloudFormation, and verify CloudTrail query costs, deletion idempotency, tenant namespace isolation, and data-retention regulations instead of adopting the sample thresholds unchanged.