AWS Bedrock AgentCore: runtime, tool use e evals
TL;DR
A AWS passou a tratar AgentCore menos como “onde o agente roda” e mais como uma camada de operação completa: execução, governança de tool use e avaliação contínua. Na prática, isso adiciona controle determinístico antes da execução, integrações MCP mais ricas e um fluxo de evals baseado em traces reais.
Para quem constrói agentes no mercado brasileiro, isso importa porque ajuda a colocar limites claros em acesso a ferramentas, medir regressões com mais disciplina e aproximar a engenharia de IA dos requisitos de compliance e custo que aparecem em times de cloud no Brasil. O ganho deixa de ser só arquitetural e vira operacional.
O que mudou no AgentCore
O ponto central da atualização é simples: a AWS empurrou o AgentCore para três frentes ao mesmo tempo. Primeiro, runtime com suporte a fluxos mais ricos e estado-aware; segundo, tool use com governança determinística; terceiro, evals gerenciadas a partir de traces para acompanhar qualidade em produção. A própria página do produto posiciona o AgentCore como um ambiente serverless para construir e operar agentes com governança e observabilidade: Amazon Bedrock AgentCore.
Esse movimento é importante porque agentes deixam de ser só “uma chamada ao modelo com ferramentas” e passam a ter controle de execução ao redor. Em vez de depender apenas do comportamento probabilístico do modelo, você passa a ter pontos de decisão e validação antes, durante e depois do uso de ferramentas.
Runtime: de execução simples para fluxo com estado
Uma das mudanças mais visíveis está no runtime com capacidades stateful para MCP. A AWS descreve o runtime com suporte a elicitation de entrada do usuário no meio do fluxo, streaming de progresso e interação em operações longas, saindo do modelo puramente stateless. Veja a referência oficial em Introducing stateful MCP client capabilities on Amazon Bedrock AgentCore Runtime.
Esse detalhe muda o desenho de produtos. Quando um agente precisa interromper uma etapa, pedir confirmação, seguir com nova informação e continuar a mesma operação, o runtime deixa de ser “apenas execução” e vira um orquestrador de conversa e progresso. Para fluxos como aprovação de reembolso, triagem interna ou automação de atendimento, isso reduz gambiarra de estado distribuído fora da plataforma.
Por que isso é relevante na arquitetura
Em implementações anteriores, era comum guardar contexto em banco externo, correlacionar eventos manualmente e reconstruir a sessão por conta própria. Agora, o runtime assume parte dessa responsabilidade, o que simplifica integração com ferramentas e deixa o contrato de execução mais explícito. Isso não elimina estado fora da plataforma, mas reduz o trabalho de costurar cada etapa da interação.
Há também um efeito prático em tarefas longas: streaming de progresso melhora a percepção de responsividade. Em vez de um silêncio até o fim da execução, o sistema consegue publicar avanços intermediários, algo valioso para operações que integram APIs corporativas ou processos com latência variável.
Tool use: governança determinística antes da chamada
A atualização mais importante na frente de tool use é a introdução de Policy in AgentCore, que intercepta requests do Gateway antes de executar chamadas para ferramentas. A política usa Cedar e adota semântica de default deny, então qualquer chamada que não casar com uma regra explícita é bloqueada. Consulte a documentação oficial em Policy in Amazon Bedrock AgentCore: Control Agent Interactions e a explicação de Cedar em Understanding Cedar in AgentCore.
Na prática, isso é um divisor de águas para agentes que executam ações sensíveis. Se antes a contenção dependia muito do prompt, agora existe uma camada determinística de autorização entre o raciocínio do agente e a ferramenta real. Isso é particularmente útil quando o agente toca sistemas internos, APIs com efeitos colaterais ou recursos com custo por uso.
Essa combinação de default deny com regras explícitas importa para qualquer time que precise justificar acesso a dados e ações. Em ambientes regulados, o agente ganha uma fronteira parecida com a de um serviço de autorização clássico.
Também há um ganho de ergonomia na autoria das políticas. A AWS indicou que elas podem ser escritas em Cedar e, em alguns fluxos, até a partir de linguagem natural, mas a execução continua sendo Cedar. A descrição oficial está em Amazon Bedrock AgentCore adds quality evaluations and policy controls for deploying trusted AI agents.
O impacto real no design de produto
Isso muda o que você precisa validar no código do agente. Antes, a pergunta era “o modelo vai chamar a tool certa?”. Agora surge outra: “mesmo que ele queira chamar, a policy permite?”. Essa separação melhora auditoria e reduz dependência de prompt engineering como único mecanismo de segurança.
Para times de engenharia no Brasil, essa distinção conversa diretamente com LGPD e com requisitos internos de governança. Se um agente acessa dados de clientes, logs, suporte ou documentos internos, a política explícita ajuda a demonstrar minimização de acesso, o que é mais defensável do que confiar apenas na instrução textual enviada ao modelo.
MCP: integrações mais centrais no Gateway e no Runtime
Outra mudança importante foi o reforço do suporte a MCP no ecossistema AgentCore. No Gateway, a AWS descreve suporte a schema de tool MCP, prompts e resources como primitivas de primeira classe, além de descoberta dinâmica, streaming e session management. A referência está em Extending MCP support for Amazon Bedrock AgentCore Gateway.
No runtime, a capacidade stateful complementa isso ao permitir fluxos onde a sessão não é apenas uma sequência de chamadas isoladas. O efeito combinado é centralizar descoberta e execução de ferramentas com mais contexto, em vez de tratar cada tool como um endpoint solto.
O que isso muda para quem integra ferramentas
Em vez de manter catálogos paralelos de ferramentas, o Gateway passa a servir como ponto mais coeso para descoberta e mediação. Isso ajuda quando o agente precisa navegar entre várias fontes: APIs internas, ações de terceiros, prompts reutilizáveis e recursos compartilhados. O runtime e o gateway passam a conversar de forma mais próxima com o padrão MCP, o que reduz atrito na composição de ferramentas.
Esse movimento também é útil para equipes que já trabalham com integrações corporativas. Em empresas brasileiras com legados e múltiplos domínios, a descoberta dinâmica e a gestão centralizada da sessão diminuem a chance de acoplamento frágil entre o agente e cada sistema integrado.
Evals: qualidade tratada como operação contínua
Na frente de avaliação, o salto é sair de testes pontuais para um modelo gerenciado em cima de traces reais. A documentação de Evaluate agent performance with Amazon Bedrock AgentCore Evaluations explica que o serviço usa traces unificados e aplica LLM-as-a-Judge, com avaliadores built-in e custom.
A mensagem da AWS é claramente “production-first”: a qualidade não acaba quando o agente passa num notebook ou numa demo interna. Ela precisa ser acompanhada nas interações reais, porque é ali que surgem regressões de resposta, de tool use e de comportamento contextual. O blog da AWS reforça esse enquadramento em Build reliable AI agents with Amazon Bedrock AgentCore Evaluations.
Por que traces importam
Usar traces como base de avaliação aproxima a análise da realidade operacional. Em vez de avaliar casos sintéticos apenas, você observa a execução que de fato passou pelo runtime, pelo gateway e pelas policies. Isso melhora a capacidade de detectar regressões em jornadas específicas, como atendimento, triagem interna, automação de documentos ou copilotos corporativos.
Também há um ganho de organização técnica: built-in e custom evaluators permitem separar métricas gerais de critérios específicos do negócio. Um time pode acompanhar completude, aderência a instruções e uso correto de ferramentas, enquanto adiciona critérios próprios ligados ao domínio da empresa.
Como ler essa mudança em uma arquitetura de agente
Se antes a arquitetura de agentes era descrita em termos de LLM, prompt e tool calls, o AgentCore atual sugere uma camada mais completa: runtime com estado, policy enforcement no tool use e evals contínuas. Isso aproxima o stack de um sistema distribuído tradicional, com autorização, observabilidade e métrica de qualidade, mas adaptado ao comportamento probabilístico do modelo.
O efeito prático é reduzir a confiança cega no comportamento do agente. Você passa a ter governança explícita para ações, melhor ergonomia para fluxos longos e uma forma de medir degradação ao longo do tempo. Em projetos reais, isso costuma significar menos surpresa em produção e mais clareza sobre o que o agente pode ou não pode fazer.
Por que importa para o dev brasileiro
No Brasil, esse conjunto de mudanças conversa diretamente com dois pontos: custo e conformidade. Muitas equipes trabalham com orçamentos enxutos, latência sensível em relação a regiões da AWS e obrigações de proteção de dados sob a LGPD. Quando um agente pode pedir confirmação em fluxo, bloquear tool calls por policy e ser avaliado continuamente, fica mais fácil justificar uso em ambientes com governança mais rígida.
Também há um aspecto de maturidade de mercado. Em times brasileiros que ainda estão saindo do estágio de POC e tentando colocar agentes em operação real, a combinação entre policy, MCP e evals reduz a distância entre “funciona no demo” e “aguenta produção”. Isso é especialmente relevante em setores como bancos, seguradoras, varejo e serviços públicos, onde a trilha de auditoria e o controle de acesso importam desde o primeiro piloto.
Um exemplo concreto: se uma equipe no Brasil integra o agente com dados de clientes, documentos fiscais ou informações operacionais, a policy determinística ajuda a demonstrar que o agente não tem acesso irrestrito às tools. Em um cenário de LGPD e auditoria interna, esse detalhe vale mais do que uma instrução bem escrita no prompt.
Conclusão
O AgentCore mudou o papel do runtime, do tool use e das evals. O runtime ficou mais apto a lidar com sessões e operações longas; o tool use ganhou uma fronteira determinística com Cedar e default deny; e as evals passaram a acompanhar qualidade com traces reais e LLM-as-a-Judge. Em conjunto, isso transforma a plataforma de base de execução em uma camada de operação para agentes.
Se você constrói agentes com AWS, vale experimentar isso em um caso concreto de baixo risco, como um fluxo interno de classificação ou de apoio ao atendimento. Depois, compare o comportamento antes e depois de uma policy explícita e de uma avaliação baseada em trace.
Abra a documentação oficial do AgentCore Evaluations e escolha um fluxo real do seu time para desenhar uma primeira avaliação em menos de 1 hora.
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 — apresenta bases de IA generativa na AWS com Bedrock, Nova, PartyRock e AgentCore em uma trilha curta.
- Michael Page - Criando Seu Primeiro Agente de IA — foca em fundamentos, engenharia de prompt, agentes e aplicações reais para produtividade e automação.
- CAIXA - Inteligência Artificial na Prática — explora fundamentos de IA aplicados a finanças, produtividade e construção de projetos com o apoio de especialistas.
- Nublify - Primeiros passos em IA e Cloud — combina cloud AWS, segurança, governança e IA generativa em projetos práticos para quem quer consolidar base técnica.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
