Da AWS Agents Classic ao AgentCore: migração e novos comportamentos em 2026
TL;DR
O Amazon Bedrock Agents Classic entrou em manutenção, e a recomendação oficial da AWS é migrar para o Amazon Bedrock AgentCore. A mudança não é só de nome: em 2026, o comportamento esperado combina memória gerenciada com retenção curta e longa, além de guardrails aplicados fora do código do agente, no gateway/política.
Na prática, isso reduz o tanto de cola que cada time precisa escrever para guardar contexto, recuperar informação relevante e filtrar entradas e saídas do agente. Para quem trabalha com IA generativa no Brasil, o ganho aparece mais rápido em times que precisam controlar dados sensíveis e reduzir risco operacional sem inflar custo de manutenção.
O que mudou no Bedrock Agents
A documentação oficial da AWS informa que o Agents Classic está em maintenance mode e que novos projetos devem considerar o AgentCore como destino de migração. O ponto central não é apenas trocar uma API por outra. É passar de um modelo em que boa parte do comportamento do agente ficava na aplicação para uma arquitetura em que memória e governança ganham componentes próprios.
Esse reposicionamento importa porque muitos agentes em produção foram construídos com prompt longo, histórico manual e regras espalhadas entre backend, orquestrador e ferramentas. Quando a plataforma assume mais da retenção e do controle, o time tende a gastar menos energia com mecanismos caseiros e mais com desenho de fluxo, avaliação e observabilidade.
O impacto prático da migração
O guia oficial de maintenance mode orienta comparação de capacidades e planejamento de migração, o que sugere que o trabalho não será um simples "lift-and-shift". Em projetos reais, vale mapear quatro coisas antes de migrar: quais habilidades o agente expõe, onde o contexto hoje é persistido, quais chamadas externas passam pelo orquestrador e onde dependências de segurança estão sendo verificadas.
Se o agente atual depende de memória em banco próprio, por exemplo, a migração costuma ser uma boa chance de remover duplicação. Se depende de regras de segurança embutidas em prompt, é o momento de separar o que é instrução do que é política de controle. A documentação e os materiais oficiais do AgentCore apontam justamente para essa separação de responsabilidades.
Memory: retenção curta, retenção longa e menos código de cola
O anúncio da AWS para o AgentCore Memory descreve uma forma gerenciada de manter contexto entre interações. O serviço trabalha com working memory, para o curto prazo, e long-term memory, para retenção entre sessões. Em vez de cada time inventar sua própria camada de persistência, o agente passa a contar com uma superfície mais padronizada de lembrança.
Esse ponto muda o comportamento do agente de maneira bem concreta. Em vez de repetir preferências do usuário, resumo de ticket ou estado de atendimento a cada rodada, o sistema pode reusar contexto já consolidado. Isso é especialmente útil em agentes de suporte, vendas internas, onboarding técnico e automação de back-office, onde o histórico é parte do valor da solução.
Metadata em long-term memory
Em maio de 2026, a AWS anunciou que a long-term memory do AgentCore passou a suportar metadata. Esse detalhe é importante porque tira a memória da lógica puramente semântica e permite filtros estruturados. Em vez de depender apenas de similaridade textual, o time pode registrar atributos como ticket, prioridade, data ou categoria e recuperar memórias com critérios mais previsíveis.
Na prática, isso aproxima o agente do tipo de indexação que times de produto e atendimento já usam em sistemas transacionais. Se você precisa recuperar "somente memórias do ticket X com prioridade alta", metadata ajuda a transformar contexto em algo administrável. O resultado é menos ambiguidade na recuperação e menos chance de trazer contexto irrelevante para a conversa.
Para arquiteturas de agentes em português, isso também ajuda com variações linguísticas e abreviações muito comuns no Brasil. Termos como "ok", "urgente", "PJ", "NF", "boleto" ou "prazo estourado" podem ganhar tags de negócio, em vez de ficar presos apenas à semântica do texto. Isso reduz ruído em fluxos onde o mesmo vocabulário aparece em atendimento, financeiro e operação.
Quando a memória passa a ter metadata, o problema deixa de ser só "lembrar" e passa a ser "lembrar com critério". Em sistemas de agente, esse detalhe é o que separa contexto útil de histórico acumulado.
Guardrails no gateway: segurança fora do código do agente
Outro movimento forte de 2026 é a aplicação de Bedrock Guardrails na policy do AgentCore. O enunciado oficial destaca enforcement no gateway/perímetro, avaliando inputs e outputs antes que a ação siga para downstream. Isso muda bastante a história de segurança de agentes porque desloca a proteção para fora do código interno da lógica agentic.
Esse desenho é valioso em cenários com loops, múltiplas tools e autonomia maior. Se a verificação fica no perímetro, você reduz a dependência de "lembrar" de checar tudo no prompt ou em cada handler. Também ganha consistência quando o agente encadeia chamadas, porque a política continua valendo independentemente da rota interna que ele siga.
Por que isso importa para prompt injection e dados sensíveis
Guardrails no gateway ajudam a conter duas classes de risco que aparecem com frequência em aplicações de agente: prompt injection e exposição de dados sensíveis. Em vez de confiar só na disciplina do prompt, a avaliação no perímetro pode bloquear entrada maliciosa ou saída fora da política antes que ela alcance outro sistema.
No mundo real, isso tem efeito direto em integrações com CRM, ERP, filas de suporte e bases internas. Se o agente consegue consultar informações de clientes, pedidos ou tickets, a checagem no gateway vira uma camada de contenção. É uma diferença relevante para qualquer operação que lida com dados pessoais sujeitos à LGPD, porque o objetivo deixa de ser apenas responder bem e passa a ser responder sem vazar o que não pode.
Como pensar a migração sem reescrever tudo
O caminho mais seguro é tratar a migração como decomposição de responsabilidades. Primeiro, identifique o que hoje é memória, o que hoje é política e o que hoje é orquestração. Depois, mova a retenção para o componente de memory, as regras de segurança para policy/guardrails e o restante para o agente em si.
Se houver automações around tools, documentação ou integrações de produto, o AgentCore CLI oficial indica que a AWS já empacotou parte do lifecycle em operações mais reproduzíveis. Isso é útil porque reduz o risco de configurar ambiente por ambiente à mão, especialmente quando há múltiplos times e ambientes de homologação com diferenças sutis.
Um roteiro prático para a migração costuma caber em quatro etapas:
- Inventariar prompts, tools e armazenamento atual de contexto.
- Definir quais informações viram memória de curto prazo e quais entram em long-term memory.
- Mapear quais filtros e metadados são necessários para recuperação confiável.
- Aplicar guardrails no gateway e validar se eles cobrem entradas, saídas e chamadas a ferramentas.
Esse tipo de separação evita o padrão comum de "agente com tudo dentro do prompt". Em produção, o salto de confiabilidade vem justamente de distribuir bem as responsabilidades entre candidato a decisão, retenção e controle.
Por que isso importa pro dev brasileiro
No contexto brasileiro, essa arquitetura conversa diretamente com a LGPD e com a forma como muitas empresas daqui operam atendimento, cobrança e suporte em canais de alto volume. Em bancos, varejo e SaaS locais, o agente frequentemente toca dados pessoais, histórico de pedidos e contexto de relacionamento. Quando a checagem de policy acontece no perímetro, a chance de aplicar a mesma regra em múltiplas ferramentas e fluxos aumenta.
Há também um componente econômico bem brasileiro: times médios costumam trabalhar com orçamento mais apertado para nuvem e menos margem para reconstruir componentes internos só para manter contexto ou validação de conteúdo. Quando a plataforma embute memória gerenciada e guardrails consistentes, o custo de engenharia tende a sair do "faço eu mesmo" para "integro e governança". Isso encurta o caminho entre prova de conceito e uso real em produção.
Outro fator local é o tempo de resposta percebido em produtos usados no Brasil, muitas vezes conectados a workloads em regiões fora do país. Se o fluxo de agente precisa atravessar várias camadas de validação e persistência customizada, a latência cresce rápido. Uma arquitetura mais padronizada ajuda a reduzir decisões improvisadas e facilita o desenho de serviços mais previsíveis para times que precisam entregar rápido sem sacrificar conformidade.
Leia a migração como mudança de arquitetura, não de SDK
O erro mais comum nesse tipo de evolução é enxergar a troca como mera atualização de biblioteca. O que a AWS está sinalizando é outra divisão de funções: o agente decide, a memória retém com critério e a policy controla o que pode atravessar o perímetro. Para times que constroem agentes internos ou voltados a cliente, isso é uma chance de tornar a solução mais auditável e menos dependente de improviso.
Os anúncios de 2026 deixam claro que o novo padrão é combinar retenção gerenciada, filtros estruturados por metadata e guardrails no gateway. Quem já mantém uma base de conhecimento, um histórico de interação ou uma ferramenta de atendimento tem material suficiente para começar a testagem sem reescrever tudo.
Conclusão
Se você ainda roda um agente no modelo clássico da AWS, vale planejar a migração com foco em três blocos: memória, governança e orquestração. O cuidado certo agora é menos sobre "como o agente fala" e mais sobre "o que ele lembra", "o que ele pode acessar" e "quem barra uma saída indevida".
Como ação prática, abra hoje a documentação oficial de maintenance mode e faça um inventário de 1 hora: liste cada tool, cada dado persistido e cada regra de segurança do seu agente atual, marcando o que deve virar memory, policy ou ficar no código.
Conteúdos da DIO para quem quer aprofundar
- Nexa - Fundamentos de IA Generativa com Bedrock — trilha curta para começar com Amazon Bedrock, AgentCore e outros serviços da AWS em projetos práticos.
- AWS - Agentes de IA em Campo — jornada voltada a agentes autônomos, automação de fluxos e desenvolvimento aplicado com o ecossistema AWS.
- CI&T - Do Prompt ao Agente — bootcamp para sair de prompt engineering básico e avançar para construção de agentes em cenários de trabalho reais.
- AWS - Cloud Amazon Web Services — trilha ampla de cloud AWS com base útil para entender o contexto de serviços e certificações antes de ir para agentes.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
