AWS Bedrock AgentCore: o que mudou na operação de agentes

TL;DR

As releases recentes do AWS Bedrock AgentCore adicionam peças que faltavam para operar agentes em produção com mais previsibilidade: governança centralizada de tool calls, avaliações contínuas e um ciclo de melhoria baseado em traces e testes. Na prática, o foco saiu de “fazer o agente responder” e foi para “controlar, medir e evoluir o comportamento do agente”.

Isso importa porque agentes em produção não falham só por gerar respostas ruins; eles falham também por usar ferramentas indevidas, perder contexto, regressar após uma mudança de prompt ou criar custo operacional desnecessário. Com Policy, Evaluations e Optimization no fluxo, o time ganha uma base mais concreta para mudança segura.

O que o AgentCore passou a cobrir

O material mais recente da AWS mostra uma evolução por camadas. Um conjunto de lançamentos foi somando capacidades de runtime, protocolo de UI, governança e observabilidade, até chegar a um fluxo mais completo para operar agentes em produção. A leitura do todo sugere uma transição clara: do agente como experimento para o agente como sistema operável.

Entre as fontes primárias do próprio AWS, as páginas de AgentCore Evaluations, Policy, AG-UI no Runtime e Optimization preview apontam exatamente nessa direção.

Governança de tool calls com Policy

O ponto mais importante para produção é a governança fora do código do agente. A caçada comum em projetos de IA é tentar resolver autorização e validação só no prompt ou no middleware da aplicação. O ponto fraco disso é que a regra fica espalhada e difícil de auditar.

Com a Policy do AgentCore, a AWS diz que a governança é aplicada no AgentCore Gateway e convertida para Cedar, interceptando requests antes de permitir ou negar acesso a tools. Isso ajuda a separar intenção do agente e política de uso. Em outras palavras: o agente tenta, o gateway decide.

Fonte primária: Policy in Amazon Bedrock AgentCore is now generally available.

Essa abordagem é especialmente relevante quando o agente aciona ações sensíveis, como consultas a sistemas internos, automação de pagamentos ou manipulação de dados pessoais. Em ambientes que precisam conversar com LGPD, trilhas de auditoria e separação de responsabilidades, mover a regra para um ponto central tende a simplificar revisão e compliance.

O detalhe que muda o desenho da solução

Quando a política fica fora do código do agente, você reduz a necessidade de rebuild sempre que uma regra muda. Isso facilita experimentação com segurança. O time de plataforma consegue alterar o que pode ou não pode ser executado sem reescrever o agente inteiro.

Para equipes no Brasil, isso conversa diretamente com cenários de auditoria interna em fintechs, seguros, varejo e setor público. Nesses contextos, a exigência de rastrear decisões e limitar acesso a dados pessoais não é abstrata; ela aparece em revisão jurídica, segurança e governança de dados desde o início do projeto.

Avaliação contínua com AgentCore Evaluations

Outra peça central é o AgentCore Evaluations, agora em GA. O lançamento traz avaliação automatizada contínua usando tráfego e traces de produção, além de workflows de teste para validar mudanças antes de promover uma nova versão. Isso encaixa o agente em um ciclo mais parecido com o de software tradicional: medir antes, durante e depois da mudança.

A AWS descreve dimensões como qualidade de resposta, segurança, completion de tarefa e uso correto de tools. Também há suporte a evaluators embutidos, Ground Truth e avaliadores customizados, incluindo lógica via funções hospedadas em Lambda. Tudo isso deixa a avaliação menos dependente de inspeção manual de conversa por conversa.

Fonte primária: Amazon Bedrock AgentCore Evaluations is now generally available.

Esse ponto merece atenção porque o ganho prático não é só qualidade. É também velocidade de decisão. Se uma mudança de prompt, de tool description ou de política altera o comportamento do agente, o time precisa saber rápido e com critério. O esforço para revisar isso manualmente cresce demais quando o volume do tráfego sobe.

Ground Truth e regressões

O uso de Ground Truth é útil porque aproxima a avaliação de casos reais. Em vez de olhar apenas para uma métrica genérica, o time declara o comportamento esperado e mede se a nova versão manteve o contrato. Isso é útil quando o agente precisa seguir sequência específica de ferramentas, respeitar formatos ou evitar ações fora do escopo.

Na prática, isso ajuda a transformar “parece funcionar” em algo verificável. Para stacks com integração em produção, isso reduz o risco de regressão silenciosa depois de um ajuste aparentemente pequeno no prompt ou em uma descrição de ferramenta.

O loop observe → improve → validate

O preview de AgentCore Optimization fecha o ciclo. A AWS afirma que o sistema analisa production traces e outputs de evaluation para sugerir melhorias em system prompts e tool descriptions. Depois, essas sugestões passam por batch evaluations e podem ser comparadas em A/B tests com significância estatística.

Esse formato é importante porque mostra uma tentativa de sair da otimização intuitiva. Em vez de mexer no prompt por feeling, o time passa a observar comportamento real, propor mudanças e validá-las com método. Isso conversa bem com times que já fazem ship de software com métricas, canary e comparação de versões.

Fonte primária: Amazon Bedrock AgentCore launches capabilities for optimizing agent performance in preview.

O ganho aqui é operacional. Em vez de discutir “qual prompt parece mais forte”, o time compara comportamento. Em agente com muitos tools, isso pode ser decisivo, porque mudar uma descrição de tool às vezes altera a forma como o modelo escolhe ações. A recomendação guiada por trace ajuda a enxergar esse efeito com mais clareza.

AG-UI no runtime e sessões operacionais

O suporte a AG-UI no AgentCore Runtime amplia o uso do runtime para experiências com interface interativa. A ideia é manter isolamento, autenticação e escala no runtime enquanto a aplicação conversa com uma UI orientada a eventos. Isso é útil quando o agente não é só backend; ele precisa responder em tempo quase real para uma interface humana.

As release notes também mencionam interactive shell sessions e stateful sessions com clientes MCP, incluindo o uso de Mcp-Session-Id. Para quem constrói fluxos longos, isso resolve parte da dor de manter contexto operacional entre interações e ferramentas.

Fonte primária: Release notes for Amazon Bedrock AgentCore.

Esse conjunto de mudanças indica que a AWS está tratando o agente como um sistema com sessão, estado, política e métricas. Isso é mais próximo da realidade de aplicações corporativas do que de demos isoladas.

Como isso afeta um time brasileiro

O contexto brasileiro traz algumas pressões bem concretas. A primeira é LGPD: quando o agente toca dados pessoais, histórico de atendimento ou documentos internos, o time precisa de controles claros de acesso e auditoria. A segunda é custo em BRL e câmbio, que torna mais sensível qualquer aumento de uso de modelo, trace ou tool call mal governado.

Além disso, muita operação no Brasil ainda lida com latência para regiões fora do país, integração com legados e times enxutos que fazem mais de uma função ao mesmo tempo. Nessa realidade, governança centralizada e avaliação automatizada evitam que cada squad crie sua própria regra artesanal de segurança e monitoramento.

Também existe um fator de mercado: parte relevante dos times brasileiros entra em cloud e IA por trilhas de formação prática, bootcamps e projetos hands-on. Por isso, uma plataforma que integre runtime, policy e evaluation tende a acelerar a passagem do laboratório para produção sem exigir que cada equipe monte seu “stack de agente” do zero.

Arquitetura de referência para começar

Um caminho prático para adotar esse conjunto é separar o sistema em quatro camadas: runtime do agente, gateway com Policy, avaliações contínuas e loop de melhoria. O agente conversa com tools; o gateway decide o que é permitido; as avaliações medem se o comportamento continua correto; e a etapa de otimização propõe ajustes com base em traces e testes.

Uma implementação inicial pode seguir esta sequência sem exagerar no escopo:

1. habilite o agente no runtime do Bedrock AgentCore;
2. defina as regras de acesso de tools no gateway com Policy;
3. crie casos de avaliação com Ground Truth para os fluxos críticos;
4. coloque batch evaluations na esteira de validação;
5. aplique recomendações só depois de comparar variantes em teste controlado.

Se o seu time vai seguir o caminho com versionamento de SDK, runtime ou policy, trate essa parte como sensível a mudanças de release. APIs de IA mudam rápido; confira sempre o changelog e as notas oficiais antes de levar para produção.

Conclusão

O conjunto de releases do AWS Bedrock AgentCore mostra uma mudança importante de maturidade: a conversa deixou de ser apenas sobre construir agentes e passou a incluir governança, validação contínua e otimização com base em produção. Para quem precisa operar IA com responsabilidade, isso é o tipo de evolução que reduz improviso e melhora rastreabilidade.

Se você já tem um agente em teste, escolha um fluxo crítico, defina Ground Truth para esse caso e rode uma avaliação comparando duas versões de prompt ou description de tool ainda hoje. Em até uma hora, você consegue transformar uma conversa vaga sobre qualidade em um teste observável.

Conteúdos da DIO para quem quer aprofundar

• Nexa - Fundamentos de IA Generativa com Bedrock — apresenta fundamentos de IA generativa na AWS e coloca o Amazon Bedrock em contexto prático com projetos e desafios.
• AWS - Agentes de IA em Campo — conecta agentes inteligentes, Amazon Bedrock, Amazon Nova e AgentCore em uma trilha voltada a aplicações reais.

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