Políticas de ciclo de vida para memória no AgentCore: como manter agentes de IA organizados e eficientes

O problema de agentes com memória descontrolada

Agentes de IA que rodam por semanas ou meses acumulam um volume enorme de memórias. Sem uma gestão ativa, esse acúmulo se torna um problema real: o agente começa a referenciar contextos desatualizados, repetir orientações obsoletas e até criar riscos de conformidade. A AWS documentou casos concretos disso — um agente de suporte que tratava uma disputa de cobrança resolvida há quatro meses como ainda ativa, e outro que repetia instruções de deploy de um runbook já substituído.

Para resolver esse problema, a AWS publicou uma arquitetura de gerenciamento de ciclo de vida de memórias para agentes rodando no AgentCore Memory, uma capacidade do Amazon Bedrock AgentCore. A solução usa AWS Step Functions, Amazon Bedrock e AWS CDK (Kit de Desenvolvimento em Nuvem) para executar um workflow noturno que avalia, consolida e descarta memórias automaticamente. O código completo está disponível no GitHub.

Taxonomia de memória: três tipos com necessidades diferentes

Antes de definir políticas, é importante entender o que os agentes lembram. A AWS categoriza a memória dos agentes em três tipos:

• Memória episódica: registros do que aconteceu em conversas passadas. São vinculadas a sessões específicas, têm alta volumetria e perdem relevância com o tempo. São as primeiras candidatas à expiração.
• Memória semântica: fatos e preferências extraídos das interações, mas desvinculados de uma conversa específica. Exemplo: “o usuário prefere a região us-east-1 para deploys.” São mais duráveis e compactas — devem ser retidas por mais tempo e são as melhores candidatas à consolidação.
• Memória procedural: fluxos de trabalho aprendidos e padrões de uso de ferramentas. Exemplo: “quando o usuário pergunta sobre custos, consulte primeiro o AWS Cost Explorer API, depois resuma.” São o tipo mais valioso para certos casos de uso, têm menor volume e o maior critério de descarte. O AgentCore armazena esse conhecimento como reflexões vinculadas à memória episódica — veja mais detalhes no blog de deep dive sobre memória episódica.

As três políticas de ciclo de vida

Política 1: Expiração por TTL (Tempo de Vida)

A primeira política deleta automaticamente memórias mais antigas do que um TTL (Tempo de Vida) configurável. O padrão sugerido é 90 dias para memórias episódicas. O TTL não avalia se a memória ainda é útil — ele apenas impõe um limite máximo de acúmulo, essencial para conformidade regulatória.

Em produção, a recomendação é diferenciar o TTL por tipo: memórias de resumo expiram em 30 a 60 dias, memórias semânticas em 6 a 12 meses, e memórias procedurais podem não ter TTL. O AgentCore Memory não oferece auto-delete nativo, mas expõe campos de timestamp que permitem filtrar registros com operadores BEFORE e AFTER. O código usa o campo x-amz-agentcore-memory-createdAt para buscar e deletar registros antigos:

cutoff = (now - timedelta(days=ttl_days)).isoformat()
response = client.list_memory_records(
    memoryId=memory_id,
    namespace=agent_id,
    metadataFilters=[{
        "left": {"metadataKey": "x-amz-agentcore-memory-createdAt"},
        "operator": "BEFORE",
        "right": {"metadataValue": {"dateTimeValue": cutoff}},
    }],
)

Política 2: Pontuação de decaimento de relevância

Nem todas as memórias envelhecem no mesmo ritmo. Uma memória acessada ontem é mais relevante do que uma que não foi consultada há semanas. A solução pontua cada memória com uma fórmula de três termos ponderados que combina recência de criação, recência do último acesso e frequência de acesso:

score = W_RECENCY * exp(-decay_rate * days_since_creation)
      + W_ACCESS  * exp(-decay_rate * days_since_last_access)
      + W_FREQUENCY * min(access_count / MAX_ACCESS_BASELINE, 1.0)

Em vez de expor uma constante de decaimento bruta, a solução oferece o parâmetro pruneDays: o número aproximado de dias após o qual uma memória não acessada cai abaixo do limiar de relevância. Com os valores padrão (pruneDays = 45, threshold = 0.3), a taxa de decaimento calculada é aproximadamente 0,02676.

Os três pesos são configuráveis para diferentes perfis de agente:

• W_RECENCY (padrão 0.4): peso para recência de criação. Valores maiores favorecem memórias mais novas.
• W_ACCESS (padrão 0.35): peso para recência do último acesso. Valores maiores favorecem memórias consultadas recentemente.
• W_FREQUENCY (padrão 0.25): peso para frequência de acesso. Valores maiores favorecem memórias muito consultadas.
• MAX_ACCESS_BASELINE (padrão 50): número de acessos no qual o termo de frequência satura em 1.0.

A AWS também fornece uma tabela de valores recomendados de pruneDays por tipo de agente:

• Bot de suporte em tempo real: 7 dias — tickets se resolvem em horas ou dias
• Agente de vendas / onboarding: 21 dias — negócios fecham em semanas
• Assistente geral: 45 dias — retenção balanceada para cargas de trabalho mistas
• Helpdesk de TI / operações: 90 dias — padrões de incidentes se repetem sazonalmente
• Consultor jurídico / de conformidade: 180 dias — precedentes permanecem relevantes por meses

Como o AgentCore Memory API não inclui um campo lastAccessedAt, a solução usa o AWS CloudTrail para rastrear acessos reais. O CDK (Kit de Desenvolvimento em Nuvem) configura uma trilha com seletores avançados que capturam eventos de dados GetMemoryRecord. A cada execução do scorer, os logs do CloudTrail das últimas 25 horas são processados e mesclados com um ledger histórico armazenado no Amazon S3 (Serviço de Armazenamento Simples), garantindo que o termo de frequência reflita o histórico de vida completo da memória.

Política 3: Consolidação via LLM

Antes de descartar memórias com baixa pontuação, a solução oferece uma última chance: consolidação. Usando o Amazon Bedrock, memórias relacionadas são mescladas em uma única entrada semântica compacta. Cinco memórias episódicas sobre preferências de deploy se tornam um único fato autoritativo.

O prompt de consolidação instrui o modelo a preservar fatos essenciais, eliminar redundâncias e retornar um score de confiança:

CONSOLIDATION_PROMPT_TEMPLATE = """You are a memory consolidation assistant.
Given the following agent memories, create a single concise summary that
preserves essential facts, user preferences, and actionable knowledge.
Remove redundancy and outdated information.

Memories:
{memory_contents}

Output a JSON object with:
- "summary": the consolidated memory text
- "confidence": a float 0.0-1.0 indicating consolidation quality
- "key_facts": list of preserved key facts"""

A memória consolidada é armazenada de volta no AgentCore Memory e os originais são deletados. Se o Amazon Bedrock falhar, os originais são mantidos intactos. Vale lembrar que consolidação é um processo com perdas — um LLM resumindo cinco memórias em uma pode perder nuances. O score de confiança retornado pelo modelo ajuda a sinalizar consolidações de baixa qualidade para revisão humana. Para domínios de alto risco, a recomendação é arquivar os originais em armazenamento frio em vez de deletá-los. Em produção, a AWS recomenda configurar o Amazon Bedrock Guardrails para filtrar conteúdo inadequado e verificar se as memórias consolidadas permanecem fiéis ao material original.

Arquitetura do workflow noturno

O Amazon EventBridge dispara uma máquina de estados do AWS Step Functions toda noite às 2h UTC. O workflow executa cinco estágios em sequência:

• Expiração por TTL: o Memory Pruner consulta registros mais antigos que o TTL configurado e os deleta.
• Pontuação de memórias: o Memory Scorer processa os logs do CloudTrail, mescla com o ledger histórico no S3, calcula os scores de relevância e retorna as memórias abaixo do limiar.
• Consolidação: o workflow agrupa as memórias de baixo score em lotes (padrão: 10) e os envia ao Memory Consolidator, que invoca o Amazon Bedrock para mesclá-los em entradas semânticas compactas.
• Emissão de métricas: o Metrics Emitter publica métricas do workflow (memórias processadas, consolidadas, descartadas) no Amazon CloudWatch.
• Gravação do resultado: o Run Output Writer persiste os resultados do workflow no S3 para auditoria.

Falhas em qualquer etapa são roteadas para um handler que publica os detalhes do erro em um tópico do Amazon SNS (Serviço de Notificação Simples).

Walkthrough do CDK Stack

Uma única stack CDK (code/lib/memory-lifecycle-stack.ts) define toda a infraestrutura. Cada função Lambda usa Python 3.12 com permissões IAM (Gerenciamento de Identidade e Acesso) de menor privilégio. O código compartilhado é implantado como uma Lambda Layer, e os parâmetros configuráveis são passados como variáveis de ambiente.

As permissões seguem o princípio do menor privilégio: o Memory Scorer pode apenas listar memórias; o Consolidator pode ler, criar e deletar memórias e invocar o Amazon Bedrock; o Pruner pode listar e deletar. O trigger noturno é configurado com uma regra do EventBridge:

new events.Rule(this, 'NightlyMemoryLifecycleRule', {
  schedule: events.Schedule.expression('cron(0 2 * * ? *)'),
  targets: [new targets.SfnStateMachine(stateMachine)],
});

Todos os parâmetros configuráveis são lidos do contexto CDK, permitindo ajustes no momento do deploy sem alterar o código:

npx cdk deploy \
  -c memoryTtlDays=60 \
  -c relevanceThreshold=0.25 \
  -c consolidationBatchSize=15 \
  -c pruneDays=45 \
  -c wRecency=0.4 \
  -c wAccess=0.35 \
  -c wFrequency=0.25 \
  -c maxAccessBaseline=50

Testando a qualidade da memória após o ciclo de vida

Descartar e consolidar memórias só é útil se o agente continuar respondendo corretamente. A solução inclui uma suíte de testes de regressão que mede se as operações de ciclo de vida degradam a qualidade das respostas.

Cada caso de teste especifica uma pergunta, os critérios que a resposta deve satisfazer e um score mínimo de qualidade. O padrão é um ciclo antes-e-depois: registra o score de qualidade antes do workflow, executa o ciclo de vida, e registra novamente. Um caso de teste falha apenas quando o score pós-ciclo cai abaixo do mínimo configurado.

A suíte se integra ao Amazon Bedrock AgentCore Evaluations, que funciona como um sistema LLM-como-juiz: você fornece a resposta do agente e critérios definidos por humanos, e o serviço retorna um score de qualidade normalizado entre 0.0 e 1.0. Isso torna a suíte totalmente automatizável em pipelines de IC/EC (Integração Contínua/Entrega Contínua).

Privacidade, conformidade e GDPR

Gerenciar o ciclo de vida de memórias não é apenas uma questão de performance — é também um requisito de conformidade. Quando o agente armazena dados pessoais em memória, surgem obrigações regulatórias como o GDPR (Regulamento Geral sobre a Proteção de Dados).

A solução inclui um GDPR Deletion Handler dedicado que deleta todas as memórias de um usuário específico. O handler lista cada memória do usuário no AgentCore Memory e as deleta individualmente, retornando uma confirmação com o número de memórias deletadas e os IDs de qualquer falha parcial.

Toda mutação de memória — pontuação, consolidação, descarte, deleção por GDPR — produz logs JSON estruturados no Amazon CloudWatch Logs com tipo de ação, ID da memória e timestamp ISO 8601. O CDK Stack também configura o AWS CloudTrail para registrar chamadas à API do AgentCore Memory, fornecendo uma trilha de auditoria imutável para demonstrações de conformidade.

Considerações de custo

O principal driver de custo é o número de invocações do Amazon Bedrock durante a consolidação. Para um agente com 1.000 memórias onde 20% pontuam abaixo do limiar, espera-se aproximadamente 20 invocações por execução noturna (cerca de US$ 0,01 a US$ 0,02). Com 100.000 memórias, isso pode chegar a US$ 50–100 por mês. A recomendação é começar com um limiar de relevância mais alto para limitar o volume de consolidação.

Pré-requisitos para implantação

Para implantar a solução, são necessários:

• Uma conta AWS com permissões para criar funções Lambda, máquinas de estados do Step Functions, regras do EventBridge, tópicos SNS, dashboards do CloudWatch, trilhas do CloudTrail e buckets S3.
• AWS CDK v2 instalado (npm install -g aws-cdk).
• Node.js 18+ e npm.
• Python 3.12 com pip.
• Acesso ao modelo Claude Sonnet 4.5 (anthropic.claude-sonnet-4-5-20250929-v1:0) habilitado no Amazon Bedrock — consulte os modelos suportados por região no Amazon Bedrock para verificar disponibilidade.
• Amazon Bedrock AgentCore com pelo menos um agente configurado com memória habilitada.
• AWS CLI configurado com as credenciais adequadas.

Conclusão

A AWS demonstrou como construir políticas de ciclo de vida de memória para agentes do Amazon Bedrock AgentCore usando AWS Step Functions e Amazon Bedrock. A solução aplica três políticas complementares: expiração por TTL para limites de tempo rígidos, pontuação de decaimento de relevância para priorização inteligente, e consolidação via LLM para preservar o conhecimento essencial. Com o parâmetro pruneDays, é possível ajustar a agressividade do decaimento. A solução também cobre testes para confirmar que o descarte não degrada a qualidade das respostas, e conformidade com GDPR na camada de memória.

O código completo está disponível no repositório GitHub. Para saber mais, consulte a página de detalhes do Amazon Bedrock AgentCore, o Guia do Desenvolvedor do AWS Step Functions e o Guia do Usuário do Amazon Bedrock.

Fonte

Designing lifecycle policies for AgentCore memory (https://aws.amazon.com/blogs/machine-learning/designing-lifecycle-policies-for-agentcore-memory/)