AWS Bedrock AgentCore: memória, policy e harness em produção

TL;DR

O AWS Bedrock AgentCore empacota três primitivas que resolvem dores bem concretas de agentes em produção: Memory para persistir contexto entre turnos, Policy para autorizar ou negar chamadas a ferramentas com Cedar, e Harness para orquestrar o loop do agente em execução isolada. Na prática, isso reduz a quantidade de cola que o time precisa escrever em volta do modelo e cria um caminho mais previsível para controle, auditoria e manutenção.

As release notes oficiais mostram que o serviço ainda está evoluindo rápido, com pontos ligados a observabilidade, automação de infraestrutura, regiões governamentais e conformidade SOC. Para quem constrói automações, assistentes internos ou fluxos com ferramentas, acompanhar essas mudanças é tão importante quanto entender a API em si.

O que é o AgentCore, na prática

O AgentCore aparece como uma camada gerenciada para operar agentes com menos responsabilidade manual no aplicativo. Em vez de o time ter de reconstruir histórico de conversa, policy engine e runtime isolado do zero, a plataforma entrega esses blocos como primitives acopladas ao loop do agente.

Essa abordagem faz sentido quando o agente deixa de ser um demo e começa a tocar tarefas com ferramentas reais. A diferença não está só em “rodar um prompt”, mas em controlar estado, acesso e ambiente de execução com consistência.

Esta seção descreve a versão preview do AWS Bedrock AgentCore. APIs de IA e serviços gerenciados mudam rápido — confira o changelog oficial antes de adotar em produção: release notes.

Memory: persistência de contexto sem carregar o histórico na mão

A documentação de Memory explica que o harness persiste o estado de conversa por session ID e, opcionalmente, por actor ID. Antes de uma nova invocação, o runtime recupera esse contexto e o devolve ao agente, o que evita que a aplicação tenha de reenviar todo o histórico a cada turno.

Esse detalhe importa porque muitos agentes falham menos por “não entender o prompt” e mais por perderem o fio da conversa. Com memória gerenciada, o time pode tratar sessões longas, retomadas e fluxos multi-etapa com uma superfície menor de código de suporte.

Por padrão, o AgentCore usa uma memória gerenciada com estratégias de semantic e summarization, além de 30-day event expiry. Isso ajuda a controlar retenção e espaço de contexto sem exigir política artesanal para cada projeto.

Também há estratégia de truncation quando o histórico excede a janela do modelo. Em outras palavras, o agente não depende de um histórico infinito; o harness aplica cortes configuráveis para manter a execução viável.

Onde isso ajuda de verdade

Em atendimento interno, triagem de tickets ou copilotos para times de engenharia, a memória evita repetir contexto de uma etapa para outra. Em um fluxo de análise de incidente, por exemplo, o agente pode manter o identificador da sessão, resumir os passos já tomados e retomar a investigação sem o operador reexplicar tudo.

Policy: controle de ferramentas com Cedar

A Policy do AgentCore age como gate antes da execução de tools. O request de chamada passa pela avaliação da policy, que decide se o acesso é permitido ou negado com base em regras escritas em Cedar ou em linguagem natural convertida e validada.

O modelo de autorização segue a estrutura clássica de principal, action, resource e condições. Isso dá ao time uma forma explícita de restringir o que o agente pode fazer, em vez de confiar apenas em instruções de prompt.

Na prática, a diferença é importante: prompt não é fronteira de segurança. Se o agente pode chamar uma tool que acessa dados, aciona uma API interna ou escreve em um sistema sensível, a decisão de acesso precisa existir em uma camada verificável e auditável.

A documentação também deixa claro que a policy opera no gateway, interceptando as invocações antes da execução. Isso cria um ponto único para aplicar regras por identidade, contexto e tipo de ação.

Por que Cedar entra nesse desenho

Cedar foi pensado para expressar políticas de autorização de maneira declarativa. Em serviços que precisam de permissões mais finas para agentes, esse formato facilita revisar quem pode fazer o quê, em quais condições, e com quais recursos.

Para times que já operam IAM na AWS, o benefício é reconhecer a lógica de controle, mas aplicada agora ao ciclo de ferramentas do agente. Isso é útil quando o agente passa a conversar com sistemas financeiros, cadastro de clientes ou automação de operações internas.

Harness: o loop gerenciado e a execução isolada

O harness do AgentCore é descrito como um agent loop gerenciado. Ele concentra a definição do modelo, system prompt e ferramentas, enquanto o backend assume orquestração, execução de tools, gestão de memória e geração da resposta final.

Outro ponto relevante é a execução em microVM isolada por sessão. Essa arquitetura abre espaço para casos como geração de código e análise de dados sem manter o ciclo inteiro preso ao processo da aplicação principal.

O serviço também suporta trazer sua própria imagem de container e integrar com Memory, Gateway, Browser, Code Interpreter e observabilidade. Na prática, isso aproxima o runtime do formato que times de plataforma já usam em cloud: imagem, role, rede, logs e métricas.

O que o harness resolve no dia a dia

Para o dev, o ganho é menos improviso em torno do agente. Em vez de costurar loop, persistência, execução de ferramenta e telemetria em bibliotecas separadas, o harness oferece uma estrutura mais próxima de produção.

Isso também ajuda revisões de arquitetura. A pergunta deixa de ser “como faço o agente funcionar?” e passa a ser “quais limites de memória, ferramenta e execução eu aceito para esse caso?”.

Compliance, segurança e controles operacionais

A documentação de segurança e acesso informa que o harness usa uma execution role IAM específica e requer trust policy para permitir que o service principal do AgentCore assuma a role. Esse é um ponto essencial para separar permissões do aplicativo e permissões do runtime.

O mesmo material detalha requisitos de rede para execução com containers e artefatos: interface endpoints para ECR e gateway endpoint para S3. Em ambientes que precisam sair da internet pública, isso reduz fricção para encaixar o AgentCore em topologias corporativas mais rígidas.

As release notes também registram conformidade SOC 1, SOC 2 e SOC 3. Isso não elimina a necessidade de governança própria, mas diminui a distância entre um experimento e um uso aprovado por áreas de risco e segurança.

Há ainda o anúncio oficial de disponibilidade em AWS GovCloud (US-West), o que reforça o foco em cenários regulados e compliance-driven.

Release notes: por que elas mudam a leitura do produto

As release notes do AgentCore não são um detalhe de manutenção; elas mostram o ritmo de evolução do serviço. Entre os itens documentados estão melhorias de observabilidade, suporte a tagging, automação com CloudFormation e marcos ligados a SOC compliance e GovCloud.

Para quem vai adotar o serviço dentro de uma plataforma interna, isso importa porque recursos de agente vivem em fronteira móvel. O que hoje é preview pode ganhar integração nativa, mudar comportamento de observabilidade ou alterar o caminho de provisionamento em poucas semanas.

A recomendação prática é tratar release notes como parte do desenho de arquitetura. Se o agente depende de um recurso específico de memory, policy ou harness, vale acompanhar a página oficial antes de padronizar o uso em produção.

Por que importa pro dev brasileiro

No Brasil, essa combinação toca uma restrição concreta: LGPD. Quando um agente guarda memória de sessão, a pergunta não é só técnica; ela envolve retenção, finalidade e minimização de dados pessoais. Isso muda a forma de estruturar histórico, resumo e expiração, especialmente em produtos que lidam com atendimento, crédito, saúde ou RH.

Há também um contexto operacional bem brasileiro. Muitas equipes trabalham com orçamento em BRL pressionado pela variação cambial, então um runtime gerenciado que reduza retrabalho em persistência, autorização e observabilidade pode ser mais fácil de justificar do que montar essa base do zero. E como grande parte das empresas daqui consome AWS em regiões externas ou em cenários híbridos, tópicos como latência, VPC endpoints e governança de acesso não são cosméticos — são parte do custo real de operação.

Além disso, o mercado local tem forte presença de times saindo de bootcamps, acelerações e transição de carreira. Para esse perfil, uma abstração clara de memory/policy/harness ajuda a subir a camada de arquitetura sem exigir que cada pessoa domine, ao mesmo tempo, orquestração de agente, autorização fina e isolamento de execução.

Como eu leria esse stack hoje

Se o seu caso é um agente simples, talvez o ganho seja pequeno. Mas se o fluxo envolve múltiplos turnos, ferramentas sensíveis, retenção de contexto e exigência de auditoria, o AgentCore já aparece como uma base útil para padronizar a operação.

A combinação mais interessante aqui é: Memory para manter contexto, Policy para limitar o que o agente pode acionar, e Harness para executar o loop de forma mais controlada. Isso cria uma separação saudável entre lógica do produto e disciplina operacional.

Conclusão

O AWS Bedrock AgentCore não resolve todo o problema de agentes, mas reduz bastante a quantidade de infraestrutura lateral que costuma crescer ao redor deles. Se você precisa levar um agente do protótipo para um ambiente com sessão, autorização e observabilidade, as três primitives — memory, policy e harness — formam um recorte coerente.

O próximo passo mais útil é testar isso em um cenário pequeno e real do seu time: escolha um fluxo com tool calls, defina uma policy mínima e observe como a memória se comporta em duas ou três interações consecutivas. Em até 1 hora, você consegue ler a documentação de Policy e Memory, além de anotar quais campos do seu domínio entram em retenção e quais devem ser descartados por governança.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.