AWS Bedrock AgentCore: o que mudou nas release updates
TL;DR
As release updates do AWS Bedrock AgentCore mostram uma virada clara: a plataforma passou a cobrir governança, observabilidade e melhoria contínua de agentes, além do runtime para executar esses fluxos. Em vez de deixar policy, avaliação e ajustes como responsabilidade integral do aplicativo, a AWS empurrou boa parte desse trabalho para o perímetro do gateway e para serviços gerenciados.
Na prática, isso reduz o atrito para colocar agentes em produção com controle de acesso, validação de qualidade e testes antes de promover mudanças. Para quem constrói automações com LLMs, o ganho está menos em “mais um endpoint” e mais em um ciclo operacional completo, do trace à correção.
O que mudou no AgentCore
O conjunto de updates mais relevante gira em torno de quatro peças: Policy, Guardrails, Evaluations e Optimization. A documentação de release notes da AWS reúne essas mudanças e mostra a direção da plataforma: sair do laboratório e entrar em operação com controles explícitos e ciclos de feedback mais curtos. Veja a visão consolidada na documentação oficial de release notes do Amazon Bedrock AgentCore.
A Policy tornou-se uma camada de governança fora do código do agente, interceptando tráfego entre tool e agent no AgentCore Gateway. A AWS descreve que essas regras podem ser convertidas para Cedar automaticamente, o que ajuda a padronizar autorização e negação de chamadas em um modelo que times de segurança já conseguem auditar. O anúncio oficial está em Policy in Amazon Bedrock AgentCore is now generally available.
Em junho, a AWS adicionou Bedrock Guardrails diretamente na Policy, permitindo avaliar entradas e saídas no perímetro do gateway antes de seguir adiante. Isso é importante porque captura cenários de prompt injection e exposição de dados sensíveis antes de a ação atingir sistemas downstream. O suporte foi anunciado em Amazon Bedrock AgentCore now supports Bedrock Guardrails in policy.
Policy e Guardrails: governança no perímetro
O ponto mais interessante aqui é arquitetural. Em vez de depender só de validações espalhadas no app, a política passa a agir como perímetro de execução para o agente. Isso ajuda principalmente quando a aplicação tem várias tools e integrações, porque cada chamada pode ser inspecionada antes de passar adiante.
Para times que trabalham com ambientes regulados ou com dados pessoais, essa mudança é prática. No Brasil, um agente que manipula dados de clientes, contratos ou tickets precisa considerar LGPD e o mínimo necessário de exposição de dados. Colocar autorização e filtragem no gateway reduz a chance de o desenvolvedor esquecer uma checagem em um ponto da aplicação e abrir uma brecha operacional.
A AWS descreve a Policy como um mecanismo que pode permitir, negar ou apenas registrar chamadas, e isso combina bem com fluxos de revisão gradual. Um time pode começar em modo observável, entender o tráfego real e só depois transformar regras em bloqueios. Esse caminho é mais seguro do que “ativar tudo de uma vez” em produção.
Evaluations: medindo qualidade sem improviso
Outro avanço relevante é o Amazon Bedrock AgentCore Evaluations, que ganhou disponibilidade geral em março de 2026. O serviço permite avaliar qualidade de resposta, segurança, conclusão de tarefas e uso de ferramentas com avaliadores prontos, além de opções de Ground Truth e avaliadores customizados. O anúncio oficial está em Amazon Bedrock AgentCore Evaluations is now generally available.
O detalhe que importa para operação é que avaliação deixa de ser um script isolado e vira etapa contínua do ciclo. A AWS menciona 13 avaliadores embutidos, além de custom evaluators baseados em LLM-as-a-Judge ou em lógica própria via Lambda com Python ou JavaScript. Isso abre espaço para medir coisas mais próximas da realidade da aplicação, como sequência esperada de ferramentas e comportamento por sessão.
Na prática, isso é útil para um agente de atendimento, por exemplo, que precisa seguir um caminho previsível: identificar intenção, consultar a base certa e só então responder. Se a ordem das tools muda ou se o agente começa a responder sem checar a fonte correta, uma evaluation bem definida captura a regressão antes que o problema chegue ao usuário final.
Esta seção descreve a versão 2026 do AWS Bedrock AgentCore. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Optimization: melhorar com dados, não com achismo
O passo seguinte do ciclo é o AWS Bedrock AgentCore Optimization, que usa traces e resultados de avaliações para gerar recomendações de prompts e descrições de ferramentas. A ideia é fechar o caminho observe → evaluate → improve com validação antes da promoção das mudanças. O anúncio está em Amazon Bedrock AgentCore Optimization preview.
Esse tipo de mecanismo é valioso porque muitos problemas em agentes não nascem do modelo em si, mas da redação da tool description, da ordem de instruções ou de pequenas ambiguidades de prompt. Quando a plataforma sugere ajustes e ainda pede batch evaluations ou A/B tests com significância estatística antes de adotar a mudança, o time consegue tratar o agente como um sistema observável, e não como uma caixa-preta que só “parece funcionar”.
Esse fluxo conversa bem com times brasileiros que costumam começar com squads pequenos e orçamento limitado em cloud. Em vez de duplicar engenharia para manter pipelines próprios de avaliação, o time pode usar avaliações gerenciadas e concentrar esforço no produto. Em reais, isso importa porque reduzir retrabalho de observabilidade e QA manual costuma ser mais relevante do que ganhar um ganho marginal de latência.
Harness: runtime gerenciado para sair do wire-up manual
O AWS Bedrock AgentCore Harness também entrou em disponibilidade geral e reforça a ideia de runtime gerenciado. A proposta é reduzir o trabalho de montar o loop manualmente e operar por configuração e APIs, com capacidades como browser, memória, identidade e observabilidade embutidas. O anúncio oficial está em Amazon Bedrock AgentCore harness is now generally available.
Esse ponto conversa com um cenário muito comum em empresas no Brasil: equipes que querem provar valor rápido em atendimento, automação interna ou assistentes de operação, mas não têm apetite para manter uma orquestração inteira do ciclo do agente. Se o runtime entrega parte desse pacote, o time consegue sair do protótipo com menos código de infraestrutura e mais foco em regra de negócio.
O valor do Harness não está em esconder complexidade de forma mágica, mas em concentrar primitivas comuns em um contrato mais consistente. Isso ajuda a padronizar experiência entre times e diminui a chance de cada squad implementar o próprio “mini framework” de agente.
Como isso afeta arquitetura de agentes
Juntando tudo, o desenho sugerido pela AWS fica mais claro: o agente passa a ter um perímetro de decisão para política e segurança, uma camada de medição contínua e um ciclo de melhoria baseado em evidência. É uma mudança importante porque aproxima a operação de agentes da disciplina que já existe em sistemas distribuídos, observabilidade e governança de APIs.
Na implementação real, isso tende a reduzir três tipos de risco. Primeiro, risco de acesso indevido a tools e dados. Segundo, risco de regressão silenciosa de qualidade. Terceiro, risco de evolução sem controle, em que qualquer ajuste no prompt gera comportamento não testado. As novidades do AgentCore atacam justamente esses três pontos.
Há também um efeito prático na documentação do sistema. Quando policy, evaluations e optimization passam a existir como etapas operacionais, o time ganha material auditável para explicar por que uma ferramenta foi bloqueada, por que uma resposta falhou e por que uma mudança foi promovida. Isso é útil tanto para engenharia quanto para compliance e suporte.
Por que importa pro dev brasileiro
No contexto brasileiro, essa evolução pesa por três motivos concretos. Primeiro, LGPD: agentes que lidam com dados pessoais em suporte, crédito, seguros ou saúde precisam limitar exposição e registrar decisões. Segundo, custo: muitos times aqui trabalham com orçamento apertado em BRL e precisam reduzir retrabalho com observabilidade e QA manual. Terceiro, latência operacional: grande parte das workloads comuns no Brasil ainda roda próxima de regiões AWS na América do Norte, então qualquer falha que obrigue reprocessamento ou intervenção humana fica mais cara e mais lenta.
O efeito final é simples: quanto mais governança vier embutida no perímetro e quanto mais a avaliação for contínua, menor a chance de um agente virar um protótipo eterno. Para squads brasileiros que estão saindo de POC e tentando alcançar produção de verdade, isso significa menos “colar fita adesiva” em volta de um fluxo de LLM e mais disciplina de engenharia aplicada ao produto.
Conclusão
As release updates do AWS Bedrock AgentCore mostram uma plataforma amadurecendo do runtime para a operação completa do agente. Policy e Guardrails colocam segurança e autorização no perímetro, Evaluations formaliza medição contínua, Optimization fecha o ciclo com melhoria baseada em dados, e Harness simplifica o caminho até um runtime gerenciado.
Se você já usa agentes em produção, o próximo passo prático é escolher um caso real do seu sistema e modelar uma avaliação mínima: defina a sequência esperada de ferramentas, um critério objetivo de sucesso e uma regra de bloqueio para entradas sensíveis. Em até 1 hora, você consegue ler a documentação oficial da AgentCore Evaluations e montar o primeiro experimento no seu fluxo atual.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — trilha prática para criar soluções com Amazon Bedrock, AgentCore, automação de fluxos e projetos aplicados em AWS.
- Nexa - Fundamentos de IA Generativa com Bedrock — introduz base de IA generativa na AWS com Bedrock, PartyRock, Amazon Nova e AgentCore.
- Universia - Fundamentos de IA Generativa 2026 — traz fundamentos de IA generativa com ferramentas, prompts e LLMs para aplicação no dia a dia.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
