How to Set a TTL on AgentCore Memory Records

Your agent has been quietly writing long-term memories since the day you shipped it, and by default every one of them lives forever. This guide adds an AgentCore memory TTL (time-to-live) so those records delete themselves after a retention period you choose. You will set it on a strategy, change it, remove it, and put the setting behind its own IAM permission so only the right people can touch retention.

1. Know which expiry clock you are setting

Amazon Bedrock AgentCore Memory has two expiry settings, and they cover different data:

• eventExpiryDuration is a required field on CreateMemory, up to 365 days. It expires raw events, the short-term memory.
• recordExpirySpecification is optional and set per strategy. It expires the long-term records a strategy extracts from those events. Without it, long-term records do not expire.

So shortening event retention does not clean up the facts, preferences and summaries your agent extracted. If your retention requirement is about what the agent has learned, the record TTL is the setting you need.

2. Grant the record-expiry IAM permission

Any request that sets or removes a recordExpirySpecification needs bedrock-agentcore:UpdateMemoryRecordExpirySpecification, on top of the base action. Without it you get an AccessDeniedException, even if the caller can already run UpdateMemory.

The permission is separate on purpose. A TTL is a deferred delete, so a principal who can configure a short one could delete newly generated records without ever holding DeleteMemoryRecord. This policy lets a principal manage memories and retention while withholding on-demand deletes:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageMemoryAndRetention",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:CreateMemory",
        "bedrock-agentcore:UpdateMemory",
        "bedrock-agentcore:UpdateMemoryRecordExpirySpecification"
      ],
      "Resource": "arn:aws:bedrock-agentcore:<region>:<account-id>:memory/*"
    }
  ]
}

Replace the Region and account ID, and narrow memory/* to specific memory ARNs where you can. Give the retention action to whoever owns your data-retention policy, not to every pipeline role.

3. Set an AgentCore memory TTL when you create the memory

Put recordExpirySpecification inside the strategy block. It works on built-in strategies and on custom ones with overrides.

aws bedrock-agentcore-control create-memory \
  --name "SupportAgentFactMemory" \
  --event-expiry-duration 90 \
  --memory-strategies '[
    {
      "semanticMemoryStrategy": {
        "name": "FactExtractor",
        "namespaceTemplates": ["/support_cases/{sessionId}/facts/"],
        "recordExpirySpecification": {
          "recordExpiryDurationDays": 60
        }
      }
    }
  ]'

Here events live 90 days and extracted facts live 60. The minimum for recordExpiryDurationDays is 31. The service stamps the TTL on each record at the moment it is generated.

4. Change the retention on an existing strategy

First find the strategy ID and see what is currently set. A strategy with no TTL shows null for days:

aws bedrock-agentcore-control get-memory \
  --memory-id "<memory-id>" \
  --query 'memory.strategies[].{id:strategyId,name:name,days:recordExpiryDurationDays}'

Then pass the new value in a modifyMemoryStrategies entry:

aws bedrock-agentcore-control update-memory \
  --memory-id "<memory-id>" \
  --memory-strategies '{
    "modifyMemoryStrategies": [
      {
        "memoryStrategyId": "<strategy-id>",
        "recordExpirySpecification": {
          "recordExpiryDurationDays": 45
        }
      }
    ]
  }'

The same call in boto3:

import boto3

control = boto3.client("bedrock-agentcore-control")

control.update_memory(
    memoryId="<memory-id>",
    memoryStrategies={
        "modifyMemoryStrategies": [
            {
                "memoryStrategyId": "<strategy-id>",
                "recordExpirySpecification": {"recordExpiryDurationDays": 45},
            }
        ]
    },
)

UpdateMemory answers with HTTP 202, so run the get-memory query again to confirm the change landed.

5. Remove the TTL with action REMOVE

A recordExpirySpecification takes exactly one of recordExpiryDurationDays or action. To stop future records from expiring, send REMOVE. It is not valid on create calls.

aws bedrock-agentcore-control update-memory \
  --memory-id "<memory-id>" \
  --memory-strategies '{
    "modifyMemoryStrategies": [
      {
        "memoryStrategyId": "<strategy-id>",
        "recordExpirySpecification": {
          "action": "REMOVE"
        }
      }
    ]
  }'

6. Decide whether you still need a pruner

AWS's lifecycle-policy post builds retention by hand. A nightly Step Functions workflow computes a cutoff, lists records whose x-amz-agentcore-memory-createdAt is BEFORE it, and deletes them. That post treats AgentCore as having no built-in auto-delete TTL, which is no longer true for new records.

For pure age-based deletion, the built-in setting wins: no schedule, no list-and-delete code, no delete permissions to hand out. Keep a pruner for what a TTL cannot do, such as relevance decay scoring, merging low-value memories, and records that already existed before you set a TTL.

Gotchas

• Changes only reach new records. Cutting 90 days to 45 does not shorten records that already exist, and REMOVE does not rescue records that already carry an expiry. Expired records cannot be recovered. eventExpiryDuration behaves the same way for events.
• Deletion is not instant. Removal can take a few days after the TTL elapses, and expired records can still come back from RetrieveMemoryRecords, GetMemoryRecord and ListMemoryRecords. For a hard "gone now" requirement, call DeleteMemoryRecord or BatchDeleteMemoryRecords.
• Some strategies must agree. Semantic and user preference strategies must share one recordExpiryDurationDays. So must summary and episodic strategies.
• Self-managed and batch writes ignore the strategy setting. For records written through BatchCreateMemoryRecords or BatchUpdateMemoryRecords, set --record-expiry-specification on the request itself. It needs the same IAM action.
• Anything under 31 days is out of range. Plan retention around that floor.

A memory that never forgets is a liability you have not priced yet, and one field plus one IAM action is enough to start pricing it.