Memória do AgentCore expira por evento — mudar o prazo não salva o histórico

Para configurar a memória no Amazon Bedrock AgentCore, crie o recurso, escolha por quanto tempo os eventos brutos devem permanecer disponíveis e adicione estratégias apenas para as informações que precisam atravessar sessões. O ponto crítico é que a expiração pertence a cada evento: mudar eventExpiryDuration depois não estende nem encurta o prazo dos eventos já gravados.

Memória curta e memória longa também exigem tratamentos distintos. A primeira conserva as interações brutas que formam o contexto da sessão; a segunda produz registros consolidados em segundo plano, conforme as estratégias escolhidas, para recuperação posterior.

1. Separe contexto de sessão de informação durável

Comece pela finalidade do dado. Turnos recentes, respostas de ferramentas e a ordem das mensagens pertencem à memória curta quando são necessários para manter a continuidade de uma conversa. Preferências, fatos relevantes e resumos que devam reaparecer em outras sessões são candidatos à memória longa.

A documentação sobre os tipos de memória diferencia os eventos brutos associados a uma sessão dos registros de longo prazo extraídos e consolidados de forma assíncrona. Portanto, a memória longa não deve ser tratada como uma cópia imediata e integral do diálogo.

• Use os eventos quando o agente precisar reconstruir o contexto exato e a sequência recente da sessão.
• Use registros consolidados quando ele precisar recuperar informação selecionada em conversas futuras.
• Mantenha fora da memória dados que não tenham uma finalidade posterior definida.

Essa divisão determina duas políticas de ciclo de vida. A expiração dos eventos controla a disponibilidade do material bruto; a política dos registros consolidados deve considerar separadamente o que será criado, recuperado, atualizado ou removido.

2. Crie o recurso com retenção e estratégias explícitas

Na criação da memória, informe seu nome e eventExpiryDuration. Se o agente precisar de memória longa, configure também as estratégias correspondentes. A orientação oficial de criação do AgentCore Memory admite retenção de eventos por até 365 dias, estratégias gerenciadas ou personalizadas e uma chave do AWS KMS administrada pelo cliente; ela também estabelece que uma alteração no prazo se aplica somente aos eventos criados depois da mudança.

Uma configuração conceitual pode usar 30 dias para eventos brutos e habilitar apenas uma estratégia adequada à finalidade do produto, como consolidação de preferências. Os valores são uma hipótese de projeto, não uma recomendação universal: a janela deve resultar das necessidades de continuidade, auditoria e proteção de dados.

1. Crie a memória e guarde o identificador retornado.
2. Defina a retenção dos eventos conforme o período em que o diálogo bruto ainda será necessário.
3. Adicione somente as estratégias de longo prazo que correspondam a informações recuperáveis pelo agente.
4. Espere o recurso ficar ativo antes de começar a enviar eventos.
5. Use um actorId estável para o usuário ou a entidade e um sessionId próprio para cada conversa.

actorId e sessionId resolvem problemas diferentes: o primeiro identifica o ator ao longo do tempo; o segundo agrupa os eventos de uma conversa. Essa organização não substitui autorização na aplicação, que ainda precisa impedir consultas a dados de outro ator.

3. Trate eventos antigos e novos como populações diferentes

Se a memória usava 30 dias e passa a usar 90, os eventos anteriores continuam sujeitos ao vencimento atribuído quando foram criados. Apenas os eventos posteriores recebem a nova duração. Pelo mesmo motivo, reduzir a configuração não funciona como exclusão retroativa do acervo existente.

O efeito operacional é direto: a configuração atual, isoladamente, não descreve o vencimento de todo o histórico. Durante a transição, registre quando a alteração entrou em vigor e considere separadamente os eventos anteriores e posteriores a esse momento.

Antes de aumentar a janela, confirme se a finalidade e os controles permitem conservar os novos eventos por mais tempo. Antes de reduzi-la, verifique se as informações que realmente precisam sobreviver estão cobertas pelas estratégias de longo prazo e estabeleça um procedimento específico caso dados antigos precisem ser removidos antes do vencimento já atribuído.

4. Recupere memória curta e longa por caminhos distintos

Para memória curta, recupere os eventos da sessão e selecione somente os turnos necessários ao contexto imediato. Essa seleção limita o volume enviado ao modelo sem transformar automaticamente cada fala em informação durável.

Para memória longa, pesquise os registros consolidados do ator e inclua no prompt apenas os resultados pertinentes à solicitação atual. Como a consolidação é assíncrona, um fluxo que exige leitura imediatamente após a gravação deve continuar usando os eventos da sessão ou outro estado transacional; não deve pressupor que o novo registro consolidado já esteja disponível.

A aplicação também precisa definir precedência. Se uma preferência antiga da memória longa divergir de uma instrução explícita na sessão atual, uma regra do produto deve decidir qual informação prevalece. Retenção maior, sozinha, não resolve esse conflito e pode trazer contexto desatualizado para a resposta.

5. Feche a configuração com controles de ciclo de vida

Retenção é uma parte do desenho, não seu controle completo. Criptografia, permissões, isolamento entre atores e procedimentos de exclusão devem acompanhar a sensibilidade e a finalidade dos dados processados. A aplicação deve validar o escopo de cada operação, em vez de confiar apenas nos identificadores enviados ao serviço.

Antes de liberar o agente, confira:

• quais dados permanecerão somente como eventos e quais poderão virar registros consolidados;
• se o prazo dos eventos é o menor compatível com a finalidade declarada;
• se consultas com diferentes actorId e sessionId permanecem isoladas;
• qual chave de criptografia será usada e quais identidades terão permissão para acessá-la;
• se o fluxo tolera o intervalo da consolidação assíncrona ou precisa recorrer à memória curta;
• quando cada mudança de eventExpiryDuration entrou em vigor;
• como eventos e registros serão removidos quando deixarem de ter finalidade.

A configuração fica consistente quando responde separadamente a duas perguntas: por quanto tempo cada interação bruta precisa existir e quais informações merecem consolidação. Alterar o primeiro prazo afeta eventos futuros; preservar conhecimento útil depende da segunda decisão.

Leia também:

• Ask Gemini substitui o painel no Google Chat — o histórico não será migrado
• Alinhamento de IA não é um placar único — saiba o que um benchmark deixa escapar
• WhatsApp troca PIN por senha — e ela não expulsa quem já invadiu a conta